linux-kernel - Re: [tip:locking/urgent] compiler, atomics: Provide READ_ONCE

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: <CACT4Y+YKnBQQ434c9wn5C9_aUhLA9shR1iNE34CX7XHcduK2Bg@mail.gmail.com>
Date:	Wed, 14 Oct 2015 18:08:16 +0200
From:	Dmitry Vyukov <dvyukov@...gle.com>
To:	Paul McKenney <paulmck@...ux.vnet.ibm.com>
Cc:	tip-bot for Andrey Ryabinin <tipbot@...or.com>,
	linux-tip-commits@...r.kernel.org,
	kasan-dev <kasan-dev@...glegroups.com>,
	Ingo Molnar <mingo@...nel.org>,
	Kostya Serebryany <kcc@...gle.com>,
	Borislav Petkov <bp@...en8.de>,
	Andrey Ryabinin <aryabinin@...tuozzo.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Andy Lutomirski <luto@...capital.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Sasha Levin <sasha.levin@...cle.com>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Wolfram Gloger <wmglo@...t.med.uni-muenchen.de>,
	Andrey Konovalov <andreyknvl@...gle.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Alexander Potapenko <glider@...gle.com>
Subject: Re: [tip:locking/urgent] compiler, atomics: Provide READ_ONCE_NOCHECK ()

On Wed, Oct 14, 2015 at 6:01 PM, Paul E. McKenney
<paulmck@...ux.vnet.ibm.com> wrote:
> On Wed, Oct 14, 2015 at 05:50:34PM +0200, Dmitry Vyukov wrote:
>> On Wed, Oct 14, 2015 at 5:45 PM, Paul E. McKenney
>> <paulmck@...ux.vnet.ibm.com> wrote:
>> > On Wed, Oct 14, 2015 at 08:28:43AM -0700, tip-bot for Andrey Ryabinin wrote:
>> >> Commit-ID:  4115ffdf4d6f8986a7abe1dd522c163f599bc0e6
>> >> Gitweb:     http://git.kernel.org/tip/4115ffdf4d6f8986a7abe1dd522c163f599bc0e6
>> >> Author:     Andrey Ryabinin <aryabinin@...tuozzo.com>
>> >> AuthorDate: Tue, 13 Oct 2015 18:28:07 +0300
>> >> Committer:  Ingo Molnar <mingo@...nel.org>
>> >> CommitDate: Wed, 14 Oct 2015 16:44:06 +0200
>> >>
>> >> compiler, atomics: Provide READ_ONCE_NOCHECK()
>> >>
>> >> Some code may perform racy by design memory reads. This could be
>> >> harmless, yet such code may produce KASAN warnings.
>> >>
>> >> To hide such accesses from KASAN this patch introduces
>> >> READ_ONCE_NOCHECK() macro. KASAN will not check the memory
>> >> accessed by READ_ONCE_NOCHECK().
>> >>
>> >> This patch creates __read_once_size_nocheck() a clone of
>> >> __read_once_size_check() (renamed __read_once_size()).
>> >> The only difference between them is 'no_sanitized_address'
>> >> attribute appended to '*_nocheck' function. This attribute tells
>> >> the compiler that instrumentation of memory accesses should not
>> >> be applied to that function. We declare it as static
>> >> '__maybe_unsed' because GCC is not capable to inline such
>> >> function: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
>> >>
>> >> With KASAN=n READ_ONCE_NOCHECK() is just a clone of READ_ONCE().
>> >
>> > So I add READ_ONCE_NOCHECK() for accesses for which the compiler cannot
>> > prove safe address for KASAN's benefit, but READ_ONCE() suffices for
>> > the data-race-detection logic in KTSAN, correct?
>>
>> KTSAN also needs READ_ONCE_NOCHECK() here. KTSAN will flag races
>> between get_wchan() and the thread accesses to own stack even more
>> aggressively than KASAN, because KTSAN won't like get_wchan() accesses
>> even to non-poisoned areas of other thread stack.
>
> So to keep KTSAN happy, any read from some other thread's stack requires
> READ_ONCE_NOCHECK()?  What if the access is via a locking primitive or
> read-modify-write atomic operation?
>
> This is of some interest in RCU, which implements synchronous grace
> periods using completions that are allocated on the calling task's stack
> and manipulated by RCU callbacks that are likely executing elsewhere.


KTSAN does not have any special logic for stacks. It just generally
flags pairs of accesses when (1) at least one access is not atomic,
(2) at least one access is a write and (3) these accesses are not
synchronized by means of other synchronization.
There is a bunch of cases when kernel code allocates objects on stack
and then passes them to other threads, but as far as there is proper
synchronization it is OK.

For the record, KTSAN is this:
https://github.com/google/ktsan
https://github.com/google/ktsan/wiki/Found-Bugs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/