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: <86802c440806121329s54bb1e6dobaaa15c26e7dc81c@mail.gmail.com>
Date:	Thu, 12 Jun 2008 13:29:20 -0700
From:	"Yinghai Lu" <yhlu.kernel@...il.com>
To:	"Paul Jackson" <pj@....com>, "Andi Kleen" <andi@...stfloor.org>,
	"H. Peter Anvin" <hpa@...or.com>
Cc:	mingo@...e.hu, bwalle@...e.de, hannes@...urebad.de,
	ying.huang@...el.com, linux-kernel@...r.kernel.org, steiner@....com
Subject: Re: Confusions with reserve_early, reserve_bootmem, e820, efi, ... on x86_64

On Thu, Jun 12, 2008 at 1:10 PM, Paul Jackson <pj@....com> wrote:
> Yinghai wrote:
>> that function seems to increase the ebda to workaround some broken
>> machine blindly.
>
> Yes, true.
>
> The reserve_ebda_region() has probably been like that for a while;
> do you understand why it would be a problem conflicting with the
> EFI memmap only now?
>
> My other two concerns remain as well:
>
>  2) Is what amounts to a change from calling reserve_bootmem()
>    to calling reserve_early(), at the end of reserve_ebda_region()
>    in the 32 bit case (now that it is merged with the 64 bit code)
>    understood to be a desired and correct change?
>
>  3) There has been quite a few patches restructuring this early
>    memory reservation code over the last week.  What is the
>    state of that work ... is it still "in progress" or is it
>    thought to be complete?

please check that commit that increase the range to 1M.
it seems at that time, andi and peter had different idea, because
increase 1M could waste K bytes memory.

also wonder if EFI is there, we still need to ebda?

YH

commit f6eb62b6924b99ec7da97fb6f554685a9ad6dce4
Author: Alexander van Heukelum <heukelum@...lshack.com>
Date:   Mon Feb 25 19:07:51 2008 +0100

    x86: reserve_early end-of-conventional-memory to 1MB, 64-bit

    Explicitly reserve_early the whole address range from the end of
    conventional memory as reported by the bios data area up to the
    1Mb mark. Regard the info retrieved from the BIOS data area with
    a bit of paranoia, though, because some biosses forget to register
    the EBDA correctly.

    Signed-off-by: Alexander van Heukelum <heukelum@...tmail.fm>
    Signed-off-by: Ingo Molnar <mingo@...e.hu>

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

+/*
+ * The BIOS places the EBDA/XBDA at the top of conventional
+ * memory, and usually decreases the reported amount of
+ * conventional memory (int 0x12) too.
+ */
 static __init void reserve_ebda(void)
 {
-       unsigned ebda_addr, ebda_size;
+       unsigned int lowmem, ebda_addr;

-       /*
-        * there is a real-mode segmented pointer pointing to the
-        * 4K EBDA area at 0x40E
-        */
-       ebda_addr = *(unsigned short *)__va(EBDA_ADDR_POINTER);
+       /* end of low (conventional) memory */
+       lowmem = *(unsigned short *)__va(BIOS_LOWMEM_KILOBYTES);
+       lowmem <<= 10;
+
+       /* start of EBDA area */
+       ebda_addr = *(unsigned short *)__va(BIOS_EBDA_SEGMENT);
        ebda_addr <<= 4;

-       if (!ebda_addr)
-               return;
+       /* Fixup: bios puts an EBDA in the top 64K segment */
+       /* of conventional memory, but does not adjust lowmem. */
+       if ((lowmem - ebda_addr) <= 0x10000)
+               lowmem = ebda_addr;

-       ebda_size = *(unsigned short *)__va(ebda_addr);
+       /* Fixup: bios does not report an EBDA at all. */
+       /* Some old Dells seem to need 4k anyhow (bugzilla 2990) */
+       if ((ebda_addr == 0) && (lowmem >= 0x9f000))
+               lowmem = 0x9f000;

-       /* Round EBDA up to pages */
-       if (ebda_size == 0)
-               ebda_size = 1;
-       ebda_size <<= 10;
-       ebda_size = round_up(ebda_size + (ebda_addr & ~PAGE_MASK), PAGE_SIZE);
-       if (ebda_size > 64*1024)
-               ebda_size = 64*1024;
+       /* Paranoia: should never happen, but... */
+       if (lowmem >= 0x100000)
+               lowmem = 0xa0000;

-       reserve_early(ebda_addr, ebda_addr + ebda_size, "EBDA");
+       /* reserve all memory between lowmem and the 1MB mark */
+       reserve_early(lowmem, 0x100000, "BIOS reserved");
 }

 void __init x86_64_start_kernel(char * real_mode_data)
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