Re: [PATCH] arm64: mm: account for hotplug memory when randomizing the linear region
From: Anshuman Khandual
Date: Fri Nov 13 2020 - 02:40:12 EST
On 11/13/20 12:36 PM, Ard Biesheuvel wrote:
> On Fri, 13 Nov 2020 at 08:03, Anshuman Khandual
> <anshuman.khandual@xxxxxxx> wrote:
>>
>>
>>
>> On 11/13/20 11:44 AM, Ard Biesheuvel wrote:
>>> On Fri, 13 Nov 2020 at 04:16, Anshuman Khandual
>>> <anshuman.khandual@xxxxxxx> wrote:
>>>>
>>>>
>>>>
>>>> On 11/12/20 2:55 PM, Catalin Marinas wrote:
>>>>> Hi Anshuman,
>>>>>
>>>>> On Wed, Nov 11, 2020 at 09:18:56AM +0530, Anshuman Khandual wrote:
>>>>>> On 11/11/20 12:44 AM, Catalin Marinas wrote:
>>>>>>> On Wed, 14 Oct 2020 10:18:57 +0200, Ard Biesheuvel wrote:
>>>>>>>> As a hardening measure, we currently randomize the placement of
>>>>>>>> physical memory inside the linear region when KASLR is in effect.
>>>>>>>> Since the random offset at which to place the available physical
>>>>>>>> memory inside the linear region is chosen early at boot, it is
>>>>>>>> based on the memblock description of memory, which does not cover
>>>>>>>> hotplug memory. The consequence of this is that the randomization
>>>>>>>> offset may be chosen such that any hotplugged memory located above
>>>>>>>> memblock_end_of_DRAM() that appears later is pushed off the end of
>>>>>>>> the linear region, where it cannot be accessed.
>>>>>>>>
>>>>>>>> [...]
>>>>>>>
>>>>>>> Applied to arm64 (for-next/mem-hotplug), thanks!
>>>>>>>
>>>>>>> [1/1] arm64: mm: account for hotplug memory when randomizing the linear region
>>>>>>> https://git.kernel.org/arm64/c/97d6786e0669
>>>>>>
>>>>>> Got delayed and never made here in time, sorry about that. Nonetheless,
>>>>>> I have got something working with respect to the generic mechanism that
>>>>>> David Hildenbrand had asked for earlier.
>>>>>>
>>>>>> https://patchwork.kernel.org/project/linux-arm-kernel/patch/1600332402-30123-1-git-send-email-anshuman.khandual@xxxxxxx/
>>>>>
>>>>> There was a lot of discussion around this patch but I haven't seen any
>>>>> new version posted.
>>>>
>>>> Just posted before some time.
>>>>
>>>> https://lore.kernel.org/linux-arm-kernel/1605236574-14636-1-git-send-email-anshuman.khandual@xxxxxxx/
>>>>
>>>
>>> You failed to cc me on that patch.
>>
>> I could see 'ardb@xxxxxxxxxx' marked as a copy on the patch. You
>> did not receive the email ? The CC list is in the commit message
>> itself. Even the lore.kernel.org based URL does list you email
>> as well. Not sure what might have happened.
>>
>> Cc: Catalin Marinas <catalin.marinas@xxxxxxx>
>> Cc: Will Deacon <will@xxxxxxxxxx>
>> Cc: Mark Rutland <mark.rutland@xxxxxxx>
>> Cc: Ard Biesheuvel <ardb@xxxxxxxxxx>
>> Cc: Steven Price <steven.price@xxxxxxx>
>> Cc: Robin Murphy <robin.murphy@xxxxxxx>
>> Cc: David Hildenbrand <david@xxxxxxxxxx>
>> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
>> Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
>> Cc: linux-kernel@xxxxxxxxxxxxxxx
>>
>
> Right. Not sure what happened there, I may have deleted it by
> accident. Apologies.
>
>>>
>>> The logic looks correct but please fix up the comment block:
>>> - PAGE_END is no longer defined in terms of vabits_actual
>>> - bits [51..48] are not ignored by the MMU
>>>
>>> Actually, I think the entire second paragraph of that comment block
>>> can be dropped.
>>
>> And from the commit message as well, had reused it in both places.
>>
>>>
>>> Please also fix up the coding style:
>>> - put && at the end of the first line
>>> - drop the redundant parens
>>> - fix the indentation
>>
>> Does this look okay ?
>>
>> static bool inside_linear_region(u64 start, u64 size)
>> {
>> /*
>> * Linear mapping region is the range [PAGE_OFFSET..(PAGE_END - 1)]
>> * accommodating both its ends but excluding PAGE_END. Max physical
>> * range which can be mapped inside this linear mapping range, must
>> * also be derived from its end points.
>> */
>> return start >= __pa(_PAGE_OFFSET(vabits_actual)) &&
>> (start + size - 1) <= __pa(PAGE_END - 1);
>> }
>
> Not sure whether the whitespace has been mangled by the email client,
> but the first ( on the second line should align vertically with the
> 's' of 'start' on the first line
It was not aligned vertically here but fixed it. I hope you have received
the latest version this time.
https://lore.kernel.org/linux-arm-kernel/1605252614-761-1-git-send-email-anshuman.khandual@xxxxxxx/