linux-kernel - Re: [2.6.27] overlapping early reservations [was: early exception

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:	Mon, 8 Sep 2008 19:54:44 +0200
From:	"Luca Tettamanti" <kronos.it@...il.com>
To:	"Yinghai Lu" <yhlu.kernel@...il.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>, "H. Peter Anvin" <hpa@...nel.org>,
	"Peter Zijlstra" <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, mingo@...hat.com
Subject: Re: [2.6.27] overlapping early reservations [was: early exception - lockdep related?]

On Sat, Sep 6, 2008 at 6:06 PM, Yinghai Lu <yhlu.kernel@...il.com> wrote:
> On Sat, Sep 6, 2008 at 7:51 AM, Ingo Molnar <mingo@...e.hu> wrote:
>>
>> * Luca Tettamanti <kronos.it@...il.com> wrote:
>>
>>> On Fri, Sep 5, 2008 at 10:18 PM, H. Peter Anvin <hpa@...nel.org> wrote:
>>> > Peter Zijlstra wrote:
>>> >>
>>> >> On Fri, 2008-09-05 at 21:17 +0200, Luca Tettamanti wrote:
>>> >>>
>>> >>> On Thu, Sep 4, 2008 at 10:51 PM, Luca Tettamanti <kronos.it@...il.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> On Thu, Sep 4, 2008 at 4:25 PM, Peter Zijlstra <peterz@...radead.org>
>>> >>>> wrote:
>>> >>>>>
>>> >>>>> Sadly your config just boots, albeit not to userspace due to missing
>>> >>>>> drivers.
>>> >>>>
>>> >>>> Yes, I managed to boot it with qemu... I tried kgdb - without luck -
>>> >>>> kernel dies too early.
>>> >>>> I also managed to get a stack trace :D
>>> >>>>
>>> >>>> http://img151.imageshack.us/my.php?image=tracedm1.jpg
>>> >>>>
>>> >>>> It seems that lockdep is an innocent bystander... the kernel died with
>>> >>>> panic() in __reserve_early, and then took another exception while
>>> >>>> printing the panic (I guess).
>>> >>>> Will add further debug stuff to see wtf is going on.
>>> >>>
>>> >>> Hum, kernel says:
>>> >>>
>>> >>> http://img177.imageshack.us/my.php?image=overlappingus2.jpg
>>> >>>
>>> >>> Overlapping early reservations b98000-eff266 RAMDISK to 200000-d09cf7
>>> >>> TEXT DATA BSS
>>> >>>
>>> >>> It would appear that the initramfs is overlapping the kernel itself,
>>> >>> is the boot loader (LILO) doing something stupid?
>>> >>
>>> >> Suppose it is, lets ask hpa..
>>> >>
>>> >
>>> > It definitely looks like it.
>>>
>>> Is there anything that the kernel could to do confuse lilo? The issue
>>> started appearing with 2.6.27 and the outcome of the boot process
>>> varies between versions and seems sensitive to configuration changes
>>> (though a "bad" kernel consistently fails).
>>
>> good question. Does your successful 2.6.26 bootup actually _depend_ on
>> the initrd? Or does it perhaps have enough built-in drivers that make it
>> boot just fine?
>>
>> in that case v2.6.26 might just have stomped on the initrd silently,
>> corrupted it (during kernel decompress), and the initrd unpacker saw the
>> corruption and ignored it. Userspace wouldnt care as the kernel had all
>> the drivers it needed.
>>
>> or perhaps something made your v2.6.27 bzImage larger so that the
>> overlap happens - while it didnt before.
>>
>>> Orthogonal to my problem: the panic() in reserve_early is useless for
>>> debugging since the output won't reach the screen or the serial
>>> console (even worse: the kernel takes an exception while trying to
>>> execute the panic). Is it acceptable to replace it with an
>>> early_printk + hlt?
>>
>> very much so. I was wondering about that already.
>
> console=uart8250,io,0x3f8,115200n8
> could help

Nope, parse_early_param() is called in start_kernel(), my kernel dies
way before it...

> wonder if lilo is fixing bzImage from 1M, and when it is calculating
> pos of ramdisk...base that
> later on-same-position uncompressing, put vmlinux from 2M...

How does LILO decides where to put the initrd (I find LILO code...
obscure)? I mean, it gets a compressed image: how does it know the
size of the uncompressed kernel image? Is it the payload_length in the
real mode header? (answer to self: no, it appears to be the compressed
payload).

> wonder if new lilo could help.

I'm already using the latest version.

Luca
--
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/