Discussion:
[Arm-netbook] Verifying firmware
Raphaël Mélotte
2016-08-21 20:19:31 UTC
Permalink
Hello,

First of all I have been following the crowdfunding and mailing list since
the first of august (I have been using another email adress) and I have to
say I really like every aspect of this project and I highly respect and
admire the ideology that goes with the project.


I haven't been able to pledge until now but I will make sure to do so as
soon as I can and before the crowdfunding ends. I really want to test what
an EOMA68 laptop would look and behave like, and I want to replace my tiny
Raspberry pi server with another EOMA68 (I will also be willing to buy more
powerful computer cards if they ever get created).

Since the EOMA68 is entirely free, I was thinking that *theoretically* it
should be possible to read and verify every firmware, and/or binaries
present to run the chip (I don't really know how to call it so I will call
it "microcode"). More and more people are worried about the microcodes that
are run on our hardware and being able to verify what is actually running
on our machine (when it boots for example) would be comforting. It seems to
me that it's the first time the source code for every microcode in a
computer will be available, since some projects tried to do so in the past,
but never achieved to run 100% without proprietary code (purism, novena,
...).

From a security point of view, open source code is the best option since it
allows to check if the code being run isn't malware. However, if I don't
verify the code present on my machine, how will I know it is the same code
as the source that was analyzed and that it is not malicious code ? That's
why I'm asking if it would be possible to read the microcodes present on
the chip, and check them against the online source codes (kind of a
checksum ?). That way we would be able to know if the code had been
tampered with, be it during shipping, after being infected by a malware
that was somehow able to change the boot code or some firmware, an evil
maid attack, etc.

Just to be clear I'm not being paranoid to the point where I would suspect
some bad guys inserting malware in my machine during shipping (I guess the
country I live in is "libre" enough to not do that, but that's surely not
the case for everyone everywhere in the world), and I will probably not try
to verify every firmware on the chip, but since this is one of the first
truly free system I was asking myself if it would be possible. Also maybe
being able to do so easily would attract more people who are deeply focused
on security and privacy and would be beneficial to the project.

I also understand that as of today, checking every code on a system is more
an utopia then a doable thing (you'd also have to check firmware from your
keyboard, mouse, webcam, USB flash drive, and pretty much everything you
connect to the main board) and may be pointless, but I'm also confident
that in the future (maybe distant, maybe not) we will have to be able to do
so if we want to keep our digital life private, as everything we do is more
and more linked to the digital world, and malware techniques are becoming
more and more creative (see for example BadUSB).

I'm not a computer scientist and although I do my best to learn how
software works, I don't understand everything about hardware and I may be
missing some important point that makes my idea impossible to realize.
That's why I'm asking it here since you know far more about it then me.

Also please forgive my written expression: I'm doing my best to express my
ideas clearly, but English isn't my native language and I sometimes don't
know how to express myself to be best understood.

Anyway, I sincerely hope this project becomes a great success, and that you
will be able to make it grow even more.


Kind regards,

