Booting large kernels

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Booting large kernels

Rickard Dahlstrand
Hi,

While working on Flashboot myself and Jakob had a discussion on what
factors are involved when booting large (~25mb) kernels. We came to the
conclusion that we didn't really know. I'm forwarding this email from
the flashboot-list if anyone can help us explain what factors are
involved and what can be done to make this process more secure.

Thanks, Rickard.

-------- Original Message --------
Subject: Re: [flashboot] Updated patch
Date: Mon, 04 Sep 2006 14:55:43 +0200
From: Rickard Dahlstrand <[hidden email]>
To: Massimo Lusetti <[hidden email]>
CC: [hidden email], Jakob Schlyter <[hidden email]>
References: <[hidden email]>
<[hidden email]>



Massimo Lusetti wrote:

> On Fri, 2006-09-01 at 11:48 +0200, Rickard Dahlstrand wrote:
>
>  
>> Hi All,
>>
>> On popular request here are some updated diffs with bugfixes and
>> cleanups, the ro/rw-scripts are committed and blink got scraped. Please
>> test and comment.
>>
>>    
>
> ./build-largekernel.sh GENRIC-RD produce a kernel which doesn't boot, it
> stops loading the 'second stage' during the boot phase even before
> starting to outputting the result of the boot process (dmesg).
> The result is the box continuisly rebooting while uncompressing/loading
> the kernel.
>  
That was what we suspected. What factors that are involved when booting
large kernels are a bit of a mystery to us. The 25 mb WRAP12 kernel
boots fine on my 128 MB WRAP-box. But the generic is a bit larger and
could possibly cause problems.

This is what Damien wrote on the subject:
/A couple of caveats regarding kernel customisation: First, if your
kernel+ramdisk blob is larger than 16Mb, then you will need to increase
NKPTP in the kernel config (just uncomment the entry in the file, it's
good for 32Mb kernels). The symptom of a kernel with a too-small NKPTP
is an immediate crash or reboot after the kernel is loaded. Another
caveat is that kernels larger than about 14Mb in size will use up all
the ISA DMA memory and the kernel will panic at boot unless isadma is
disabled in the config or via UKC. This leads to the final problem: if
isadma is disabled, then things that attempt to use it (e.g. floppy disk
access) will panic the kernel. The best solution is to try to keep your
kernels small./

As far as I can tell both of these are done for all kernels:
http://cvsweb.mindrot.org/index.cgi/flashboot/GENERIC-RD.diff?r1=1.7;r2=1.8

And then we have this where Damien had some kind of idea on what could
be done: http://cvsweb.mindrot.org/index.cgi/flashboot/TODO?rev=1.6

I'm afraid that I understand to little on this, we need an expert.

Until we get some facts here people should only use the large-kernel
option if tested properly and on systems with console access and a
backup obsd-kernel.

Rickard.

Reply | Threaded
Open this post in threaded view
|

Re: Booting large kernels

Tobias Weingartner-2
On Tuesday, September 5, Rickard Dahlstrand wrote:
>
> While working on Flashboot myself and Jakob had a discussion on what
> factors are involved when booting large (~25mb) kernels. We came to the
> conclusion that we didn't really know. I'm forwarding this email from
> the flashboot-list if anyone can help us explain what factors are
> involved and what can be done to make this process more secure.

I'm not sure what you're asking.  What do you mean by "factors", and
what do you mean by "more secure".


> > ./build-largekernel.sh GENRIC-RD produce a kernel which doesn't boot, it
> > stops loading the 'second stage' during the boot phase even before
> > starting to outputting the result of the boot process (dmesg).
> > The result is the box continuisly rebooting while uncompressing/loading
> > the kernel.

How large a kernel?

> That was what we suspected. What factors that are involved when booting
> large kernels are a bit of a mystery to us. The 25 mb WRAP12 kernel
> boots fine on my 128 MB WRAP-box. But the generic is a bit larger and
> could possibly cause problems.

First and foremost, there is the issue of memory.  Is there a full
contiguous 25MB available starting at the 2MB boundary in your machine?
Plus some extra for the BSS, heap, etc?  Are you sure that chewing up
25MB of static, physically contiguous kvm does not violate some sort
of assumption in the uvm layer, in the pmap layer, in locore, or in
machdep?  Most likey it does...

> This is what Damien wrote on the subject:
> /A couple of caveats regarding kernel customisation: First, if your
> kernel+ramdisk blob is larger than 16Mb, then you will need to increase
> NKPTP in the kernel config (just uncomment the entry in the file, it's
> good for 32Mb kernels). The symptom of a kernel with a too-small NKPTP
> is an immediate crash or reboot after the kernel is loaded. Another
> caveat is that kernels larger than about 14Mb in size will use up all
> the ISA DMA memory and the kernel will panic at boot unless isadma is
> disabled in the config or via UKC. This leads to the final problem: if
> isadma is disabled, then things that attempt to use it (e.g. floppy disk
> access) will panic the kernel. The best solution is to try to keep your
> kernels small./

Sure, that is one issue.  I'm sure there are going to be others.  For
example, lots of machines have holes at just below the 16MB boundary.
You sure you're not trampling some sort of BIOS memory?  Or even I/O
space for the on-board video?  There is a reason we did the things we
did.

> As far as I can tell both of these are done for all kernels:
> http://cvsweb.mindrot.org/index.cgi/flashboot/GENERIC-RD.diff?r1=1.7;r2=1.8
>
> And then we have this where Damien had some kind of idea on what could
> be done: http://cvsweb.mindrot.org/index.cgi/flashboot/TODO?rev=1.6
>
> I'm afraid that I understand to little on this, we need an expert.

Ok, this reminds me of young kids wanting to go fast.  They go out, buy
a turbo-charged car, and start modifying it.  Before long they find out
that raising the boost makes more power.  And invariably, they don't
understand what they are doing, and end up blowing up their engine.

You've taken the first step, you've recognized what you don't know.  :)
Now young pedouin, go forth, and learn about the x86 architecture and
the BIOS.  Then read the code for /boot and locore/machdep.  Your answers
are all there... :)

--Toby.