[U-Boot] RFC: postload: Loading some U-Boot code later

[U-Boot] RFC: postload: Loading some U-Boot code later

[Simon Glass]

Hi,

I am looking to implement a feature where a cut-down U-Boot is
initially loaded, which is enough for a normal boot. But then when an
abnormal boot is required (e.g. from a USB stick or network), we can
load more code to cope with it.

Why?
- Improves security by not loading code that we shouldn't execute
- Speeds up boot by loading less code (we are targeting very fast boot
time and 100ms is worth chasing)

My current thinking is a system where the optional code is kept at the
end of the image in a post-load area and loaded when needed. Given
that, I am thinking:

1. We use the CONFIG items to find object files which can be made
optional. For example, CONFIG_CMD_ECHO controls whether cmd_echo.o is
linked in. So if we don't need the echo command in the normal case we
can move it to the 'post-load' area.

2. More extreme: we could do a build of a cut-down U-Boot for analysis
purposes, and compare the functions linked with those in the full
U-Boot. When building the full U-Boot, all the functions which are not
in the cut-down one can go into post-load.

2a. For simplicity, don't do anything special with data and bss -
these stay at full size.

3. Control the build using a new 'build-select' file which specifies
which CONFIG items are essential and which are normally not needed.

4. We need to adjust the link script to move the objects around. The
generation of (parts of) this link script would need to be under
control of the build-select file.

5. Provide a function like postload_load_chunk() which loads a chunk
of code when we decide we need it. This can be called within U-Boot
when/if needed. It loads the code from flash, relocates it and returns
with everything ready.

I am interested in any thoughts that people have about this:

- has this been done before, or something similar?
- any hints, tips, dragon warnings?
- does the above approach sound reasonable?

Thanks,
Simon

[U-Boot] RFC: postload: Loading some U-Boot code later

[Wolfgang Denk]

Dear Simon Glass,

In message <CAPnjgZ0Y7Lnu6KiOsm8Q4qFqNeZh0wg3txFFiTqhzPZUW8Weig@mail.gmail.com> you wrote:
> 
> I am looking to implement a feature where a cut-down U-Boot is
> initially loaded, which is enough for a normal boot. But then when an
> abnormal boot is required (e.g. from a USB stick or network), we can
> load more code to cope with it.
...
> - has this been done before, or something similar?

This has been done before, since the very earliest versions of U-Boot
(or PPCboot, as it was called at that times).  The feature is called
standalone applications.  There are _many_ systems around where you
can load (and run) manufacturing test code, hardware diagnosis code,
burn in test stuff, proprietary code to perform top secret actions
nobody ever may know, etc.

> - any hints, tips, dragon warnings?
> - does the above approach sound reasonable?

I understand what you want, and why you want it.  But I disagree with
the suggested implementation.

If you just need a simple environment, you can probably do well with
the existing standalone approach.

If you are looking for a more powerful solution, that is more tightly
integrated with the rest of the U-Boot code (**) then we should make
the jump and implement loadable modules.  This has been done before,
too - see Linux for a big example, or barebox for a smaller, more
U-Boot-like one.

(**) The separation and restriction of the standalone code is an
     intentional one, made not for technical but for political
     reasons - standalone applications are provided as a means to run
     closed-source, proprietary code.  This is something that has to
     hurt a bit.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
How many QA engineers does it take to screw in a lightbulb? 3:  1  to
screw it in and 2 to say "I told you so" when it doesn't work.

[U-Boot] RFC: postload: Loading some U-Boot code later

[Simon Glass]

Hi Wolfgang,

Thanks for the response.

On Thu, Jul 28, 2011 at 7:45 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> In message <CAPnjgZ0Y7Lnu6KiOsm8Q4qFqNeZh0wg3txFFiTqhzPZUW8Weig@mail.gmail.com> you wrote:
>>
>> I am looking to implement a feature where a cut-down U-Boot is
>> initially loaded, which is enough for a normal boot. But then when an
>> abnormal boot is required (e.g. from a USB stick or network), we can
>> load more code to cope with it.
> ...
>> - has this been done before, or something similar?
>
> This has been done before, since the very earliest versions of U-Boot
> (or PPCboot, as it was called at that times). ?The feature is called
> standalone applications. ?There are _many_ systems around where you
> can load (and run) manufacturing test code, hardware diagnosis code,
> burn in test stuff, proprietary code to perform top secret actions
> nobody ever may know, etc.

In my case I am just wanting to run U-Boot code. It seems to me that
the standalone code is for being able to jump to a binary which can
still find and call U-Boot functions.

>
>> - any hints, tips, dragon warnings?
>> - does the above approach sound reasonable?
>
> I understand what you want, and why you want it. ?But I disagree with
> the suggested implementation.
>
> If you just need a simple environment, you can probably do well with
> the existing standalone approach.

Hmmm so I think I would need to build some of the U-Boot code into a
separate binary.

>
> If you are looking for a more powerful solution, that is more tightly
> integrated with the rest of the U-Boot code (**) then we should make
> the jump and implement loadable modules. ?This has been done before,
> too - see Linux for a big example, or barebox for a smaller, more
> U-Boot-like one.

OK I can certainly see how this could work. My idea is more along the
lines that there is a single 'virtual' U-Boot code image, but we just
don't have access to it all at the start. With modules we would
presumably enhance the y/n CONFIG items to support an 'm' option. We
would likely end up with one module per CONFIG item. Then the question
arises as to how to detect when a module is needed and load it. Also
there is the issue of load overhead - since some modules may only be
<1KB each. That suggests the idea of grouping functions into modules,
like a NET module.

It sounds like a lot of work! Is there a general use for it?

>
> (**) The separation and restriction of the standalone code is an
> ? ? intentional one, made not for technical but for political
> ? ? reasons - standalone applications are provided as a means to run
> ? ? closed-source, proprietary code. ?This is something that has to
> ? ? hurt a bit.

OK I understand that. Everything we are doing is open source here.

Regards,
Simon

>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> How many QA engineers does it take to screw in a lightbulb? 3: ?1 ?to
> screw it in and 2 to say "I told you so" when it doesn't work.
>