Re: [PATCH 3/7] inflate pt1: clean up input logic

[Matt Mackall <mpm@selenic.com>]

On Sat, Feb 25, 2006 at 10:57:49PM +0000, Russell King wrote:
> On Sat, Feb 25, 2006 at 04:37:37PM -0600, Matt Mackall wrote:
> > On Sat, Feb 25, 2006 at 09:58:50PM +0000, Russell King wrote:
> > > 1. kernel is loaded.
> > > 2. firmware scans loaded kernel, finds gzip magic numbers (the compressed
> > >    kernel.)
> > > 3. firmware sets initrd pointeres to point at the compressed kernel.
> > > 4. firmware calls kernel decompressor.
> > > 5. kernel decompresses and self-relocates.
> > > 6. compressed kernel image is thereby partly corrupted.
> > > 7. kernel boots.
> > > 8. kernel tries to decompress the compressed kernel image.
> > > 9. decompressor gets confused and tries to gobble more data than is
> > >    available.
> > > 10. kernel sits there being a dumb fuck.
> > 
> > Why are we attempting to decompress the kernel image again? Accident?
> 
> The firmware is trying to be "clever" - looking in the object it TFTP'd
> for the gzip magic numbers and assuming that any it finds are an initrd.
> The firmware then points the kernel at the start of that gzipped image.
> 
> The fact that a zImage contains the gzip magic numbers never occurred to
> the people who implemented this misfeature in the firmware.  It is a
> misfeature because:
> 
> 1. this exact problem - that a zImage contents can be mistaken for an initrd.
> 2. an initrd doesn't have to be compressed with gzip.
> 3. an initrd may contain gzip markers which do not relate to the start of
>    the initrd.
> 
> > > > In my mind, being unable to decompress init* is every bit as fatal as
> > > > being unable to mount root.
> > > 
> > > It's very simple.  With fix, the kernel successfully boots on these
> > > machines.  Without fix, the kernel hangs on these machines for _no_
> > > good reason other than the firmware did something that was stupid.
> > 
> > And how does this work currently? We attempt to decompress the kernel
> > a second time, give up and move on?
> 
> Yes.
> 
> > Assuming we can write to the compressed image (and thereby corrupt
> > it), wouldn't it be better to just stomp on the gzip magic and spare
> > us the overhead of decompressing it twice?
> 
> That's not guaranteed, so is impossible to do in the boot time
> decompressor.
> 
> > > I'm sorry, I just do not see why you're being soo bloody difficult
> > > over this.
> > 
> > Because it's taken this long to get close to an explanation of what
> > the problem is.
> 
> $#%@%#$%#@!!!  I really think you're intentionally trying to wind me up
> through this whole thread.
>
> The email:
> 
>   http://www.ussg.iu.edu/hypermail/linux/kernel/0312.2/1024.html
> 
> contains a full and clear explaination of the situation.  The second
> paragraph of that email is key to understanding the problem and makes
> it absolutely clear what is trying to be decompressed as the initrd
> (the corrupted compressed piggy).

It was neither full nor clear to me at least. But the above clarifies
it enough that I understand what all the fuss is about, thanks. I'm
back to the drawing board; I'll add an underflow path back in.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/