linux-kernel - Re: [PATCH] Fix alignment of early reservation for EBDA

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:	Sun, 24 Feb 2008 20:41:21 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Alexander van Heukelum <heukelum@...lshack.com>
Cc:	Andi Kleen <ak@...e.de>, Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Alexander van Heukelum <heukelum@...tmail.fm>
Subject: Re: [PATCH] Fix alignment of early reservation for EBDA


* Alexander van Heukelum <heukelum@...lshack.com> wrote:

> Hi Andi,
> 
> My eyes fell on the following table in the boot messages:
> 
> early res: 0 [0-fff] BIOS data page
> early res: 1 [6000-7fff] SMP_TRAMPOLINE
> early res: 2 [200000-374557] TEXT DATA BSS
> early res: 3 [9fc00-a0bff] EBDA
> early res: 4 [8000-afff] PGTABLE
> 
> The memory reserved for the EBDA overflows into the area normally 
> reserved for the VGA adaptor. It seems that you wanted to force the 
> allocation to cover whole pages, like:

well, that's what your EBDA descriptor says - it's set to 9fc00 which is 
512 bytes below the VGA range. This behavior didnt really change over 
v2.6.24 (which reserved 'into' the VGA range too), it's just that in 
v2.6.25 we also print out these early reservations. Can you see any 
regression? There should be no harm from overlapping into the VGA range 
- these "reservations" only make RAM unavailable for normal allocations.

your patch on the other hand rounds the EBDA area down which could in 
theory be unsafe on other boxes (where there could be real RAM above the 
EBDA area): the safest approach is to round the beginning of it down, 
the end of it up (to page boundary). Your patch _should_ be OK, but in 
practice it doesnt hurt to reserve a bit more around the edges than to 
accidentally give a page to the OS that the BIOS might rely upon.

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