[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ae1bdb23-4e44-bc6f-bdf0-a4efbcb5a3cb@arm.com>
Date: Fri, 13 Nov 2020 12:32:47 +0530
From: Anshuman Khandual <anshuman.khandual@....com>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Will Deacon <will@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Mark Rutland <mark.rutland@....com>,
Steve Capper <steve.capper@....com>,
Mark Brown <broonie@...nel.org>, Marc Zyngier <maz@...nel.org>,
gshan@...hat.com, Robin Murphy <robin.murphy@....com>,
Steven Price <steven.price@....com>,
David Hildenbrand <david@...hat.com>
Subject: Re: [PATCH] arm64: mm: account for hotplug memory when randomizing
the linear region
On 11/13/20 11:44 AM, Ard Biesheuvel wrote:
> On Fri, 13 Nov 2020 at 04:16, Anshuman Khandual
> <anshuman.khandual@....com> 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@arm.com/
>>>
>>> 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@arm.com/
>>
>
> You failed to cc me on that patch.
I could see 'ardb@...nel.org' 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@....com>
Cc: Will Deacon <will@...nel.org>
Cc: Mark Rutland <mark.rutland@....com>
Cc: Ard Biesheuvel <ardb@...nel.org>
Cc: Steven Price <steven.price@....com>
Cc: Robin Murphy <robin.murphy@....com>
Cc: David Hildenbrand <david@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-arm-kernel@...ts.infradead.org
Cc: linux-kernel@...r.kernel.org
>
> 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);
}
Powered by blists - more mailing lists