linux-kernel - Re: [PATCH] THE LINUX/I386 BOOT PROTOCOL

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: <44F21122.3030505@zytor.com>
Date:	Sun, 27 Aug 2006 14:39:46 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Andi Kleen <ak@...e.de>
CC:	Alon Bar-Lev <alon.barlev@...il.com>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	johninsd@....rr.com, Matt_Domsch@...l.com
Subject: Re: [PATCH] THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit
 (ping)

Andi Kleen wrote:
> On Sunday 27 August 2006 21:32, H. Peter Anvin wrote:
>> Andi Kleen wrote:
>>> Just increasing that constant caused various lilo setups to not boot
>>> anymore. I don't know who is actually to blame, just wanting to
>>> point out that this "obvious" patch isn't actually that obvious.
>>>
>> How would that even be possible (unless you recompiled LILO with the new 
>> headers)?  There would be no difference in the memory image at the point 
>> LILO hands off to the kernel.
> 
> AFAIK the problem was that some EDD data got overwritten.
> 
>> In order to reproduce this we need some details about your "various LILO 
>> setups", or this will remain as a source of cargo cult programming.
> 
> You can search the mailing list archives, it's all in there if you don't
> belive me.
> 

Found the references.  This seems to imply that EDD overwrites the area 
used by LILO 22.6.1.  LILO 22.6.1 uses the new boot protocol, with the 
full pointer, and seems to obey the spec as far as I can read the code. 
  I'm going to try to run it in simulation and observe the failure that way.

However, something is still seriously out of joint.  The EDD data 
actually overlays the setup code, not the bootsect code, and thus there 
"shouldn't" be any way that this could interfere.  My best guess at this 
time is that either the EDD code or LILO uses memory it's not supposed 
to use, and the simulation should hopefully reveal that.

Sorry if I seem snarky on this, but if we can't get to the bottom of 
this we can't ever fix it.

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