does software KASAN not instrument READ_ONCE() on arm64 with LTO?
Jann Horn
jannh at google.com
Thu Mar 27 12:09:23 PDT 2025
On Thu, Mar 27, 2025 at 8:29 AM Alexander Potapenko <glider at google.com> wrote:
> On Thu, Mar 27, 2025 at 12:10 AM Jann Horn <jannh at google.com> wrote:
> > Hi!
> >
> > I just realized - arm64 redefines __READ_ONCE() to use inline assembly
> > instead of a volatile load, and ASAN is designed to not instrument asm
> > statement operands (not even memory operands).
>
> Nice catch!
>
> > (I think I may have a years-old LLVM patch somewhere that changes
> > that, but I vaguely recall being told once that that's an intentional
> > design decision. I might be misremembering that though...)
>
> We have some best-effort asm instrumentation in KMSAN (see
> https://llvm.org/doxygen/MemorySanitizer_8cpp_source.html#l04968) and
> could potentially do something similar for KASAN, but if I remember
> correctly there were some corner cases with unknown argument sizes and
> with percpu instrumentation (at least on x86 percpu accesses receive
> an offset of the variable in .data..percpu, not the actual address).
Ah, I see. Annoying that memory operands are used for that...
> > So because __READ_ONCE() does not call anything like
> > instrument_read(), I think instrumentation-based KASAN in LTO arm64
> > builds probably doesn't cover READ_ONCE() accesses?
> >
> > A quick test seems to confirm this: https://godbolt.org/z/8oYfaExYf
>
> So should it be enough to call instrument_read()?
Sort of, I think; but I'm not sure whether instrument_read() is
available in this header or whether that would create an include
dependency loop because READ_ONCE is so fundamental
(linux/instrumented.h depends on linux/compiler.h, which pulls in
asm/rwonce.h). So instrument_read() might maybe need to be open-coded
if we want to use it here? IDK...
And also I think this would probably cause ASAN false-positives in
__read_once_word_nocheck(), because I think disabling ASAN
instrumentation per-function with __no_sanitize_or_inline probably
does not disable explicit instrumentation through instrument_read()?
More information about the linux-arm-kernel
mailing list