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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