Raphaël Mélotte
A Bioengineering student interested in computers
Luke Kenneth Casson Leighton
2016-08-21 20:55:31 UTC
Permalink
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Sun, Aug 21, 2016 at 9:19 PM, Raphaël Mélotte
Post by Raphaël Mélotte
Hello,
First of all I have been following the crowdfunding and mailing list since
the first of august (I have been using another email adress) and I have to
say I really like every aspect of this project and I highly respect and
admire the ideology that goes with the project.
thanks. it's not quiiite "ideology" - there are genuine sound and
practical business reasons for doing what we're doing. let me put it
another way: when we get to mass-volume levels would you *like* us to
be "yet another proprietary software peddler"? :)
Post by Raphaël Mélotte
I haven't been able to pledge until now but I will make sure to do so as
soon as I can and before the crowdfunding ends. I really want to test what
an EOMA68 laptop would look and behave like, and I want to replace my tiny
Raspberry pi server with another EOMA68 (I will also be willing to buy more
powerful computer cards if they ever get created).
cool. they will.
Post by Raphaël Mélotte
Since the EOMA68 is entirely free,
the *standard* is open (properly open), the source code is libre, and
the hardware is 99% libre, aiming for 100%.
Post by Raphaël Mélotte
I was thinking that *theoretically* it
should be possible to read and verify every firmware, and/or binaries
present to run the chip (I don't really know how to call it so I will call
it "microcode").
the only "microcode" - using the phrase you use - that we know of is
the eGON Boot ROM, which hno has extracted and
part-reverse-engineered, more info here:
http://linux-sunxi.org/EGON#eGON.BRM
Post by Raphaël Mélotte
More and more people are worried about the microcodes that
are run on our hardware and being able to verify what is actually running on
our machine (when it boots for example) would be comforting. It seems to me
that it's the first time the source code for every microcode in a computer
will be available, since some projects tried to do so in the past, but never
achieved to run 100% without proprietary code (purism, novena, ...).
there are actually plenty - many of them early beaglebone designs
especially those around the AM Sitara series - but it's the first that
could be deployed usefully in mass-volume scenarios as opposed to
"engineering only" boards.
Post by Raphaël Mélotte
From a security point of view, open source code
no it isn't... *libre* source code is...
Post by Raphaël Mélotte
is the best option since it
allows to check if the code being run isn't malware. However, if I don't
verify the code present on my machine, how will I know it is the same code
as the source that was analyzed and that it is not malicious code ?
well if you can't do it, at least someone else can.
Post by Raphaël Mélotte
That's
why I'm asking if it would be possible to read the microcodes present on the
chip, and check them against the online source codes (kind of a checksum ?).
no idea.
Post by Raphaël Mélotte
That way we would be able to know if the code had been tampered with, be it
during shipping, after being infected by a malware that was somehow able to
change the boot code or some firmware, an evil maid attack, etc.
well, we picked an "unbrickable" processor precisely so that you
could download binaries / source from a *trusted* source and re-flash
everything.
Post by Raphaël Mélotte
Just to be clear I'm not being paranoid to the point where I would suspect
some bad guys inserting malware in my machine during shipping (I guess the
country I live in is "libre" enough to not do that,
you _are_ joking, right? :) it's *well known* that the NSA unboxes
Cisco products and other routers, installs replacement firmware *AND
CHIPS*, then boxes them back up and sends them on their way. there's
even photographs online of them carrying out these practices.
Post by Raphaël Mélotte
but that's surely not
the case for everyone everywhere in the world), and I will probably not try
to verify every firmware on the chip, but since this is one of the first
truly free system I was asking myself if it would be possible.
yes.
Post by Raphaël Mélotte
I also understand that as of today, checking every code on a system is more
an utopia then a doable thing (you'd also have to check firmware from your
keyboard, mouse, webcam, USB flash drive, and pretty much everything you
connect to the main board)
true... but here you *can* check the STM32F072's firmware (which
controls the keyboard, mouse and PMIC), and you can re-flash on every
boot should you so wish... bear in mind that's going to wreck the
on-board flash at some point, but you can do it.
Post by Raphaël Mélotte
and may be pointless, but I'm also confident that
in the future (maybe distant, maybe not) we will have to be able to do so if
we want to keep our digital life private, as everything we do is more and
more linked to the digital world, and malware techniques are becoming more
and more creative (see for example BadUSB).
yep.... not a lot that can be done about that. shoving 240v AC down
a 5v DC line is guaranteed to be disastrous, no matter what the piece
of electronics is.
Post by Raphaël Mélotte
I'm not a computer scientist and although I do my best to learn how software
works, I don't understand everything about hardware and I may be missing
some important point that makes my idea impossible to realize. That's why
I'm asking it here since you know far more about it then me.
Also please forgive my written expression: I'm doing my best to express my
ideas clearly, but English isn't my native language and I sometimes don't
know how to express myself to be best understood.
doing pretty well so far
Post by Raphaël Mélotte
Anyway, I sincerely hope this project becomes a great success, and that you
will be able to make it grow even more.
thanks.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-
Henrik Nordström
2016-08-23 17:50:30 UTC
Permalink
Post by Raphaël Mélotte
From a security point of view, open source code
 no it isn't... *libre* source code is...
I would love to hear your elaboration on how libre source code is more
secure than open source. I don't see how libre have any relevance
there.

Having access to the complete readable sourcecode and being developed
in a trustworthy environment is very relevant. But that is by no means
unique to libre or even proven to be an natural effect of libre. Those
aspects come from other properties of the software projects than what
makes the distinction between open/libre.
Post by Raphaël Mélotte
That's
why I'm asking if it would be possible to read the microcodes present on the
chip, and check them against the online source codes (kind of a checksum ?).
 no idea.
There is no microcode or closed firmware running on the A20.

There is a bootrom embedded in the CPU that allows the CPU to load the
bootloader from flash or usb recovery but once the bootloader takes
control the bootrom ceases to execute entirely.

The bootrom is easily extracted from both Linux and the USB recovery
boot protocol if you want to analyze it further. But it is an embedded
ROM memory in the CPU silicon that can not be modified short of
Allwinner making another CPU silicon production mask and produces new
CPUs.

What the A20 is missing from a security perspective is secure boot
procedure. There is some primitive support but not really functioning.
Some of you may think I am crazy speaking about secure boot, but
properly used it is a very strong tool for ensuring that the installed
software is not tampered with by untrusted parties. But this requires
that you are in control of the security keys and not some untrusted
proprietary vendor.
 well, we picked an "unbrickable" processor precisely so that you
could download binaries / source from a *trusted* source and re-flash
everything.
Yes, the A20 is very nice in that it is unbrickable in software terms,
just as most other SoCs in the same area. It is still possible to brick
A20 systems by software but then by wearing out flash storage etc, not
by accidently writing the wrong software to flash.

And the A20 it is one of the most well covered SoCs in terms of
open/libre software support.
 yep.... not a lot that can be done about that.  shoving 240v AC down
a 5v DC line is guaranteed to be disastrous, no matter what the piece
of electronics is.
That can actually be dealt with without too much trouble, but not in
scope of this list..

Regards
Henrik

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-n
Luke Kenneth Casson Leighton
2016-08-23 18:06:31 UTC
Permalink
On Tue, Aug 23, 2016 at 6:50 PM, Henrik Nordström
Post by Henrik Nordström
Post by Luke Kenneth Casson Leighton
Post by Raphaël Mélotte
From a security point of view, open source code
no it isn't... *libre* source code is...
I would love to hear your elaboration on how libre source code is more
secure than open source. I don't see how libre have any relevance
there.
Having access to the complete readable sourcecode and being developed
in a trustworthy environment is very relevant. But that is by no means
unique to libre or even proven to be an natural effect of libre.
thanks for picking up on that, henrik. so you're saying that if the
source is "open" it's no different from "libre" because in both cases
the full source is available.

