5 sec boot

[david at lang.hm]

On Fri, 3 Oct 2008, david at lang.hm wrote:

> On Fri, 3 Oct 2008, Jeremy Katz wrote:
>
>> On Fri, 2008-10-03 at 11:32 -0700, david at lang.hm wrote:
>>> On Fri, 3 Oct 2008, Mitch Bradley wrote:
>>>> david at lang.hm wrote:
>>>>> On Fri, 3 Oct 2008, Mitch Bradley wrote:
>>>>> if you don't need modules to boot, why do you need initrd? you should be
>>>>> able to just do everything from the main partition.
>>>> 
>>>> Our activation security system is in an initrd so that the firmware can 
>>>> check
>>>> its signature before booting it.  The whole security thing adds a bunch 
>>>> of
>>>> interesting wrinkles.
>>> 
>>> ouch. try to make the initrd do as little as possible.
>> 
>> The use of an initrd shouldn't have a substantial impact on boot time.
>> There should not be a significant fundamental difference in how long it
>> takes between booting into a userspace that happens to be from an
>> initrd, does a little bit and then switchroots vs booting into a
>> userspace off of a disk[1]
>> 
>> Jeremy
>> 
>> [1] With the one[2] obvious exception of "whatever is done in the initrd
>> takes time" -- but if those things are moved later, they still take the
>> same time.  And if they're not needed, don't do them.
>> [2] Also, there might be a tiny amount of time needed to uncompress the
>> initrd and un-cpio, but that really should be nominal.  If not, it means
>> other problems later in the boot sequence
>
> the default distro initrd images do a _lot_ of stuff that takes a significant 
> amount of time, but since the OLPC initrd is doing completely different stuff 
> it should not have the same problem, but that goes back to 'make it do as 
> little as possible'

one other thing, Tivo has shown that you don't need to have an initrd to 
lock a device down, you just need some partiton somewhere that you can 
check.

for that matter, if you were slightly crazy you could have the firmware 
check individual files on the filesystem, but keeping track of everything 
would be a mess.

however, you _could_ do something where you store your init security stuff 
in a filesystem image on your real filesystem (accessed via a loop mount 
type of thing), similar code to what grub uses to find files on the system 
could find the security filesystem. this would be more complicated then a 
seperate partition, but has the advantage that you only loose the space 
that you need for the security stuff.

David Lang