please don't switch to kexec (was Re: R70/R71 on debug v3 board ?)
laforge at openmoko.org
Mon Feb 11 13:17:08 CET 2008
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:
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.
- Harald Welte <laforge at openmoko.org> http://openmoko.org/
Software for the world's first truly open Free Software mobile phone
More information about the openmoko-kernel