2022-04-25 07:39:07

by Ard Biesheuvel

[permalink] [raw]
Subject: Re: [PATCH] arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map

On Sun, 24 Apr 2022 at 19:22, Mike Rapoport <[email protected]> wrote:
>
> From: Mike Rapoport <[email protected]>
>
> The semantics of pfn_valid() is to check presence of the memory map for a
> PFN and not whether a PFN is covered by the linear map. The memory map may
> be present for NOMAP memory regions, but they won't be mapped in the linear
> mapping. Accessing such regions via __va() when they are memremap()'ed
> will cause a crash.
>
> On v5.4.y the crash happens on qemu-arm with UEFI [1]:
>
> <1>[ 0.084476] 8<--- cut here ---
> <1>[ 0.084595] Unable to handle kernel paging request at virtual address dfb76000
> <1>[ 0.084938] pgd = (ptrval)
> <1>[ 0.085038] [dfb76000] *pgd=5f7fe801, *pte=00000000, *ppte=00000000
>
> ...
>
> <4>[ 0.093923] [<c0ed6ce8>] (memcpy) from [<c16a06f8>] (dmi_setup+0x60/0x418)
> <4>[ 0.094204] [<c16a06f8>] (dmi_setup) from [<c16a38d4>] (arm_dmi_init+0x8/0x10)
> <4>[ 0.094408] [<c16a38d4>] (arm_dmi_init) from [<c0302e9c>] (do_one_initcall+0x50/0x228)
> <4>[ 0.094619] [<c0302e9c>] (do_one_initcall) from [<c16011e4>] (kernel_init_freeable+0x15c/0x1f8)
> <4>[ 0.094841] [<c16011e4>] (kernel_init_freeable) from [<c0f028cc>] (kernel_init+0x8/0x10c)
> <4>[ 0.095057] [<c0f028cc>] (kernel_init) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
>
> On kernels v5.10.y and newer the same crash won't reproduce on ARM because
> commit b10d6bca8720 ("arch, drivers: replace for_each_membock() with
> for_each_mem_range()") changed the way memory regions are registered in the
> resource tree, but that merely covers up the problem.
>
> On ARM64 memory resources registered in yet another way and there the
> issue of wrong usage of pfn_valid() to ensure availability of the linear
> map is also covered.
>
> Implement arch_memremap_can_ram_remap() on ARM and ARM64 to prevent access
> to NOMAP regions via the linear mapping in memremap().
>
> Link: https://lore.kernel.org/all/[email protected]
> Reported-by: "kernelci.org bot" <[email protected]>
> Tested-by: Mark Brown <[email protected]>
> Cc: [email protected] # 5.4+
> Signed-off-by: Mike Rapoport <[email protected]>
> ---
> arch/arm/include/asm/io.h | 4 ++++
> arch/arm/mm/ioremap.c | 9 ++++++++-
> arch/arm64/include/asm/io.h | 4 ++++
> arch/arm64/mm/ioremap.c | 8 ++++++++
> kernel/iomem.c | 2 +-
> 5 files changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
> index 0c70eb688a00..fbb2eeea7285 100644
> --- a/arch/arm/include/asm/io.h
> +++ b/arch/arm/include/asm/io.h
> @@ -145,6 +145,10 @@ extern void __iomem * (*arch_ioremap_caller)(phys_addr_t, size_t,
> unsigned int, void *);
> extern void (*arch_iounmap)(volatile void __iomem *);
>
> +extern bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
> + unsigned long flags);
> +#define arch_memremap_can_ram_remap arch_memremap_can_ram_remap
> +
> /*
> * Bad read/write accesses...
> */
> diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
> index aa08bcb72db9..6eb1ad24544d 100644
> --- a/arch/arm/mm/ioremap.c
> +++ b/arch/arm/mm/ioremap.c
> @@ -43,7 +43,6 @@
> #include <asm/mach/pci.h>
> #include "mm.h"
>
> -
> LIST_HEAD(static_vmlist);
>
> static struct static_vm *find_static_vm_paddr(phys_addr_t paddr,
> @@ -493,3 +492,11 @@ void __init early_ioremap_init(void)
> {
> early_ioremap_setup();
> }
> +
> +bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
> + unsigned long flags)
> +{
> + unsigned long pfn = PHYS_PFN(offset);
> +
> + return memblock_is_map_memory(pfn);
> +}
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 7fd836bea7eb..3995652daf81 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -192,4 +192,8 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
> extern int valid_phys_addr_range(phys_addr_t addr, size_t size);
> extern int valid_mmap_phys_addr_range(unsigned long pfn, size_t size);
>
> +extern bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
> + unsigned long flags);
> +#define arch_memremap_can_ram_remap arch_memremap_can_ram_remap
> +
> #endif /* __ASM_IO_H */
> diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
> index b7c81dacabf0..b21f91cd830d 100644
> --- a/arch/arm64/mm/ioremap.c
> +++ b/arch/arm64/mm/ioremap.c
> @@ -99,3 +99,11 @@ void __init early_ioremap_init(void)
> {
> early_ioremap_setup();
> }
> +
> +bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
> + unsigned long flags)
> +{
> + unsigned long pfn = PHYS_PFN(offset);
> +
> + return pfn_is_map_memory(pfn);
> +}
> diff --git a/kernel/iomem.c b/kernel/iomem.c
> index 62c92e43aa0d..e85bed24c0a9 100644
> --- a/kernel/iomem.c
> +++ b/kernel/iomem.c
> @@ -33,7 +33,7 @@ static void *try_ram_remap(resource_size_t offset, size_t size,
> unsigned long pfn = PHYS_PFN(offset);
>
> /* In the simple case just return the existing linear address */
> - if (pfn_valid(pfn) && !PageHighMem(pfn_to_page(pfn)) &&
> + if (!PageHighMem(pfn_to_page(pfn)) &&

This looks wrong to me. Calling any of the PageXxx() accessors is only
safe if the PFN is valid, since otherwise, we don't know if the
associated struct page exists.

> arch_memremap_can_ram_remap(offset, size, flags))
> return __va(offset);
>
>
> base-commit: b2d229d4ddb17db541098b83524d901257e93845
> --
> 2.28.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


2022-04-25 07:52:49

by Mike Rapoport

[permalink] [raw]
Subject: Re: [PATCH] arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map

On Sun, Apr 24, 2022 at 11:19:05PM +0200, Ard Biesheuvel wrote:
> On Sun, 24 Apr 2022 at 19:22, Mike Rapoport <[email protected]> wrote:
> >
> > From: Mike Rapoport <[email protected]>
> >
> > The semantics of pfn_valid() is to check presence of the memory map for a
> > PFN and not whether a PFN is covered by the linear map. The memory map may
> > be present for NOMAP memory regions, but they won't be mapped in the linear
> > mapping. Accessing such regions via __va() when they are memremap()'ed
> > will cause a crash.

...

> > diff --git a/kernel/iomem.c b/kernel/iomem.c
> > index 62c92e43aa0d..e85bed24c0a9 100644
> > --- a/kernel/iomem.c
> > +++ b/kernel/iomem.c
> > @@ -33,7 +33,7 @@ static void *try_ram_remap(resource_size_t offset, size_t size,
> > unsigned long pfn = PHYS_PFN(offset);
> >
> > /* In the simple case just return the existing linear address */
> > - if (pfn_valid(pfn) && !PageHighMem(pfn_to_page(pfn)) &&
> > + if (!PageHighMem(pfn_to_page(pfn)) &&
>
> This looks wrong to me. Calling any of the PageXxx() accessors is only
> safe if the PFN is valid, since otherwise, we don't know if the
> associated struct page exists.

Yeah, you are right, was over-enthusiastic here...

> > arch_memremap_can_ram_remap(offset, size, flags))
> > return __va(offset);
> >
> >
> > base-commit: b2d229d4ddb17db541098b83524d901257e93845
> > --
> > 2.28.0
> >

--
Sincerely yours,
Mike.