linux-kernel - Re: Use of memmap= to forcibly recover memory in 3GB-4GB range

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] [day] [month] [year] [list]

Message-ID: <50F812B5.5050507@fold.natur.cuni.cz>
Date:	Thu, 17 Jan 2013 16:03:17 +0100
From:	Martin Mokrejs <mmokrejs@...d.natur.cuni.cz>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	Alex Villacís Lasso <a_villacis@...osanto.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Use of memmap= to forcibly recover memory in 3GB-4GB range -
 is this safe?

Yinghai Lu wrote:
> On Wed, Jan 16, 2013 at 4:24 PM, Alex Villacís Lasso
> <a_villacis@...osanto.com> wrote:
>> El 16/01/13 02:11, Yinghai Lu escribió:
>>
>>> On Tue, Jan 15, 2013 at 5:47 PM, Alex Villacís Lasso
>>> <a_villacis@...osanto.com> wrote:
>>>>
>>>> [    0.000000] e820: BIOS-provided physical RAM map:
>>>> [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009f3ff]
>>>> usable
>>>> [    0.000000] BIOS-e820: [mem 0x000000000009f400-0x000000000009ffff]
>>>> reserved
>>>> [    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff]
>>>> reserved
>>>> [    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000cf58ffff]
>>>> usable
>>>> [    0.000000] BIOS-e820: [mem 0x00000000cf590000-0x00000000cf5e2fff]
>>>> ACPI
>>>> NVS
>>>> [    0.000000] BIOS-e820: [mem 0x00000000cf5e3000-0x00000000cf5effff]
>>>> ACPI
>>>> data
>>>> [    0.000000] BIOS-e820: [mem 0x00000000cf5f0000-0x00000000cf5fffff]
>>>> reserved
>>>> [    0.000000] BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff]
>>>> reserved
>>>> [    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000ffffffff]
>>>> reserved
>>>> [    0.000000] NX (Execute Disable) protection: active
>>>
>>> ..
>>>>
>>>> [    0.000000] original variable MTRRs
>>>> [    0.000000] reg 0, base: 4GB, range: 512MB, type WB
>>>> [    0.000000] reg 1, base: 4608MB, range: 256MB, type WB
>>>> [    0.000000] reg 2, base: 0GB, range: 2GB, type WB
>>>> [    0.000000] reg 3, base: 2GB, range: 1GB, type WB
>>>> [    0.000000] reg 4, base: 3GB, range: 256MB, type WB
>>>> [    0.000000] reg 5, base: 3319MB, range: 1MB, type UC
>>>> [    0.000000] reg 6, base: 3320MB, range: 8MB, type UC
>>>> [    0.000000] reg 7, base: 3318MB, range: 1MB, type UC
>>>> [    0.000000] total RAM covered: 4086M
>>>
>>> Can you apply attached debug patch to see if the raw e820 is right from
>>> BIOS ?
> 
>> Done. The output is attached. I see no difference between raw and sanitized
>> maps.
> 
> yeah, it is BIOS problem.
> 
> you may either live with memmap= or try to get one BIOS update.

Hi Yinghai,
  wouldn't it be useful for other to include this patch into the kernel? It might help
someone else. Provided it is printed only when extra debug is enabled in the kernel
I don't think it hurts. Right?
  Actually, if it could do the check for differences automatically and print a warning
it would be even better.
Martin
--
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/