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: <749bfac7-00b9-0350-18b7-2c3388646853@arm.com>
Date:   Tue, 4 Jan 2022 09:46:10 +0530
From:   Anshuman Khandual <anshuman.khandual@....com>
To:     David Hildenbrand <david@...hat.com>,
        linux-arm-kernel@...ts.infradead.org
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        James Morse <james.morse@....com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2] arm64/mm/hotplug: Warn when memory limit has been
 reduced



On 1/3/22 6:27 PM, David Hildenbrand wrote:
> 
>>> Via which mechanism would the unplug of that memory happen? On arm64,
>>> this should only be possible via ACPI, when unplugging a DIMM that was
>>> available since boot.
>>>
>>> But won't acpi_memory_enable_device() try adding that memory while
>>> ignoring the memory limit? And adding should work, no?
>>
>> Adding that memory via hotplug into the kernel first ? In that case
>> removal would still go via the kernel and user would know about it.
> 
> Can we please add details on how to actually trigger it (below) to the
> patch description? Otherwise it's really hard to get about which senario
> we do care, and about which we don't care.

Sure, will try and add those details in the commit message.

> 
>>
>>>
>>> Can you share some details on how to trigger this on arm64?
>>
>> The primary scenario this proposal is targeted towards is when boot
>> memory is set aside from the host, hot-plugged back into the kernel
>> and repurposed (via hotplug-hotremove path) for guest kernel usage.
>> This new warning would reassert that "mem=" cmdline option is debug
>> only on arm64 platform, and should not be used for production.
> Let me get this straight:
> 
> 1. Restrict physical memory to use via "mem="
> 
> -> Some boot memory is !present and, therefore !early
> 
> 2. Hotplug that memory to the kernel
> 
> -> How?
> 
> a) dax/kmem? Does not apply I think.
> b) DIMM? Does not apply I think.
> c) CONFIG_ARCH_MEMORY_PROBE ?
> 
> 3. Trigger physical hotunplug and actually remove the memory
> 
> -> How?
> 
> 4. kexec; will try using hotunplugged memory
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