so it would only be instances where the source *isn't* available (and
the binary was encrypted with an RSA key, then loaded into a separate
virtual memory space which was made inaccessible to even read)... but
that would, yes, be an instance where source... wasn't available :)

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send
Russell Hyer
2016-08-23 18:55:41 UTC
Permalink
I thought the whole argument of libre/free vs. open source had
absolutely nothing to do with the source itself, but it's about the
essential freedoms as granted in the software. So, in some respects,
Apple and Microsoft allow developers to see the source of at least
some of the systems (when you're developing on their systems), but the
systems that one creates in this way are non-free. And open source has
allowed companies like Google and co to whitewash the whole idea of
being free to program. (Luckily, their reach hasn't extended to
cooking food for ourselves, or we'd have to invent a government plan
to reduce/add/modify salt/sugar content in food. No wait, such
programs do exist!)

Russell
If days were numbered, this one would probably be 23...
Post by Luke Kenneth Casson Leighton
On Tue, Aug 23, 2016 at 6:50 PM, Henrik Nordström
Post by Henrik Nordström
Post by Luke Kenneth Casson Leighton
Post by Raphaël Mélotte
From a security point of view, open source code
no it isn't... *libre* source code is...
I would love to hear your elaboration on how libre source code is more
secure than open source. I don't see how libre have any relevance
there.
Having access to the complete readable sourcecode and being developed
in a trustworthy environment is very relevant. But that is by no means
unique to libre or even proven to be an natural effect of libre.
thanks for picking up on that, henrik. so you're saying that if the
source is "open" it's no different from "libre" because in both cases
the full source is available.
so it would only be instances where the source *isn't* available (and
the binary was encrypted with an RSA key, then loaded into a separate
virtual memory space which was made inaccessible to even read)... but
that would, yes, be an instance where source... wasn't available :)
l.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co.u
Raphaël Mélotte
2016-08-23 22:02:21 UTC
Permalink
Post by Henrik Nordström
Post by Luke Kenneth Casson Leighton
Post by Raphaël Mélotte
That's
why I'm asking if it would be possible to read the microcodes present on the
chip, and check them against the online source codes (kind of a checksum ?).
no idea.
There is no microcode or closed firmware running on the A20.
There is a bootrom embedded in the CPU that allows the CPU to load the
bootloader from flash or usb recovery but once the bootloader takes
control the bootrom ceases to execute entirely.
The bootrom is easily extracted from both Linux and the USB recovery
boot protocol if you want to analyze it further. But it is an embedded
ROM memory in the CPU silicon that can not be modified short of
Allwinner making another CPU silicon production mask and produces new
CPUs.
What the A20 is missing from a security perspective is secure boot
procedure. There is some primitive support but not really functioning.
Some of you may think I am crazy speaking about secure boot, but
properly used it is a very strong tool for ensuring that the installed
software is not tampered with by untrusted parties. But this requires
that you are in control of the security keys and not some untrusted
proprietary vendor.
Regards
Henrik
Thank you for detailing that :-)
It's true that a secure booting mechanism would be a great addition to
security.
Nevertheless if I have to choose I prefer no secure boot than secure boot
the way it has been implemented in almost all modern laptops, where almost
only proprietary OSes are allowed to boot and everything is obfuscated
since it's proprietary (that sort of secure boot in my opinion, doesn't add
any security and only brings hassle).
And the EOMA68 being libre, maybe people will be interested in developing a
libre secure boot :-)
Russell Hyer
2016-08-23 22:30:28 UTC
Permalink
Yes, Raphaël, that is an issue. After all, if you have one of those
new fancy laptops (that doesn't have a libre BIOS) to run a
non-Windows kernel, the tool you get to use (that you can find
packaged into the Ubuntu boot discs) is actually a self-signed hack by
Microsoft (MS) to allow you to boot ANY system, and the system
"validates" itself. So, yeah, the commercial systems aren't worth
much, but at least they allow you to undo the security, by pressing
the hollywood button (TM).

:)

Russell
Post by Raphaël Mélotte
Post by Henrik Nordström
Post by Luke Kenneth Casson Leighton
Post by Raphaël Mélotte
That's
why I'm asking if it would be possible to read the microcodes present on the
chip, and check them against the online source codes (kind of a checksum ?).
no idea.
There is no microcode or closed firmware running on the A20.
There is a bootrom embedded in the CPU that allows the CPU to load the
bootloader from flash or usb recovery but once the bootloader takes
control the bootrom ceases to execute entirely.
The bootrom is easily extracted from both Linux and the USB recovery
boot protocol if you want to analyze it further. But it is an embedded
ROM memory in the CPU silicon that can not be modified short of
Allwinner making another CPU silicon production mask and produces new
CPUs.
What the A20 is missing from a security perspective is secure boot
procedure. There is some primitive support but not really functioning.
Some of you may think I am crazy speaking about secure boot, but
properly used it is a very strong tool for ensuring that the installed
software is not tampered with by untrusted parties. But this requires
that you are in control of the security keys and not some untrusted
proprietary vendor.
Regards
Henrik
Thank you for detailing that :-)
It's true that a secure booting mechanism would be a great addition to
security.
Nevertheless if I have to choose I prefer no secure boot than secure boot
the way it has been implemented in almost all modern laptops, where almost
only proprietary OSes are allowed to boot and everything is obfuscated
since it's proprietary (that sort of secure boot in my opinion, doesn't add
any security and only brings hassle).
And the EOMA68 being libre, maybe people will be interested in developing a
libre secure boot :-)
_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to ar
Raphaël Mélotte
2016-08-23 23:07:03 UTC
Permalink
Yes, that's why I ended up just disabling secure boot on my laptop (at the
time I wanted to install another OS there wasn't even such tool available
for the distribution I wanted to install).
At least I have an option to disable it completely, I heard some laptops
don't even offer the choice to disable it.
It feels just the same as when you buy a smartphone and you have to find a
hack to root it or install another OS (and possibly loose your warranty). I
can't believe that happened to PCs as well
Yes, Raphaël, that is an issue. After all, if you have one of those
new fancy laptops (that doesn't have a libre BIOS) to run a
non-Windows kernel, the tool you get to use (that you can find
packaged into the Ubuntu boot discs) is actually a self-signed hack by
Microsoft (MS) to allow you to boot ANY system, and the system
"validates" itself. So, yeah, the commercial systems aren't worth
much, but at least they allow you to undo the security, by pressing
the hollywood button (TM).
:)
Russell
Albert ARIBAUD
2016-08-24 09:31:13 UTC
Permalink
Bonjour,

