On Sun, Nov 24, 2024 at 06:13:26PM +0100, Ard Biesheuvel wrote:
> > On Sun, 24 Nov 2024 at 17:16, Lukas Wunner <lukas@xxxxxxxxx> wrote:
> > > Zorro reports a false-positive BUG_ON() when running crypto selftests on
> > > boot: Since commit 1e562deacecc ("crypto: rsassa-pkcs1 - Migrate to
> > > sig_alg backend"), test_sig_one() invokes an RSA verify operation with a
> > > test vector in the kernel's .rodata section. The test vector is passed
> > > to sg_set_buf(), which performs a virt_addr_valid() check.
> > >
> > > On arm64, virt_addr_valid() returns false for kernel image addresses
> > > such as this one, even though they're valid virtual addresses.
> > > x86 returns true for kernel image addresses, so the BUG_ON() does not
> > > occur there. In fact, x86 has been doing so for 16 years, i.e. since
> > > commit af5c2bd16ac2 ("x86: fix virt_addr_valid() with
> > > CONFIG_DEBUG_VIRTUAL=y, v2").
> > >
> > > Do the same on arm64 to avoid the false-positive BUG_ON() and to achieve
> > > consistent virt_addr_valid() behavior across arches.
[...]
> that doesn't mean doing DMA from the kernel image is a great
> idea. Allocations in the linear map are rounded up to cacheline size
> to ensure that they are safe for non-coherent DMA, but this does not
> apply to the kernel image. .rodata should still be safe in this
> regard, but the general idea of allowing kernel image addresses in
> places where DMA'able virtual addresses are expected is something we
> should consider with care.
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.
I'll wait for guidance from arm64 maintainers what the preferred
approach is.
Thanks,
Lukas
