| 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
| ||
|
Message-ID: <CACT4Y+bEYJJR+CRdngiprjQJ6ykDfsYS3jQL4sTPF1=BoQLvdg@mail.gmail.com>
Date: Wed, 14 Oct 2015 17:50:34 +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 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.
> Thanx, Paul
>
>> Signed-off-by: Andrey Ryabinin <aryabinin@...tuozzo.com>
>> Cc: Alexander Potapenko <glider@...gle.com>
>> Cc: Andrew Morton <akpm@...ux-foundation.org>
>> Cc: Andrey Konovalov <andreyknvl@...gle.com>
>> Cc: Andy Lutomirski <luto@...capital.net>
>> Cc: Borislav Petkov <bp@...en8.de>
>> Cc: Denys Vlasenko <dvlasenk@...hat.com>
>> Cc: Dmitry Vyukov <dvyukov@...gle.com>
>> Cc: Kostya Serebryany <kcc@...gle.com>
>> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
>> Cc: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
>> Cc: Peter Zijlstra <peterz@...radead.org>
>> Cc: Sasha Levin <sasha.levin@...cle.com>
>> Cc: Thomas Gleixner <tglx@...utronix.de>
>> Cc: Wolfram Gloger <wmglo@...t.med.uni-muenchen.de>
>> Cc: kasan-dev <kasan-dev@...glegroups.com>
>> Link: http://lkml.kernel.org/r/1444750088-24444-2-git-send-email-aryabinin@virtuozzo.com
>> Signed-off-by: Ingo Molnar <mingo@...nel.org>
>> ---
>> include/linux/compiler-gcc.h | 13 ++++++++++
>> include/linux/compiler.h | 60 ++++++++++++++++++++++++++++++++++----------
>> 2 files changed, 60 insertions(+), 13 deletions(-)
>>
>> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
>> index dfaa7b3..f2a9aec 100644
>> --- a/include/linux/compiler-gcc.h
>> +++ b/include/linux/compiler-gcc.h
>> @@ -237,12 +237,25 @@
>> #define KASAN_ABI_VERSION 3
>> #endif
>>
>> +#if GCC_VERSION >= 40902
>> +/*
>> + * Tell the compiler that address safety instrumentation (KASAN)
>> + * should not be applied to that function.
>> + * Confilcts with inlining: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
>> + */
>> +#define __no_sanitize_address __attribute__((no_sanitize_address))
>> +#endif
>> +
>> #endif /* gcc version >= 40000 specific checks */
>>
>> #if !defined(__noclone)
>> #define __noclone /* not needed */
>> #endif
>>
>> +#if !defined(__no_sanitize_address)
>> +#define __no_sanitize_address
>> +#endif
>> +
>> /*
>> * A trick to suppress uninitialized variable warning without generating any
>> * code
>> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
>> index c836eb2..aa2ae4c 100644
>> --- a/include/linux/compiler.h
>> +++ b/include/linux/compiler.h
>> @@ -198,19 +198,42 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
>>
>> #include <uapi/linux/types.h>
>>
>> -static __always_inline void __read_once_size(const volatile void *p, void *res, int size)
>> +#define __READ_ONCE_SIZE \
>> +({ \
>> + switch (size) { \
>> + case 1: *(__u8 *)res = *(volatile __u8 *)p; break; \
>> + case 2: *(__u16 *)res = *(volatile __u16 *)p; break; \
>> + case 4: *(__u32 *)res = *(volatile __u32 *)p; break; \
>> + case 8: *(__u64 *)res = *(volatile __u64 *)p; break; \
>> + default: \
>> + barrier(); \
>> + __builtin_memcpy((void *)res, (const void *)p, size); \
>> + barrier(); \
>> + } \
>> +})
>> +
>> +static __always_inline
>> +void __read_once_size_check(const volatile void *p, void *res, int size)
>> {
>> - switch (size) {
>> - case 1: *(__u8 *)res = *(volatile __u8 *)p; break;
>> - case 2: *(__u16 *)res = *(volatile __u16 *)p; break;
>> - case 4: *(__u32 *)res = *(volatile __u32 *)p; break;
>> - case 8: *(__u64 *)res = *(volatile __u64 *)p; break;
>> - default:
>> - barrier();
>> - __builtin_memcpy((void *)res, (const void *)p, size);
>> - barrier();
>> - }
>> + __READ_ONCE_SIZE;
>> +}
>> +
>> +#ifdef CONFIG_KASAN
>> +/*
>> + * This function is not 'inline' because __no_sanitize_address confilcts
>> + * with inlining. Attempt to inline it may cause a build failure.
>> + * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
>> + * '__maybe_unused' allows us to avoid defined-but-not-used warnings.
>> + */
>> +static __no_sanitize_address __maybe_unused
>> +void __read_once_size_nocheck(const volatile void *p, void *res, int size)
>> +{
>> + __READ_ONCE_SIZE;
>> }
>> +#else
>> +static __always_inline __alias(__read_once_size_check)
>> +void __read_once_size_nocheck(const volatile void *p, void *res, int size);
>> +#endif
>>
>> static __always_inline void __write_once_size(volatile void *p, void *res, int size)
>> {
>> @@ -248,8 +271,19 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s
>> * required ordering.
>> */
>>
>> -#define READ_ONCE(x) \
>> - ({ union { typeof(x) __val; char __c[1]; } __u; __read_once_size(&(x), __u.__c, sizeof(x)); __u.__val; })
>> +#define __READ_ONCE(x, check) \
>> +({ \
>> + union { typeof(x) __val; char __c[1]; } __u; \
>> + __read_once_size##check(&(x), __u.__c, sizeof(x)); \
>> + __u.__val; \
>> +})
>> +#define READ_ONCE(x) __READ_ONCE(x, _check)
>> +
>> +/*
>> + * Use READ_ONCE_NOCHECK() instead of READ_ONCE() if you need
>> + * to hide memory access from KASAN.
>> + */
>> +#define READ_ONCE_NOCHECK(x) __READ_ONCE(x, _nocheck)
>>
>> #define WRITE_ONCE(x, val) \
>> ({ \
>>
>
> --
> You received this message because you are subscribed to the Google Groups "kasan-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@...glegroups.com.
> To post to this group, send email to kasan-dev@...glegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20151014154532.GV3910%40linux.vnet.ibm.com.
> For more options, visit https://groups.google.com/d/optout.
--
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/
Powered by blists - more mailing lists