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]

Message-ID: <m1bqqzoc5q.fsf@ebiederm.dsl.xmission.com>
Date:	Sat, 05 Aug 2006 01:49:05 -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:

>> 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.
>
> I thought so too, but I took vmlinuz images from people (Vivek) who had it
> boot on their systems but those images still failed on my two machines.  

Odd.  That might narrow things down.  This is just booting with grub
so there is no relocation specific weirdness coming into play.

>> 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.
>
> I printed out orig_len -> 5910532 (which matches vmlinux.bin)
>              bytes_out -> 5910531

Is the last byte of vmlinux.bin 0?

One byte off certainly, fits my patter of something slightly off.

>> 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.
>
> I am not familiar with the code, so very few sparks are flying.  I'll
> still dig through though.  Thanks for the tips.

Welcome.

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/