Le Tue, 23 Aug 2016 19:50:30 +0200
Post by Henrik Nordström
Post by Raphaël Mélotte
From a security point of view, open source code
I am feeling that there was some early cut here wrt the point discussed:
what Raphaël was say is "From a security point of view, open source
code is the best option since it allows to check if the code being run
isn't malware".
Post by Henrik Nordström
 no it isn't... *libre* source code is...
I would love to hear your elaboration on how libre source code is more
secure than open source. I don't see how libre have any relevance
there.
Having access to the complete readable sourcecode and being developed
in a trustworthy environment is very relevant. But that is by no means
unique to libre or even proven to be an natural effect of libre. Those
aspects come from other properties of the software projects than what
makes the distinction between open/libre.
There is a slight difference though, at least if our understanding of
"libre vs open" is similar enough, and bearing in mind Raphaël's
statement above.

FTR, a TL;DR description of my own viewpoint would be "libre source is
open source plus the ability, both legally and physically, to replace
binaries built from said source with one's own possibly modified
version" -- IOW, a 'thing' for which I can have source code but cannot
rebuild and replace all of the binary code is not libre even though it
may be said 'open source' without causing me to die gasping.

With this definition in mind, I see a difference between open and
libre, in that with both, I can analyze the code, possibly discover
risks, and potentially modify the source code so as to remove the risk,
but only with libre can I actually eliminate the risk where it might
arise.

This is where, considering Raphaël's statement, libre beats open: true,
open source may allow checking whether some binary is a tampered build,
but it does not necessarily allows fixing that; libre does.

