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
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Sun, Aug 21, 2016 at 9:19 PM, Raphaël Mélotte raphael.melotte@gmail.com wrote:
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"? :)
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.
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%.
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
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.
From a security point of view, open source code
no it isn't... *libre* source code is...
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.
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.
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.
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.
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.
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.
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.
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
Anyway, I sincerely hope this project becomes a great success, and that you will be able to make it grow even more.
thanks.
sön 2016-08-21 klockan 21:55 +0100 skrev Luke Kenneth Casson Leighton:
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.
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
On Tue, Aug 23, 2016 at 6:50 PM, Henrik Nordström henrik@henriknordstrom.net wrote:
sön 2016-08-21 klockan 21:55 +0100 skrev Luke Kenneth Casson Leighton:
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.
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...
On 23/08/2016, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Tue, Aug 23, 2016 at 6:50 PM, Henrik Nordström henrik@henriknordstrom.net wrote:
sön 2016-08-21 klockan 21:55 +0100 skrev Luke Kenneth Casson Leighton:
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-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
2016-08-23 19:50 GMT+02:00 Henrik Nordström henrik@henriknordstrom.net:
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 :-)
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
On 23/08/2016, Raphaël Mélotte raphael.melotte@gmail.com wrote:
2016-08-23 19:50 GMT+02:00 Henrik Nordström henrik@henriknordstrom.net:
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 :-)
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
On Aug 24, 2016 12:30 AM, "Russell Hyer" russell.hyer@gmail.com wrote:
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
Bonjour,
Le Tue, 23 Aug 2016 19:50:30 +0200 Henrik Nordström henrik@henriknordstrom.net a écrit:
sön 2016-08-21 klockan 21:55 +0100 skrev Luke Kenneth Casson Leighton:
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".
With that in mind:
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.)
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.
Regards Henrik
Amicalement,
On 08/24/2016 11:31 AM, Albert ARIBAUD wrote:
Bonjour,
Le Tue, 23 Aug 2016 19:50:30 +0200 Henrik Nordström henrik@henriknordstrom.net a écrit:
sön 2016-08-21 klockan 21:55 +0100 skrev Luke Kenneth Casson Leighton:
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".
With that in mind:
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
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Wed, Aug 24, 2016 at 10:31 AM, Albert ARIBAUD albert.aribaud@free.fr wrote:
Bonjour,
Le Tue, 23 Aug 2016 19:50:30 +0200 Henrik Nordström henrik@henriknordstrom.net a écrit:
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.
El Wed, Aug 24, 2016 at 08:58:06PM +0100, Luke Kenneth Casson Leighton deia:
... 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.
El Wed, Aug 24, 2016 at 08:58:06PM +0100, Luke Kenneth Casson Leighton deia:
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 ?
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
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).
El Wed, Aug 24, 2016 at 01:56:58PM -0400, Stefan Monnier deia:
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.
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".
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
El Thu, Aug 25, 2016 at 12:01:48AM -0400, Stefan Monnier deia:
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.
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.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Aug 25, 2016 at 6:56 AM, Xavi Drudis Ferran xdrudis@tinet.cat wrote:
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.
El Thu, Aug 25, 2016 at 07:23:45AM +0100, Luke Kenneth Casson Leighton deia:
'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!
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.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Aug 25, 2016 at 8:16 AM, Xavi Drudis Ferran xdrudis@tinet.cat wrote:
El Thu, Aug 25, 2016 at 07:23:45AM +0100, Luke Kenneth Casson Leighton deia:
'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!
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.
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 ;-)
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.
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"
Note that there is no electrical switch in even standard SD -- that advisory "switch" is just a plastic slider whose position is sensed by an actual switch in the card slot (if so equipped). So you'd need to find a ridiculously tiny switch to fit in an SD card case, and find a way to make that plastic slider operate it.
If the card is small/cheap enough, you might just put a loop of fine jumper wire in series with write-enable, and leave it hanging out of the case -- snip/tear the wire for read-only. Or even better -- a little window in the case exposes a section of PCB with a cut trace. Solder/de-solder as many times as you like.
Benson
arm-netbook@lists.phcomp.co.uk
-
Albert ARIBAUD -
Benson Mitchell -
Henrik Nordström -
Luke Kenneth Casson Leighton -
pelzflorian (Florian Pelz) -
Raphaël Mélotte -
Russell Hyer -
Stefan Monnier -
Xavi Drudis Ferran