-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 is okay. >> 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/ > 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 > it? 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. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHsDM7OjLpvpq7dMoRAn6NAJ9yi+id44YUwRoqLNbMHEUX6gDRtACfaooR pohsuegyo5Lst1Jub/HotEM= =4YWY -----END PGP SIGNATURE-----