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
| ||
|
Date: Tue, 18 Aug 2020 10:34:28 +0200 From: Marco Elver <elver@...gle.com> To: Marco Elver <elver@...gle.com>, "Paul E. McKenney" <paulmck@...nel.org> Cc: Will Deacon <will@...nel.org>, Arnd Bergmann <arnd@...db.de>, Mark Rutland <mark.rutland@....com>, linux-arch <linux-arch@...r.kernel.org>, Dmitry Vyukov <dvyukov@...gle.com>, kasan-dev <kasan-dev@...glegroups.com>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCH] bitops, kcsan: Partially revert instrumentation for non-atomic bitops On Thu, 13 Aug 2020 at 18:39, Marco Elver <elver@...gle.com> wrote: > Previous to the change to distinguish read-write accesses, when > CONFIG_KCSAN_ASSUME_PLAIN_WRITES_ATOMIC=y is set, KCSAN would consider > the non-atomic bitops as atomic. We want to partially revert to this > behaviour, but with one important distinction: report racing > modifications, since lost bits due to non-atomicity are certainly > possible. > > Given the operations here only modify a single bit, assuming > non-atomicity of the writer is sufficient may be reasonable for certain > usage (and follows the permissible nature of the "assume plain writes > atomic" rule). In other words: > > 1. We want non-atomic read-modify-write races to be reported; > this is accomplished by kcsan_check_read(), where any > concurrent write (atomic or not) will generate a report. > > 2. We do not want to report races with marked readers, but -do- > want to report races with unmarked readers; this is > accomplished by the instrument_write() ("assume atomic > write" with Kconfig option set). > > With the above rules, when KCSAN_ASSUME_PLAIN_WRITES_ATOMIC is selected, > it is hoped that KCSAN's reporting behaviour is better aligned with > current expected permissible usage for non-atomic bitops. > > Note that, a side-effect of not telling KCSAN that the accesses are > read-writes, is that this information is not displayed in the access > summary in the report. It is, however, visible in inline-expanded stack > traces. For now, it does not make sense to introduce yet another special > case to KCSAN's runtime, only to cater to the case here. > > Signed-off-by: Marco Elver <elver@...gle.com> > Cc: Dmitry Vyukov <dvyukov@...gle.com> > Cc: Paul E. McKenney <paulmck@...nel.org> > Cc: Will Deacon <will@...nel.org> > --- > As discussed, partially reverting behaviour for non-atomic bitops when > KCSAN_ASSUME_PLAIN_WRITES_ATOMIC is selected. > > I'd like to avoid more special cases in KCSAN's runtime to cater to > cases like this, not only because it adds more complexity, but it > invites more special cases to be added. If there are other such > primitives, we likely have to do it on a case-by-case basis as well, and > justify carefully for each such case. But currently, as far as I can > tell, the bitops are truly special, simply because we do know each op > just touches a single bit. > --- > .../bitops/instrumented-non-atomic.h | 30 +++++++++++++++++-- > 1 file changed, 27 insertions(+), 3 deletions(-) Paul, if it looks good to you, feel free to pick it up. Thanks, -- Marco
Powered by blists - more mailing lists