On Fri, 13 Nov 2020 at 08:03, Anshuman Khandual
<[email protected]> wrote:
>
>
>
> On 11/13/20 11:44 AM, Ard Biesheuvel wrote:
> > On Fri, 13 Nov 2020 at 04:16, Anshuman Khandual
> > <[email protected]> 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/[email protected]/
> >>>
> >>> 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/[email protected]/
> >>
> >
> > You failed to cc me on that patch.
>
> I could see '[email protected]' 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 <[email protected]>
> Cc: Will Deacon <[email protected]>
> Cc: Mark Rutland <[email protected]>
> Cc: Ard Biesheuvel <[email protected]>
> Cc: Steven Price <[email protected]>
> Cc: Robin Murphy <[email protected]>
> Cc: David Hildenbrand <[email protected]>
> Cc: Andrew Morton <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
>
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
