linux-arm-kernel.lists.infradead.org archive mirror
 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

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

Thread overview: 3+ 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-29 13:38 ` Ard Biesheuvel
2022-04-29 18:23   ` Catalin Marinas [this message]

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).