linux-kernel - Re: [PATCH] x86/process: Silence KASAN warnings in get

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: <CALCETrUxUOhuqQr5wsrea1L2sTi9-vRXco2AswkReaLwpa3cMg@mail.gmail.com>
Date:	Tue, 6 Oct 2015 11:11:08 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Andrey Ryabinin <aryabinin@...tuozzo.com>,
	Andi Kleen <ak@...ux.intel.com>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"x86@...nel.org" <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrey Konovalov <andreyknvl@...gle.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Alexander Potapenko <glider@...gle.com>,
	kasan-dev <kasan-dev@...glegroups.com>,
	Borislav Petkov <bp@...en8.de>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	Wolfram Gloger <wmglo@...t.med.uni-muenchen.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] x86/process: Silence KASAN warnings in get_wchan()

On Tue, Oct 6, 2015 at 12:26 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Andrey Ryabinin <aryabinin@...tuozzo.com> 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():
>>       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 - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63533
>> 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.

--Andy
--
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/