On Mon, Feb 11, 2008 at 11:36:27AM +0000, Andy Green wrote: > Somebody in the thread at some point said: > > On Mon, Feb 11, 2008 at 10:01:49AM +0000, Andy Green wrote: > >>> Anything that can be done in software is not a sufficient level of > >>> protection. We want to reliably claim that this nor flash is read-only, > >>> and that users can always recover, no matter what they do on the > >>> software side. > >> How about if it doesn't ship with flash_unlock? > > > > no. it's still very easily possible for malicious code to circumvent that. > > Well, if it can get in the phone and run as root, yes.
which is probably still extremely easy, with all the (legitimate) focus being on completing functionality and not on security auditing :) > >> That's annoying because it seems soon we will discard U-Boot and move to > >> using a kexec-ed kernel directly (thus getting out of this crazy system > >> of implementing things twice once for kernel and once for U-Boot). And > >> we have 2MByte NOR there that can do this. > > > > I know werner has been wanting to do that for a long time. But this > > really sucks. Do you realize that you are just scrapping the ability to > > boot any different OS on the device? > > No I don't think so -- Linux can just be a large U-Boot for these > purposes, like Two Kernel Monte: > > http://sourceforge.net/projects/monte/ I was not aware of this. But I still doubt there are existing, reliable and well-understood solutions for loading an ELF image or other OS kernels that way, particularly probably not on ARM. > I believe that U-Boot is just a broken down Linux, so logically if we > use the full-strength original actual Linux we can do a *superset* of > what was possible with U-Boot, including acting as a bootloader for BSD > or whatever. There's nothing especially smelly about Linux for this > purpose (except footprint, but we have the space) that can't be said > about U-Boot the same. It's just U-Boot modestly says it is a > "bootloader" and Linux says it is an "operating system". well, the difference being that the bootloader works with MMU off, in the highest privilege level.. and an OS usually refuses anyone else doing that, while it remains in control. starting an OS kernel on top of an already-running Linux system sounds much more complicated than running an executable on that very kernel (whcih is what the OS is designed for) The factor here should also not only: What can be done, but rather: how can it be done? Is there existing demo code that people can use, ... > If the problem we're trying to solve is evil haxxors, then I guess we > should keep the hardware gating for NOR write: it truly limits what can > be done... otherwise we should allow NOR upgrades because it's hard > enough to brick already. The idea of the NOR flash was to protect against anything that software can do, even intentionally malicious software. An open device has many advantages, but it also is much easier to develop malicious code for it :) That's the very nature of openness. You can't open the borders and not expect a certain percentage of criminals coming in... I really see little point in updating the u-boot image in the NOR flash after the device has shipped. If that bootloader image is known to have working DFU support, dynpart creation, etc., then there is little reason for updating it later. Yes, it might have bugs here and there. But if the core functionality for autonomously unbricking the device has once worked, it will continue to work in the future. Obviously, it should not depend on the sanity of any data structures present in the NAND flash, e.g. environment / partition table / bad block table persing. Otherwise, a particularly crafted data structure could easily break the NOR-based u-boot and you have the same problem all over again. Cheers, -- - Harald Welte <[EMAIL PROTECTED]> http://openmoko.org/ ============================================================================ Software for the world's first truly open Free Software mobile phone