linux-kernel - Re: [PATCH] [RFC] be more verbose when probing EDD

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: <476C74F1.2070407@zytor.com>
Date:	Fri, 21 Dec 2007 18:22:41 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Andi Kleen <andi@...stfloor.org>
CC:	devzero@....de, linux-kernel@...r.kernel.org, Matt.Domsch@...l.com
Subject: Re: [PATCH] [RFC] be more verbose when probing EDD

Andi Kleen wrote:
>> Those don't live in an area of memory which is hard-limited to 32K.
> 
> Why not 64k?
> 

Because the bootloader needs some memory in the same segment that it 
controls.  Furthermore, since there were some residual uses of the 
0x9000 segment (now removed, but not all bootloaders could be easily 
fixed), we were limited to about 40K for everything.

Unfortunately we already have the problem that some bootloaders (notably 
LOADLIN and mknbi) hardcoded an arbitrary limit which was even smaller 
than that (about 16K, which we're already pushing up against.)

> Ok, that's a different argument than before. Ok. Although it's
> only a few bytes. 
> 
> I would lobby for any message at least contain the suggestion to try
> edd=off. That could save users a lot of time.

The important thing is that there is a message before and after.  The 
rest can be dealt with by Google on in documentation.  That's what the 
patch currently in x86setup.git does.

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