linux-kernel - Re: [PATCH v2] mm/hotplug, x86: Disable ARCH_MEMORY

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:	Tue, 23 Jul 2013 10:01:01 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Toshi Kani <toshi.kani@...com>
Cc:	akpm@...ux-foundation.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, x86@...nel.org, dave@...1.net,
	kosaki.motohiro@...il.com, isimatu.yasuaki@...fujitsu.com,
	tangchen@...fujitsu.com, vasilis.liaskovitis@...fitbricks.com
Subject: Re: [PATCH v2] mm/hotplug, x86: Disable ARCH_MEMORY_PROBE by default

* Toshi Kani <toshi.kani@...com> wrote:

> > Could we please also fix it to never crash the kernel, even if stupid 
> > ranges are provided?
> 
> Yes, this probe interface can be enhanced to verify the firmware 
> information before adding a given memory address.  However, such change 
> would interfere its test use of "fake" hotplug, which is only the known 
> use-case of this interface on x86.

Not crashing the kernel is not a novel concept even for test interfaces...

Where does the possible crash come from - from using invalid RAM ranges, 
right? I.e. on x86 to fix the crash we need to check the RAM is present in 
the e820 maps, is marked RAM there, and is not already registered with the 
kernel, or so?

> In order to verify if a given memory address is enabled at run-time (as 
> opposed to boot-time), we need to check with ACPI memory device objects 
> on x86.  However, system vendors tend to not implement memory device 
> objects unless their systems support memory hotplug.  Dave Hansen is 
> using this interface for his testing as a way to fake a hotplug event on 
> a system that does not support memory hotplug.

All vendors implement e820 maps for the memory present at boot time.

How is the testing done by Dave Hansen? If it's done by booting with less 
RAM than available (via say the mem=1g boot parameter), and then 
hot-adding some of the missing RAM, then this could be made safe via the 
e820 maps and by consultig the physical memory maps (to avoid double 
registry), right?

How does the hotplug event based approach solve double adds? Relies on the 
hardware not sending a hot-add event twice for the same memory area or for 
an invalid memory area, or does it include fail-safes and double checks as 
well to avoid double adds and adding invalid memory? If yes then that 
could be utilized here as well.

I.e. fragility of an interface is our choice, not some natural given 
property.

Thanks,

	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/