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  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 Oct 2015 11:11:08 -0700
From:	Andy Lutomirski <>
To:	Ingo Molnar <>
Cc:	Andrey Ryabinin <>,
	Andi Kleen <>,
	Dmitry Vyukov <>,
	Thomas Gleixner <>,
	Ingo Molnar <>,
	"H. Peter Anvin" <>,
	"" <>,
	LKML <>,
	Andrey Konovalov <>,
	Kostya Serebryany <>,
	Alexander Potapenko <>,
	kasan-dev <>,
	Borislav Petkov <>,
	Denys Vlasenko <>,
	Sasha Levin <>,
	Wolfram Gloger <>,
	Linus Torvalds <>,
	Andrew Morton <>
Subject: Re: [PATCH] x86/process: Silence KASAN warnings in get_wchan()

On Tue, Oct 6, 2015 at 12:26 AM, Ingo Molnar <> wrote:
> * Andrey Ryabinin <> wrote:
>> On 10/05/2015 07:39 PM, Andi Kleen wrote:
>> >> But, I think I have the solution.
>> >> We could have some blacklist - list of function names which we should be ignored.
>> >> In kasan_report() we could resolve return address to function name and compare it with name in list.
>> >> If name in list -> ignore report.
>> >
>> > I think annotating statements is cleaner than functions, even if it
>> > is more code. Much better documentation
>> >
>> I agree with that, that's why I suggested to add READ_ONCE_NOCHECK():
>>       {
>>               kasan_disable_current();
>>               READ_ONCE();
>>               kasan_enable_current();
>>       }
>> Anywone objects?
> Sounds good to me! As long as it's hidden from plain .c files I'm a happy camper.
> This should probably also be faster for KASAN than triggering a warning and having
> to parse a blacklist, right?
>> > If disabling with an attribute doesn't work, you could put it into a special
>> > section with __attribute__((section ...)) and check the start/end symbol
>> > before reporting. That's how kprobes solves similar issues. It also has the
>> > advantage that it stops inlining.
>> Yes, it might be better. Although, because of broken -fconserve-stack, this may
>> not work in some cases -
>> Function splitter may split original function into two parts and it always puts
>> one split part in default .text section.
> We do a _ton_ of such section tricks in the kernel (all of exception handling is
> based on that) - if that's broken by -fconserve-stack then the kernel is broken
> much more widely.
> So unless KASAN wants to do something special here you can rely on sections just
> fine.

Kprobes is moving away from a section approach for some reason (not
sure why), but the kprobe approach should work, too.

But what's wrong with the GCC attribute mechanism?  Surely GCC ought
to be able to generate the code, at least in the simple cases, and the
attribute already exists.  The attribute and READ_ONCE_NOCHECK seem
like the least messy in the C code.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists