linux-kernel - Re: RCU vs data

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]

Date:   Tue, 6 Jul 2021 10:44:46 +0200
From:   Marco Elver <elver@...gle.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     "Paul E. McKenney" <paulmck@...nel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: RCU vs data_race()

On Tue, 6 Jul 2021 at 10:00, Peter Zijlstra <peterz@...radead.org> wrote:
[...]
> In that case, would not an explicit: data_debug(addr) call (implemented
> by KASAN/KCSAN/whoever), which would report whatever knowledge they have
> about that address, be even more useful?

KCSAN/KASAN report data-races/memory errors as soon as they encounter
them, but before they do, cannot give you any more than that (metadata
if it exists, but not sure it can be interpreted in any useful way
before an error occurs).

But maybe I misunderstood. Is data_debug() meant to not return
anything and instead just be a "fake access"?

For those, we already have various existing primitives:

-- KCSAN: ASSERT_EXCLUSIVE_{ACCESS,WRITER}()
(https://www.kernel.org/doc/html/latest/dev-tools/kcsan.html#race-detection-beyond-data-races)

-- All sanitizers (KASAN & KCSAN right now): <linux/instrumented.h>:
instrument_*() calls, for generic explicit instrumentation.

-- For sanitizer-specific checks, there's everything else in
<linux/{kasan,kcsan}-checks.h>, but instrumented.h should be
preferred.

Thanks,
-- Marco