[Arm-netbook] EOMA68-A20 schematics review - enable verified boot ???

[Xavi Drudis Ferran]

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-leaks-golden-key/
)

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

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.