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, 25 Feb 2008 20:46:36 +0100
From:	"Alexander van Heukelum" <heukelum@...tmail.fm>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>, "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] reserve_early end-of-conventional-memory to 1MB

On Mon, 25 Feb 2008 10:13:17 -0800, "H. Peter Anvin" <hpa@...or.com>
said:
> Alexander van Heukelum wrote:
> > 
> >  arch/x86/kernel/head64.c |   45 +++++++++++++++++++++++++++------------------
> >  1 files changed, 27 insertions(+), 18 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
> > index 38f32e7..b684552 100644
> > --- a/arch/x86/kernel/head64.c
> > +++ b/arch/x86/kernel/head64.c
> > @@ -49,33 +49,42 @@ static void __init copy_bootdata(char *real_mode_data)
> >  	}
> >  }
> >  
> > -#define EBDA_ADDR_POINTER 0x40E
> > +#define BIOS_EBDA_SEGMENT 0x40E
> > +#define BIOS_LOWMEM_KILOBYTES 0x413
> >  
> 
> Linus has specific comments in the 32-bit code that states we do not 
> want to use address 0x413 for anything - if nothing else because it's 
> often lowered when there is boottime code involved like CD-ROM booting 
> or PXE.

Hello hpa,

I failed to find a comment referring to 0x413 or int 0x12 in
arch/x86/kernel. I do know the comment in Documentation/i386/boot.txt,
however, suggesting that "INT 12h" _should_ be used, but that it would
be pointless for zImage and old bzImage kernels, because they _have_
to be started from 0x90000 anyway. New bzImage kernels do not have
this limitation, and smart bootloaders simply put them at much
lower addresses, like 0x40000. (I know: you know.) My point is just
that the argument not to use 0x413 in the bootloader is not valid
for this case.

That leaves the possibility that code/data is inserted at the top of
conventional memory by either the BIOS or some kind of bootloader.
My view on this is that this code/data should be preserved: it
was specifically asked from us by lowering 0x413. One just loses
a tiny bit of usable memory, and if the program booting the kernel
knows better it can unload the driver if it wants to. It's just
not a kernel problem.

> Either way, the code should be shared between 32 and 64 bits.
> There is nothing bitsize-specific about it!

Of course. That's also why I already added the old-Dell case ;).
But one problem at a time, please!

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

-- 
http://www.fastmail.fm - I mean, what is it about a decent email service?

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

Powered by blists - more mailing lists