linux-kernel - Re: [PATCH] arm64/mm: Validate hotplug range before creating linear mapping

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]

Message-ID: <20200929152221.GA13995@willie-the-truck>
Date:   Tue, 29 Sep 2020 16:22:22 +0100
From:   Will Deacon <will@...nel.org>
To:     Anshuman Khandual <anshuman.khandual@....com>
Cc:     linux-arm-kernel@...ts.infradead.org, catalin.marinas@....com,
        Mark Rutland <mark.rutland@....com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Steven Price <steven.price@....com>,
        Robin Murphy <robin.murphy@....com>,
        David Hildenbrand <david@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64/mm: Validate hotplug range before creating linear
 mapping

On Tue, Sep 29, 2020 at 01:34:24PM +0530, Anshuman Khandual wrote:
> 
> 
> On 09/29/2020 02:05 AM, Will Deacon wrote:
> > On Thu, Sep 17, 2020 at 02:16:42PM +0530, Anshuman Khandual wrote:
> >> During memory hotplug process, the linear mapping should not be created for
> >> a given memory range if that would fall outside the maximum allowed linear
> >> range. Else it might cause memory corruption in the kernel virtual space.
> >>
> >> Maximum linear mapping region is [PAGE_OFFSET..(PAGE_END -1)] accommodating
> >> both its ends but excluding PAGE_END. Max physical range that can be mapped
> >> inside this linear mapping range, must also be derived from its end points.
> >>
> >> When CONFIG_ARM64_VA_BITS_52 is enabled, PAGE_OFFSET is computed with the
> >> assumption of 52 bits virtual address space. However, if the CPU does not
> >> support 52 bits, then it falls back using 48 bits instead and the PAGE_END
> >> is updated to reflect this using the vabits_actual. As for PAGE_OFFSET,
> >> bits [51..48] are ignored by the MMU and remain unchanged, even though the
> >> effective start address of linear map is now slightly different. Hence, to
> >> reliably check the physical address range mapped by the linear map, the
> >> start address should be calculated using vabits_actual. This ensures that
> >> arch_add_memory() validates memory hot add range for its potential linear
> >> mapping requirement, before creating it with __create_pgd_mapping().
> >>
> >> 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
> >> Fixes: 4ab215061554 ("arm64: Add memory hotplug support")
> >> Signed-off-by: Anshuman Khandual <anshuman.khandual@....com>
> >> ---
> >>  arch/arm64/mm/mmu.c | 27 +++++++++++++++++++++++++++
> >>  1 file changed, 27 insertions(+)
> >>
> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> >> index 75df62fea1b6..d59ffabb9c84 100644
> >> --- a/arch/arm64/mm/mmu.c
> >> +++ b/arch/arm64/mm/mmu.c
> >> @@ -1433,11 +1433,38 @@ static void __remove_pgd_mapping(pgd_t *pgdir, unsigned long start, u64 size)
> >>  	free_empty_tables(start, end, PAGE_OFFSET, PAGE_END);
> >>  }
> >>  
> >> +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.
> >> +	 *
> >> +	 * With CONFIG_ARM64_VA_BITS_52 enabled, PAGE_OFFSET is defined with
> >> +	 * the assumption of 52 bits virtual address space. However, if the
> >> +	 * CPU does not support 52 bits, it falls back using 48 bits and the
> >> +	 * PAGE_END is updated to reflect this using the vabits_actual. As
> >> +	 * for PAGE_OFFSET, bits [51..48] are ignored by the MMU and remain
> >> +	 * unchanged, even though the effective start address of linear map
> >> +	 * is now slightly different. Hence, to reliably check the physical
> >> +	 * address range mapped by the linear map, the start address should
> >> +	 * be calculated using vabits_actual.
> >> +	 */
> >> +	return ((start >= __pa(_PAGE_OFFSET(vabits_actual)))
> >> +			&& ((start + size) <= __pa(PAGE_END - 1)));
> >> +}
> > 
> > Why isn't this implemented using the existing __is_lm_address()?
> 
> Not sure, if I understood your suggestion here. The physical address range
> [start..start + size] needs to be checked against maximum physical range
> that can be represented inside effective boundaries for the linear mapping
> i.e [__pa(_PAGE_OFFSET(vabits_actual)..__pa(PAGE_END - 1)].
> 
> Are you suggesting [start..start + size] should be first be converted into
> a virtual address range and then checked against __is_lm_addresses() ? But
> is not deriving the physical range from from know limits of linear mapping
> much cleaner ?

I just think having a function called "inside_linear_region()" as well as a
macro called "__is_lm_address()" is weird when they have completely separate
implementations. They're obviously trying to do the same thing, just the
first one gets given physical address as parameters.

Implementing one in terms of the other is much better for maintenance.

Will