[U-Boot] RFC: postload: Loading some U-Boot code later
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
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
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@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.
participants (2)
-
Simon Glass -
Wolfgang Denk