linux-kernel - Re: does software KASAN not instrument READ

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: <CAG48ez1w3YO=dwuGqVF3PdHec6=vbYr3GmabY-qQHbZ0fko2JA@mail.gmail.com>
Date: Thu, 27 Mar 2025 20:09:23 +0100
From: Jann Horn <jannh@...gle.com>
To: Alexander Potapenko <glider@...gle.com>
Cc: Will Deacon <will@...nel.org>, kasan-dev <kasan-dev@...glegroups.com>, 
	Andrey Ryabinin <ryabinin.a.a@...il.com>, kernel list <linux-kernel@...r.kernel.org>, 
	Linux ARM <linux-arm-kernel@...ts.infradead.org>, 
	Catalin Marinas <catalin.marinas@....com>, Andrey Konovalov <andreyknvl@...il.com>, 
	Dmitry Vyukov <dvyukov@...gle.com>, Vincenzo Frascino <vincenzo.frascino@....com>
Subject: Re: does software KASAN not instrument READ_ONCE() on arm64 with LTO?

On Thu, Mar 27, 2025 at 8:29 AM Alexander Potapenko <glider@...gle.com> wrote:
> On Thu, Mar 27, 2025 at 12:10 AM Jann Horn <jannh@...gle.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()?