Thread: Neo900 - finally a successor of N900
View Single Post
joerg_rw's Avatar
joerg_rw is offline joerg_rw
2016-01-06 , 06:58
Posts: 2,222 | Thanked: 12,651 times | Joined on Mar 2010 @ SOL 3
#2751
Originally Posted by ibero View Post
No offence meant. We can all see that you're the guy holding project together, and we all appreciate it greatly.

As I read it, the bugtracker page you link to says that for security reasons the sys_boot5 pin will be linked to the Hall switch (which senses the state of the battery cover - i.e. battery cover off; sys_boot5=1), and that for additional security it may be possible to hardwire the sys_boot5 low, and hence override the Hall switch and not allow the boot sequence to be modified at all. Is this right?
Yes, exactly. Also keep in mind that SYS_BOOT only defines where from ROMBOOT loads xloader aka MLO. The latter then loads uBoot from arbitrary storage - depending on what's coded into xloader. Finally uBoot loads the kernel and tells kernel where is /-fs. So even without any control over SYS_BOOT[5] the natural method to do "multiboot" is to have uBoot (as well as xloader) loaded from NAND and uBoot then lets user decide where kernel and system should get fetched from. In case xloader in NAND is not found, the ROMBOOT will fall through to next source in boot sequence
Code:
sys_boot5=0:  sys_boot[4:0]=0b10000 --> OneNAND USB UART3 MMC1
sys_boot5=1:  sys_boot[4:0]=0b10000 --> USB UART3 MMC1 OneNAND
So SYS_BOOT[5]=1 is only needed to recover from a broken xloader/uBoot in OneNAND, by booting from either USB, UART3 (HackerBus) or MMC1. While normal changing of boot device (and thus kernel and system) is done in uBoot which can have all the protection against attacks you could think of. And since OneNAND is first in normal boot sequence, if you locked your device there's no way for an attacker to bypass that security in uBoot, except of unlocking the device again which means disassemble and solder which can't get done without losing RAM content. So your encrypted filesystem is secure when your device has a lockscreen enabled :-) The less concerned user would keep the battery lid hallswitch connected to SYS_BOOT[5] to allow forcing of e.g. USB (xloader) boot in case some mishap messed up e.g. uBoot. For added safety you would want your system to erase from RAM any cryptokeys for your encrypted filesystems as soon as a battery lid removal gets detected on a screenlocked device.

cheers
/j
Last edited by joerg_rw; 2016-01-06 at 07:37.
 

The Following 10 Users Say Thank You to joerg_rw For This Useful Post: