[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z0SOZhtJohCNxX6_@wunner.de>
Date: Mon, 25 Nov 2024 15:49:10 +0100
From: Lukas Wunner <lukas@...ner.de>
To: Mark Rutland <mark.rutland@....com>
Cc: Ard Biesheuvel <ardb@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
Herbert Xu <herbert@...dor.apana.org.au>,
Zorro Lang <zlang@...hat.com>,
Vegard Nossum <vegard.nossum@...cle.com>,
Joey Gouly <joey.gouly@....com>,
linux-arm-kernel@...ts.infradead.org, linux-crypto@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH for-next/fixes] arm64/mm: Fix false-positive
!virt_addr_valid() for kernel image
On Mon, Nov 25, 2024 at 10:50:48AM +0000, Mark Rutland wrote:
> On Mon, Nov 25, 2024 at 10:54:49AM +0100, Lukas Wunner wrote:
> > Other arches do not seem to be concerned about this and
> > let virt_addr_valid() return true for the kernel image.
> > It's not clear why arm64 is special and needs to return false.
> >
> > However, I agree there's hardly ever a reason to DMA from/to the
> > .text section. From a security perspective, constraining this to
> > .rodata seems reasonable to me and I'll be happy to amend the patch
> > to that effect if that's the consensus.
>
> Instead, can we update the test to use lm_alias() on the symbols in
> question? That'll convert a kernel image address to its linear map
> alias, and then that'll work with virt_addr_valid(), virt_to_phys(),
> etc.
Do you mean that sg_set_buf() should pass the address to lm_alias()
if it points into the kernel image?
That would require a helper to determine whether it's a kernel image
address or not. It seems we do not have such a cross-architecture
helper (but maybe I'm missing something). (I am adding an arm64-specific
one in the proposed patch.)
So this doesn't look like a viable approach.
Also, I'd expect pushback against an sg_set_buf() change which is
only necessary to accommodate arm64. I'd expect the obvious question
to be asked, which is why arm64's virt_addr_valid() can't behave like
any other architecture's. And honestly I wouldn't know what to answer.
Thanks,
Lukas
Powered by blists - more mailing lists