please don't switch to kexec (was Re: R70/R71 on debug v3 board ?)

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

>> 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 :)

Can be so.

>>>> 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.

Allocate kmalloc() memory, pull the new OS image from the filesystem
into memory, maybe call the suspend() functions to kill DMA and so on,
turn off interrupts and fiq and jump into the image you loaded.  After
all we only want to do what U-Boot is doing to start that image and that
really can't be so hard.

>> 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.

Why does MMU matter... if you're leaving the Linux OS side as if you go
to suspend or as if you shut down, there are no more expectations about
the system memory state from the Linux side.  All you need is a linear
allocation with the new OS image load into already to jump into.

> 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)

Linux is dead and finished by the time we jump into the new OS image,
they never run concurrently.  Linux thinks it did a suspend or a
shutdown so all DMA is over and device states are idle.

> 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, ...

No demo code would be needed, you use the same BSD image or whatever it
is you would have used with U-Boot.  You might have to change the image
start address in RAM if it needs to know it, dunno what that is like on BSD.

Anyway there is zero "open-ness" dimension to kexec that isn't there for
U-Boot with this chainloading concept.

>> 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

Yes well the scenario I am hoping for really is that after a year we all
have a laugh about "do you remember we used to work with U-Boot and run
around cutting and pasting Linux drivers into it -- doing and debugging
everything twice - ha ha ha !" as we drink beer.  Then it will weird us
out to press aux and come up in stale old U-Boot, we will want to have a
shiny new kexec in there -- well I guess we can do it anyway.

Alright, let's keep the NOR lock resistors :-)

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHsEMrOjLpvpq7dMoRAtFSAKCDO9cuywRxZA+wr5cYbm95V4GJOgCeJMqd
2YjqfmBHvKoFKno9ULqYtl4=
=cKiZ
-----END PGP SIGNATURE-----