(again, that's assuming the distinction above between open and libre.)
Post by Henrik Nordström
What the A20 is missing from a security perspective is secure boot
procedure. There is some primitive support but not really functioning.
Some of you may think I am crazy speaking about secure boot, but
properly used it is a very strong tool for ensuring that the installed
software is not tampered with by untrusted parties. But this requires
that you are in control of the security keys and not some untrusted
proprietary vendor.
Agreed that secure boot is a tool which can be used for good as well as
bad. My personal opinion is that I'm fine with secure boot as long as
there is a way back -- i.e. a way to revert the whole thing to a "blank"
state where, yes, whatever keys were inside are erased so encrypted
data that was on the device may be lost (except possibly to sufficient
crypto-analysis resources), but the device can always be "refitted" with
new keys for new data.
Post by Henrik Nordström
Regards
Henrik
Amicalement,
--
Albert.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@fil
pelzflorian (Florian Pelz)
2016-08-24 10:28:28 UTC
Permalink
Post by Albert ARIBAUD
Bonjour,
Le Tue, 23 Aug 2016 19:50:30 +0200
Post by Henrik Nordström
Post by Luke Kenneth Casson Leighton
Post by Raphaël Mélotte
From a security point of view, open source code
what Raphaël was say is "From a security point of view, open source
code is the best option since it allows to check if the code being run
isn't malware".
Post by Henrik Nordström
Post by Luke Kenneth Casson Leighton
no it isn't... *libre* source code is...
I would love to hear your elaboration on how libre source code is more
secure than open source. I don't see how libre have any relevance
there.
Having access to the complete readable sourcecode and being developed
in a trustworthy environment is very relevant. But that is by no means
unique to libre or even proven to be an natural effect of libre. Those
aspects come from other properties of the software projects than what
makes the distinction between open/libre.
There is a slight difference though, at least if our understanding of
"libre vs open" is similar enough, and bearing in mind Raphaël's
statement above.
FTR, a TL;DR description of my own viewpoint would be "libre source is
open source plus the ability, both legally and physically, to replace
binaries built from said source with one's own possibly modified
version" -- IOW, a 'thing' for which I can have source code but cannot
rebuild and replace all of the binary code is not libre even though it
may be said 'open source' without causing me to die gasping.
With this definition in mind, I see a difference between open and
libre, in that with both, I can analyze the code, possibly discover
risks, and potentially modify the source code so as to remove the risk,
but only with libre can I actually eliminate the risk where it might
arise.
This is where, considering Raphaël's statement, libre beats open: true,
open source may allow checking whether some binary is a tampered build,
but it does not necessarily allows fixing that; libre does.
(again, that's assuming the distinction above between open and libre.)
While free software advocates emphasize the user’s rights and
independence – and unlike open source advocates, it matters to them that
the rights are granted in practice and granted fully, including for
commercial use –, open source proponents *do* care about (and may care
more about) advantages like more trustworthy code (more „eyes“). Of
course, a libre culture may make it easier to actually fix
vulnerabilities in practice when found.

Regards,
Florian Pelz

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files
Luke Kenneth Casson Leighton
2016-08-24 19:58:06 UTC
Permalink
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by Albert ARIBAUD
Bonjour,
Le Tue, 23 Aug 2016 19:50:30 +0200
Post by Henrik Nordström
What the A20 is missing from a security perspective is secure boot
procedure. There is some primitive support but not really functioning.
Some of you may think I am crazy speaking about secure boot, but
properly used it is a very strong tool for ensuring that the installed
software is not tampered with by untrusted parties. But this requires
that you are in control of the security keys and not some untrusted
proprietary vendor.
Agreed that secure boot is a tool which can be used for good as well as
bad. My personal opinion is that I'm fine with secure boot as long as
there is a way back -- i.e. a way to revert the whole thing to a "blank"
state where, yes, whatever keys were inside are erased so encrypted
data that was on the device may be lost (except possibly to sufficient
crypto-analysis resources), but the device can always be "refitted" with
new keys for new data.
... and that's where things like the TI SoCs and the Samsung Exynos
SoCs fall down. you simply *cannot* undo a blown e-fuse: that's the
whole point.

which is why if you were to ship a processor that *didn't* have its
"secure e-fuse" blown, you're actually selling people a ticking
time-bomb where the possibility exists for someone to hack in to your
computer, install some spyware at the bootloader level, blow the
e-fuse and then you're *really* screwed. a whole new ransomware
vector at the *hardware* level. dang.

which is why i contacted TI to ask them if there was a way to blow
the e-fuses so that DRM could ****NEVER**** be enabled. they were
incredibly surprised: i was literally the first person ever to ask
them.

oh... the answer was "no".

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.
Xavi Drudis Ferran
2016-08-24 20:04:03 UTC
Permalink
Post by Luke Kenneth Casson Leighton
... and that's where things like the TI SoCs and the Samsung Exynos
SoCs fall down. you simply *cannot* undo a blown e-fuse: that's the
whole point.
which is why if you were to ship a processor that *didn't* have its
"secure e-fuse" blown, you're actually selling people a ticking
time-bomb where the possibility exists for someone to hack in to your
computer, install some spyware at the bootloader level, blow the
e-fuse and then you're *really* screwed. a whole new ransomware
vector at the *hardware* level. dang.
which is why i contacted TI to ask them if there was a way to blow
the e-fuses so that DRM could ****NEVER**** be enabled. they were
incredibly surprised: i was literally the first person ever to ask
them.
oh... the answer was "no".
I didn't know that.

Does this affect all TI SoCs or only some or you just checked the one
you were evaluating ?

Do you have a link to the docs ?

Thank you.


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp
Xavi Drudis Ferran
2016-08-24 20:07:44 UTC
Permalink
Post by Luke Kenneth Casson Leighton
which is why i contacted TI to ask them if there was a way to blow
the e-fuses so that DRM could ****NEVER**** be enabled. they were
incredibly surprised: i was literally the first person ever to ask
them.
oh... the answer was "no".
Thinking more about it I'm more interested in the docs...
What does that efuse do ? One would imagine that while it isn't fused you
can install either software or keys to validate software that you choose ?
Then you could install some noop DRM and fuse the e-fuse ? Just to make
sure nobody takes control and install their nasty DRM and then fuses ?
Something similar to the Ubuntu boot loader that boots unverified kernels ?


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.p
Stefan Monnier
2016-08-24 17:51:48 UTC
Permalink
Post by Henrik Nordström
Post by Raphaël Mélotte
From a security point of view, open source code
 no it isn't... *libre* source code is...
I would love to hear your elaboration on how libre source code is more
secure than open source. I don't see how libre have any relevance
there.
I don't want to make the claim either, but I'd point out that lots of
"open source" code isn't really completely "open source", nowadays, but
nobody cares (because that's irrelevant to the proponents of "open
source"), whereas the Free Software crowd tends to care more.

E.g. some people think their smartphone runs "open source" software, but
all there is really is that there's some "open source" code that's claimed
to be related to the binary code they have on their phone. But they
have no way to verify whether there truly is such a relation, nor
would they be able to install the presumably corresponding "open
source" code.

So I guess from this point of view, Libre source code is safer because
it insists on you being able to replace the binary code with one that
you built yourself from the source.


Stefan


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large at
Stefan Monnier
2016-08-24 17:56:58 UTC
Permalink
Post by Henrik Nordström
What the A20 is missing from a security perspective is secure boot
procedure. There is some primitive support but not really functioning.
Some of you may think I am crazy speaking about secure boot, but
properly used it is a very strong tool for ensuring that the installed
software is not tampered with by untrusted parties.
How serious is such a threat?

I mean I see the point in theory, but in practice the risk of the user
losing control of his device because of such a "trusted boot" seems to
be far higher than the risks linked to the absence of such a mechanism.


Stefan


PS: by the way, if you boot from the µSD card, you could probably get
the same result as a trusted boot by using your own µSD when booting and
making sure this card is read-only (e.g. by taking it out after the
boot is over).


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbo
Xavi Drudis Ferran
2016-08-24 18:52:20 UTC
Permalink
Post by Stefan Monnier
PS: by the way, if you boot from the µSD card, you could probably get
the same result as a trusted boot by using your own µSD when booting and
making sure this card is read-only (e.g. by taking it out after the
boot is over).
mmm... manually taking it out is cumbersome. And leaves some time
vulnerable to remote attacks (during boot and between boot and
removal).

uSD cards already have a microcontroller in them. And some have been
hacked, I think. You could design one that has a way to define a read
only part (not like the SD cards that have that switch which only asks
the O.S. "please don't write me" but like the microcontrolled
answering "nah nah nah I don't hear you" when write requests to the
specified range arrive).

Then you could put some switch in the uSD card itself to allow RW
access. Or you could have an unreadable part that holds a passphrase and
when you write to it the same passphrase it allows writing to all the
storage, until you write something again in that area which becomes
the new passphrase and locks the readonly region.

With such a uSD card you could have verified boot (without evil maid
protection, only remote attacks protection) in basically any computer
that can boot from uSD. You should possibly take care if the computer
can boot from more non-removable places, though.

But you would need a uSD factory, of course, and people who trust you
and your factory. And you would need to have verified boot for the
software running in the uSD microcontroller. It's verified boot turtles
all the way down...

I think it's easier to put a switch in serial to the write enable in
the EEPROM or NAND and make sure the switch makes it boot only from
there. If you can afford it to only make a region read-only much the
better.

Or you can live without secure boot, verified boot, etc. like most people
has most of the computer history.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co
Stefan Monnier
2016-08-25 04:01:48 UTC
Permalink
Post by Xavi Drudis Ferran
mmm... manually taking it out is cumbersome. And leaves some time
vulnerable to remote attacks (during boot and between boot and
removal).
Sure. Same issue w.r.t how realistic such an attack would be compared
to the clear and obvious attacks to your freedom perpetrated in the name
of "secure boot".
Post by Xavi Drudis Ferran
uSD cards already have a microcontroller in them. And some have been
hacked, I think. You could design one that has a way to define a read
only part (not like the SD cards that have that switch which only asks
the O.S. "please don't write me" but like the microcontrolled
answering "nah nah nah I don't hear you" when write requests to the
specified range arrive).
Probably easier would be to make a µSd card where the little switch is
not just advisory but is "put [...] in serial to the write enable in the
EEPROM or NAND" on the card ;-)


Stefan


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@fil
Xavi Drudis Ferran
2016-08-25 05:56:10 UTC
Permalink
Post by Stefan Monnier
Post by Xavi Drudis Ferran
mmm... manually taking it out is cumbersome. And leaves some time
vulnerable to remote attacks (during boot and between boot and
removal).
Sure. Same issue w.r.t how realistic such an attack would be compared
to the clear and obvious attacks to your freedom perpetrated in the name
of "secure boot".
I'm not advocating for secure boot. In fact I advocate against any
form of secure boot that is not under the user control at all times. I
also avocate against any service or content that requires secure boot
or remote attestation, even if the user could choose not to use the
service or content and not to use secure boot, or not to use certain keys.

I'm only trying not to sell something broken to those who want secure boot
under user control.
Post by Stefan Monnier
Post by Xavi Drudis Ferran
uSD cards already have a microcontroller in them. And some have been
hacked, I think. You could design one that has a way to define a read
only part (not like the SD cards that have that switch which only asks
the O.S. "please don't write me" but like the microcontrolled
answering "nah nah nah I don't hear you" when write requests to the
specified range arrive).
Probably easier would be to make a µSd card where the little switch is
not just advisory but is "put [...] in serial to the write enable in the
EEPROM or NAND" on the card ;-)
Yes. I only said that because SD cards have a switch and uSD cards don't
so I thought there is some mechanical difficulty in puting a switch in
a card so small.

You could put a switch in a uSD card, but that would make the whole
uSD card read only, so you would need something else for storage
space. If you can get simply a part readonly that'd be much better and
self contained.

And yes, we can live happy without secure boot.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@fil
Luke Kenneth Casson Leighton
2016-08-25 06:23:45 UTC
Permalink
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by Xavi Drudis Ferran
You could put a switch in a uSD card, but that would make the whole
uSD card read only, so you would need something else for storage
space. If you can get simply a part readonly that'd be much better and
self contained.
'i've set up read-only rootfs on debian before, it was fun to do.
needed it because i was booting off of CF cards. used somebody else's
scripts... where are they... ah ha!

https://gist.github.com/netj/1216392

that was the one. slight adaptation - worked great. i use a variant
of that on my laptop (SSD) where /var/log is entirely in a tmpfs.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large
Xavi Drudis Ferran
2016-08-25 07:16:40 UTC
Permalink
Post by Luke Kenneth Casson Leighton
'i've set up read-only rootfs on debian before, it was fun to do.
needed it because i was booting off of CF cards. used somebody else's
scripts... where are they... ah ha!
https://gist.github.com/netj/1216392
You mean software read only, right ? (as in file system mount flags)
That's good but we were talking hardware read only which would seem
more secure. If one has the kind of compromise that secure boot or
verified boot try to protect against, the attacker can possibly
remount read write or something.






_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments
Luke Kenneth Casson Leighton
2016-08-25 15:42:33 UTC
Permalink
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by Xavi Drudis Ferran
Post by Luke Kenneth Casson Leighton
'i've set up read-only rootfs on debian before, it was fun to do.
needed it because i was booting off of CF cards. used somebody else's
scripts... where are they... ah ha!
https://gist.github.com/netj/1216392
You mean software read only, right ? (as in file system mount flags)
yeahyeah... so if the *hardware* is read-only it'll work. basically
the OS-level adaptation required to work with read-only filesystem
media is right there. or, the basis for it, anyway.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attac

Stefan Monnier
2016-08-25 13:24:57 UTC
Permalink
Post by Xavi Drudis Ferran
I'm not advocating for secure boot. In fact I advocate against any
form of secure boot that is not under the user control at all times.
Yes, we agree violently ;-)
Post by Xavi Drudis Ferran
Yes. I only said that because SD cards have a switch and uSD cards don't
so I thought there is some mechanical difficulty in puting a switch in
a card so small.
Oh, you're right, I forgot that µSD cards don't have the little
advisory switch. So we'd need an SD card instead. I can live with it.
Post by Xavi Drudis Ferran
You could put a switch in a uSD card, but that would make the whole
uSD card read only, so you would need something else for storage
space. If you can get simply a part readonly that'd be much better
and self contained.
Sure, you can always ask for more, but since the A20 comes with plenty
of MMC ports, you can have a whole read-only SD card plus a separate
read-write µSD card.


Stefan "whose Orange Pi mini has 2 µSD slots one of which holds
a card with nothing else than U-boot"


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netbook
Raphaël Mélotte
2016-08-22 19:32:19 UTC
Permalink
Date: Sun, 21 Aug 2016 21:55:31 +0100
Subject: Re: [Arm-netbook] Verifying firmware
gmail.com>
Content-Type: text/plain; charset=UTF-8
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sun, Aug 21, 2016 at 9:19 PM, Raphaël Mélotte
Post by Raphaël Mélotte
Hello,
First of all I have been following the crowdfunding and mailing list
since
Post by Raphaël Mélotte
the first of august (I have been using another email adress) and I have
to
Post by Raphaël Mélotte
say I really like every aspect of this project and I highly respect and
admire the ideology that goes with the project.
thanks. it's not quiiite "ideology" - there are genuine sound and
practical business reasons for doing what we're doing. let me put it
another way: when we get to mass-volume levels would you *like* us to
be "yet another proprietary software peddler"? :)
Post by Raphaël Mélotte
I haven't been able to pledge until now but I will make sure to do so as
soon as I can and before the crowdfunding ends. I really want to test
what
Post by Raphaël Mélotte
an EOMA68 laptop would look and behave like, and I want to replace my
tiny
Post by Raphaël Mélotte
Raspberry pi server with another EOMA68 (I will also be willing to buy
more
Post by Raphaël Mélotte
powerful computer cards if they ever get created).
cool. they will.
Post by Raphaël Mélotte
Since the EOMA68 is entirely free,
the *standard* is open (properly open), the source code is libre, and
the hardware is 99% libre, aiming for 100%.
Post by Raphaël Mélotte
I was thinking that *theoretically* it
should be possible to read and verify every firmware, and/or binaries
present to run the chip (I don't really know how to call it so I will
call
Post by Raphaël Mélotte
it "microcode").
the only "microcode" - using the phrase you use - that we know of is
the eGON Boot ROM, which hno has extracted and
http://linux-sunxi.org/EGON#eGON.BRM
Post by Raphaël Mélotte
More and more people are worried about the microcodes that
are run on our hardware and being able to verify what is actually
running on
Post by Raphaël Mélotte
our machine (when it boots for example) would be comforting. It seems to
me
Post by Raphaël Mélotte
that it's the first time the source code for every microcode in a
computer
Post by Raphaël Mélotte
will be available, since some projects tried to do so in the past, but
never
Post by Raphaël Mélotte
achieved to run 100% without proprietary code (purism, novena, ...).
there are actually plenty - many of them early beaglebone designs
especially those around the AM Sitara series - but it's the first that
could be deployed usefully in mass-volume scenarios as opposed to
"engineering only" boards.
Post by Raphaël Mélotte
From a security point of view, open source code
no it isn't... *libre* source code is...
Post by Raphaël Mélotte
is the best option since it
allows to check if the code being run isn't malware. However, if I don't
verify the code present on my machine, how will I know it is the same
code
Post by Raphaël Mélotte
as the source that was analyzed and that it is not malicious code ?
well if you can't do it, at least someone else can.
Post by Raphaël Mélotte
That's
why I'm asking if it would be possible to read the microcodes present on
the
Post by Raphaël Mélotte
chip, and check them against the online source codes (kind of a checksum
?).
no idea.
Post by Raphaël Mélotte
That way we would be able to know if the code had been tampered with, be
it
Post by Raphaël Mélotte
during shipping, after being infected by a malware that was somehow able
to
Post by Raphaël Mélotte
change the boot code or some firmware, an evil maid attack, etc.
well, we picked an "unbrickable" processor precisely so that you
could download binaries / source from a *trusted* source and re-flash
everything.
Post by Raphaël Mélotte
Just to be clear I'm not being paranoid to the point where I would
suspect
Post by Raphaël Mélotte
some bad guys inserting malware in my machine during shipping (I guess
the
Post by Raphaël Mélotte
country I live in is "libre" enough to not do that,
you _are_ joking, right? :) it's *well known* that the NSA unboxes
Cisco products and other routers, installs replacement firmware *AND
CHIPS*, then boxes them back up and sends them on their way. there's
even photographs online of them carrying out these practices.
Post by Raphaël Mélotte
but that's surely not
the case for everyone everywhere in the world), and I will probably not
try
Post by Raphaël Mélotte
to verify every firmware on the chip, but since this is one of the first
truly free system I was asking myself if it would be possible.
yes.
Post by Raphaël Mélotte
I also understand that as of today, checking every code on a system is
more
Post by Raphaël Mélotte
an utopia then a doable thing (you'd also have to check firmware from
your
Post by Raphaël Mélotte
keyboard, mouse, webcam, USB flash drive, and pretty much everything you
connect to the main board)
true... but here you *can* check the STM32F072's firmware (which
controls the keyboard, mouse and PMIC), and you can re-flash on every
boot should you so wish... bear in mind that's going to wreck the
on-board flash at some point, but you can do it.
Post by Raphaël Mélotte
and may be pointless, but I'm also confident that
in the future (maybe distant, maybe not) we will have to be able to do
so if
Post by Raphaël Mélotte
we want to keep our digital life private, as everything we do is more and
more linked to the digital world, and malware techniques are becoming
more
Post by Raphaël Mélotte
and more creative (see for example BadUSB).
yep.... not a lot that can be done about that. shoving 240v AC down
a 5v DC line is guaranteed to be disastrous, no matter what the piece
of electronics is.
Post by Raphaël Mélotte
I'm not a computer scientist and although I do my best to learn how
software
Post by Raphaël Mélotte
works, I don't understand everything about hardware and I may be missing
some important point that makes my idea impossible to realize. That's why
I'm asking it here since you know far more about it then me.
Also please forgive my written expression: I'm doing my best to express
my
Post by Raphaël Mélotte
ideas clearly, but English isn't my native language and I sometimes don't
know how to express myself to be best understood.
doing pretty well so far
Post by Raphaël Mélotte
Anyway, I sincerely hope this project becomes a great success, and that
you
Post by Raphaël Mélotte
will be able to make it grow even more.
thanks.
Thank you for your precise answer ! (As every of your answers I saw on the
mailing list)

