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

On Sun, 24 Feb 2008 20:41:21 +0100, "Ingo Molnar" <mingo@...e.hu> said:
> 
> * 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.

It's 1024 bytes below, but yes, the EBDA starts there. Then the first
two
bytes of the EBDA contain the value 0x0001, which means that its size is
1kb, so the BIOS is correct.

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

Correct. I thought it was new code, but looking more closely, the
behaviour
has indeed not changed recently (note to self: git log -p somefile.c
does
not indicate in any way that code was moved from some other place.)

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

No regressions, it's just cosmetic.

> 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).

Not really: ebda_addr is just a local variable. If the system needs to
find the start of the EBDA, it will just have to look at the 16 bit
value
at address 0x40E again.

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

The patch is exactly trying to do that. The code that was there seemed
to
imply that the author wanted to allocate whole pages, in such a way that
the allocation contained the whole EBDA. I think that is what it does
after this patch.

Greetings,
    Alexander
-- 
  Alexander van Heukelum
  heukelum@...tmail.fm

-- 
http://www.fastmail.fm - And now for something completely different

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