All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Guillaume Tucker <gtucker@collabora.com>,
	Mark Brown <broonie@kernel.org>,
	Mark-PK Tsai <mark-pk.tsai@mediatek.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Russell King <linux@armlinux.org.uk>,
	Tony Lindgren <tony@atomide.com>, Will Deacon <will@kernel.org>,
	"kernelci . org bot" <bot@kernelci.org>,
	kernelci-results@groups.io,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	"# 3.4.x" <stable@vger.kernel.org>
Subject: Re: [PATCH v2] arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map
Date: Fri, 29 Apr 2022 19:23:24 +0100	[thread overview]
Message-ID: <YmwtHOSy2vf3vw0Y@arm.com> (raw)
In-Reply-To: <CAMj1kXG=-YFKLkv3EkMeuhS7fiuTsEctehxRCueyTuYBxY1kUQ@mail.gmail.com>

On Fri, Apr 29, 2022 at 03:38:59PM +0200, Ard Biesheuvel wrote:
> On Tue, 26 Apr 2022 at 08:01, Mike Rapoport <rppt@kernel.org> wrote:
> > From: Mike Rapoport <rppt@linux.ibm.com>
> >
> > 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/Yl65zxGgFzF1Okac@sirena.org.uk
> > Reported-by: "kernelci.org bot" <bot@kernelci.org>
> > Tested-by: Mark Brown <broonie@kernel.org>
> > Cc: stable@vger.kernel.org      # 5.4+
> > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> > ---
> > v2: don't remove pfn_valid() from try_ram_remap(), per Ard
> >
> >  arch/arm/include/asm/io.h   | 3 +++
> >  arch/arm/mm/ioremap.c       | 8 ++++++++
> >  arch/arm64/include/asm/io.h | 4 ++++
> >  arch/arm64/mm/ioremap.c     | 8 ++++++++
> >  4 files changed, 23 insertions(+)
> >
> 
> I think this looks reasonable, but you'll need to split it in two if
> it is going through the respective arch trees.

I guess that would be best. Otherwise, if Andrew picks it up:

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Guillaume Tucker <gtucker@collabora.com>,
	Mark Brown <broonie@kernel.org>,
	Mark-PK Tsai <mark-pk.tsai@mediatek.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Russell King <linux@armlinux.org.uk>,
	Tony Lindgren <tony@atomide.com>, Will Deacon <will@kernel.org>,
	"kernelci . org bot" <bot@kernelci.org>,
	kernelci-results@groups.io,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	"# 3.4.x" <stable@vger.kernel.org>
Subject: Re: [PATCH v2] arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map
Date: Fri, 29 Apr 2022 19:23:24 +0100	[thread overview]
Message-ID: <YmwtHOSy2vf3vw0Y@arm.com> (raw)
In-Reply-To: <CAMj1kXG=-YFKLkv3EkMeuhS7fiuTsEctehxRCueyTuYBxY1kUQ@mail.gmail.com>

On Fri, Apr 29, 2022 at 03:38:59PM +0200, Ard Biesheuvel wrote:
> On Tue, 26 Apr 2022 at 08:01, Mike Rapoport <rppt@kernel.org> wrote:
> > From: Mike Rapoport <rppt@linux.ibm.com>
> >
> > 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/Yl65zxGgFzF1Okac@sirena.org.uk
> > Reported-by: "kernelci.org bot" <bot@kernelci.org>
> > Tested-by: Mark Brown <broonie@kernel.org>
> > Cc: stable@vger.kernel.org      # 5.4+
> > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> > ---
> > v2: don't remove pfn_valid() from try_ram_remap(), per Ard
> >
> >  arch/arm/include/asm/io.h   | 3 +++
> >  arch/arm/mm/ioremap.c       | 8 ++++++++
> >  arch/arm64/include/asm/io.h | 4 ++++
> >  arch/arm64/mm/ioremap.c     | 8 ++++++++
> >  4 files changed, 23 insertions(+)
> >
> 
> I think this looks reasonable, but you'll need to split it in two if
> it is going through the respective arch trees.

I guess that would be best. Otherwise, if Andrew picks it up:

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

  reply	other threads:[~2022-04-29 18:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-26  6:01 [PATCH v2] arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map Mike Rapoport
2022-04-26  6:01 ` Mike Rapoport
2022-04-29 13:38 ` Ard Biesheuvel
2022-04-29 13:38   ` Ard Biesheuvel
2022-04-29 18:23   ` Catalin Marinas [this message]
2022-04-29 18:23     ` Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YmwtHOSy2vf3vw0Y@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=ardb@kernel.org \
    --cc=bot@kernelci.org \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=gtucker@collabora.com \
    --cc=kernelci-results@groups.io \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark-pk.tsai@mediatek.com \
    --cc=rppt@kernel.org \
    --cc=rppt@linux.ibm.com \
    --cc=stable@vger.kernel.org \
    --cc=tony@atomide.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.