Ideology probably wasn't the right word, of course I wouldn't like you to
be "yet another proprietary software peddler".
By the way if I got it right, you say 99% of the hardware is open because
only the mali GPU isn't documented ? (but we won't use it) That is awesome
!
I really didn't know that NSA was already intercepting shipments before
they arrive to their destination, now I'm even more convinced that we need
libre hardware for everyone.

What I forgot to ask was if it was possible to read and possibly reflash
firmware from the userspace, or would it require some special hardware to
be connected directly to the chip like when flashing libreboot ? Anyway I
guess I will find out by myself as investigate more about it.

PS: I miss-configured my subscription to the mailing list and couldn't
reply directly to your message. I hope this reply will get where it has to
be, linked to the right thread.
Luke Kenneth Casson Leighton
2016-08-22 21:31:28 UTC
Permalink
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Mon, Aug 22, 2016 at 8:32 PM, Raphaël Mélotte
Thank you for your precise answer ! (As every of your answers I saw on the
mailing list)
no problem. i guess talking with dr stallman had some effect, uh? :)
Ideology probably wasn't the right word, of course I wouldn't like you to be
"yet another proprietary software peddler".
:)
By the way if I got it right, you say 99% of the hardware is open because
only the mali GPU isn't documented ? (but we won't use it) That is awesome
!
yep. it's less ideal than we'd like (clearly).
I really didn't know that NSA was already intercepting shipments before they
arrive to their destination,
easily found, google "nsa intercept photos" - it's right there
http://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/
now I'm even more convinced that we need libre
hardware for everyone.
*shrugs* :)
What I forgot to ask was if it was possible to read and possibly reflash
firmware from the userspace,
yep.
or would it require some special hardware to be
connected directly to the chip like when flashing libreboot ?
no - you just need to format a micro-sd card in a specific way, and
the boot rom will look for it on MMC0. another way is to put the
processor into "USB-FEL" mode and just upload programs over a USB-OTG
cable directly into memory.

