El Sun, Aug 14, 2016 at 11:14:07PM +0100, Luke Kenneth Casson Leighton deia:

ok i need to do a schematic / PCB upgrade to add an extra address line to the current EOMA68-A20 PCB to be able to access 2GB of RAM instead of the current limit of 1GB. i've looked at the cost of the 2x DDR3 x16 RAM ICs and they're nuts: $9 **EACH** whereas 4x DDR3 x8 RAM ICs are $3.95 giving a total of $12 for the 2GB RAM.

I thought the production units were going to be like the existing prototype, but since there's a redesign I just thought it might be time to add some switch or jumper to enable/disable writing to some NAND area or SD or something ?

I don't know how to go about it, the idea would be to "answer" the request for secure boot of those people saying they can't trust an ARM device without Trust Zone.

I'm relunctant in general to trust Trust Zone/Secure boot, because it is too complex even if well designed, and even when the owner has all the keys. But smarter people than me seem to find it useful, so I'm not ready to outright dismiss it either. For me it is not so much about controlling what gets installed but about letting others control what is installed (the delegation is forced in the case of bad secure boot and decided by the owner in the case of good secure boot). The advantage of delegation is that some party that centralizes security may be able to devote more resources, and the disadvantage that that also becomes a more attractive target for attacks or failures that compromise everyone who has delegated to them (see http://arstechnica.com/security/2016/08/microsoft-secure-boot-firmware-snafu... )

Once I read the verified boot idea in chromebook devices http://www.chromium.org/chromium-os/chromiumos-design-docs/firmware-boot-and...

It looks like roughly right (disregarding the paternalism, cloud backups, scaremongering people modifiying their OS, etc.). And to simplify, I wouldn't care about malicious users "borrowing" the device and returning it with malware, just about remote attacks. After all compute cards are small enough that you can keep them in a safe or locked box or your pocket. It does not require Trusted Zone, and could be simplified further.

What it boils down to is that if the compute card had some sort of jumper or switch that users with physical access could operate intentionally, it could have two positions. In one the computer card is unbrickable just like it is now and can boot from several places, all those places readwrite or replaceable. In the other the device can only boot from a section of the NAND and that section is readonly (until the switch changes position).

The computer cards would be delivered as unbrickable, without any verified boot software, but any user wishing to develop or adapt a verified boot firmware could develop and install it themselves and have the minimal hardware support to operate it with the flip of a switch. If someone wants to set up a system for users who don't understand verified boot they can seal the switch with an adhesive tape or just instruct the users to never touch it whatever it happens.

If the NAND eventually becomes too corrupt to boot from it, then the computer card can be repurposed to non-verified uses or sold to someone who wants such uses. (or the NAND could be socketed enabling repair, but that does not seem easy at all).

Now I don't know what hardware design it would require. I read some EEPROMs have read only sections. Maybe we could just make do with complete readonly NAND (not just part of it) by an AND of the switch and the write enable signal. 8GB read only seems a waste, but if it is simple enough to get it's already something. Or maybe some simple logic circuit from the address bus (if parallel, but address goes probably in serial through the wires?). And then somehow prevent booting from other sources when the switch is on to protect from remote attackers modifying the boot media. Can the A20 be straped to boot only from NAND ? I think the JZ4775 can, by just troggling some input lines.

I really don't know if it is possible or hard, I just thought I could comment it in case someone had a simple solution that would not cause too much trouble in redesign, retest, etc. If it is too complex, I don't think it is worth it.

Also, it'd be best if some expert in security would chime in to say how much the idea is worth. For instance an objetion I can see is that malware in the writable storage (part of the NAND, or SD or whatever) could just wait until the user flips the switch for a regular update and sneak something bad in the boot code. But then the verified boot should have prevented that malware being there at all, I guess. It's a matter of the verified OS preventing access. And foremost, the code in the readonly part should be as simple and audited as possible and not be updated too often, maybe only after strict verification of the whole system, I don't know. I mean the code doing the verification in secure boot/trusted zone is just in there read only, so if you trust that you could trust some other verifying code and just never flip the switch?

I don't know. I'm just trying to make Trust Zone believers happy without really being one myself, so I may be wrong.