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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