linux-kernel - Re: [Fastboot] [CFT] ELF Relocatable x86 and x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 04 Aug 2006 15:25:55 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Don Zickus <dzickus@...hat.com>
Cc:	fastboot@...l.org, Horms <horms@...ge.net.au>,
	Jan Kratochvil <lace@...kratochvil.net>,
	"H. Peter Anvin" <hpa@...or.com>,
	Magnus Damm <magnus.damm@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [Fastboot] [CFT] ELF Relocatable x86 and x86_64 bzImages

Don Zickus <dzickus@...hat.com> writes:

> On Mon, Jul 31, 2006 at 10:19:04AM -0600, Eric W. Biederman wrote:
>> 
>> I have spent some time and have gotten my relocatable kernel patches
>> working against the latest kernels.  I intend to push this upstream
>> shortly.
>> 
>> Could all of the people who care take a look and test this out
>> to make certain that it doesn't just work on my test box?
>
> Is there any reason to get following error on x86_64 using your patches?

There shouldn't be.

>  Filesystem type is ext2fs, partition type 0x83
> kernel /bzImage ro root=LABEL=/1 console=ttyS0,115200
> earlyprintk=ttyS0,115200
>    [Linux-bzImage, setup=0x1c00, size=0x24917c]
> initrd /initrd-2.6.18-rc3.img
>    [Linux-initrd @ 0x37e0d000, 0x1e25e7 bytes]
>
> .
> Decompressing Linux...
>
> length error
>
>  -- System halted
>
>
> I can get i386 to boot fine.  I can't for the life of me figure out what I
> am doing wrong..

The length error comes from lib/inflate.c 

I think it would be interesting to look at orig_len and bytes_out.

My hunch is that I have tripped over a tool chain bug or a weird
alignment issue.

The error is the uncompressed length does not math the stored length
of the data before from before we compressed it.  Now what is
fascinating is that our crc's match (as that check is performed first).

Something is very slightly off and I don't see what it is.

After looking at the state variables I would probably start looking
at the uncompressed data to see if it really was decompressing
properly.  If nothing else that is the kind of process that would tend
to spark a clue.

Eric

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