both methods are fully documented on the sunxi wiki.
Anyway I guess
I will find out by myself as investigate more about it.
yep. start with the sunxi wiki.
PS: I miss-configured my subscription to the mailing list and couldn't reply
directly to your message. I hope this reply will get where it has to be,
linked to the right thread.
looks like it. "reply" is configured to go only to the list, but
whom you're sending as must be *only* from the address that's
subscribed. stick another one on and change the subscription to
"nomail" if you prefer - i've done that with 3 separate email
addresses on this list alone ;)

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments
Raphaël Mélotte
2016-08-23 21:38:47 UTC
Permalink
That is great news ! Thanks for pointing me out where to start :-)
Post by Luke Kenneth Casson Leighton
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
Post by Raphaël Mélotte
What I forgot to ask was if it was possible to read and possibly reflash
firmware from the userspace,
yep.
Post by Raphaël Mélotte
or would it require some special hardware to be
connected directly to the chip like when flashing libreboot ?
no - you just need to format a micro-sd card in a specific way, and
the boot rom will look for it on MMC0. another way is to put the
processor into "USB-FEL" mode and just upload programs over a USB-OTG
cable directly into memory.
both methods are fully documented on the sunxi wiki.
Post by Raphaël Mélotte
Anyway I guess
I will find out by myself as investigate more about it.
yep. start with the sunxi wiki.
l.
_______________________________________________
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Continue reading on narkive:
Loading...