linux-kernel - instrument_atomic_read()/_write() in noinstr functions?

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-next>] [day] [month] [year] [list]

Message-ID: <871r4z55fn.fsf@dja-thinkpad.axtens.net>
Date:   Wed, 06 Oct 2021 12:05:00 +1100
From:   Daniel Axtens <dja@...ens.net>
To:     kasan-dev@...glegroups.com, linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>, paulmck@...nel.org,
        rcu@...r.kernel.org
Subject: instrument_atomic_read()/_write() in noinstr functions?

Hi,

commit b58e733fd774 ("rcu: Fixup noinstr warnings") adds some
instrument_atomic_read calls to rcu_nmi_enter - a function marked
noinstr. Similar calls are added to some other functions as well.

This is causing me some grief on powerpc64 while trying to enable
KASAN. powerpc64 book3s takes some NMIs in real mode, and in real mode
we can't access where I'm proposing to put the KASAN shadow - we can
only access it with translations on. So I end up taking a fault in the
kasan_check_read path via rcu_nmi_enter.

As far as I can tell `instrumentation_begin()` and
`instrumentation_end()` don't make it safe to call instrumentation, they
just tell the developer that instrumentation is safe. (And they are used
to check the balance of _begin()/_end() blocks.)

Is the underlying assumption that the KASAN shadow will always be safe
to access, even in functions marked noinstr? It seems to undercut what
an architecture can assume about a function marked noinstr...

Kind regards,
Daniel

P.S. On a more generic note instrumentation_begin()/_end() is now
scattered across the kernel and it makes me a bit nervous. It's making a
statement about something that is in part a property of how the arch
implements instrumentation. Are arches expected to implement things in
such a way as to make these blocks accurate? For example in
arch/powerpc/include/asm/interrupt.h::interrupt_nmi_enter_prepare we
currently sometimes call nmi_enter in real mode; should we instead only
call it when we have translations on?