please don't switch to kexec (was Re: R70/R71 on debug v3 board ?)
andy at openmoko.com
Mon Feb 11 12:36:27 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
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.
>>> In fact, the NOR flash is only for users who don't have a debug board.
>>> Users that have a debug board can always recover via jtag. So making
>>> this dependent on the debug board is a perfect solution.
>> I can see the logic, but I can also see it puts us in a unique position
>> with it for the next couple of weeks until RTM, we're not going to be
>> able to generally update whatever it is we put in there subsequently.
> Well, that is the whole point :) the nor u-boot must be finished for
> emergency boots before shipping the product.
It seems Werner has that much working, so that end of the existing plan
>> 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:
> It's supposed to be an open device. Open not only in a way that you can
> write your own apps, but open also in the way that you can hack the OS.
> That you can in fact replace the OS, and run e.g. the (for GTA01
> existing) NetBSD port. There might be more
> Do you really believe this is the right step for an _open_ device?
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".
>> We can recover a bricked device with the debug board, it seems to me we
>> take so much care avoiding the one scenario we create a problem along
>> with definitively fixing the possibility of corruption and that has to
>> be balanced.
> _we_ can. We are the 'elite' who has those boards. In the future, 99.9%
> of all users will not have a debug board. What is the RMA strategy for
> people who accidentially bricked their devices? Where are the OpenMoko
> support centers in every major country that can do such a thing after
> sending in the device (without having to care about customs and
> excessive intercontinental shipping fees, ...)? Who is going yo pay for
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel