linux-kernel - Re: [PATCH v3 00/13] Kernel address sanitizer

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+bptO341KQAQMSzUVV22KsjuomdTeDip=HaHJ3+1kvraQ@mail.gmail.com>
Date:	Fri, 26 Sep 2014 10:29:34 -0700
From:	Dmitry Vyukov <dvyukov@...gle.com>
To:	Andrey Ryabinin <ryabinin.a.a@...il.com>
Cc:	Sasha Levin <sasha.levin@...cle.com>,
	Andrey Ryabinin <a.ryabinin@...sung.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Konstantin Serebryany <kcc@...gle.com>,
	Dmitry Chernenkov <dmitryc@...gle.com>,
	Andrey Konovalov <adech.fo@...il.com>,
	Yuri Gribov <tetra2005@...il.com>,
	Konstantin Khlebnikov <koct9i@...il.com>,
	Michal Marek <mmarek@...e.cz>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dave Hansen <dave.hansen@...el.com>,
	Andi Kleen <andi@...stfloor.org>,
	Vegard Nossum <vegard.nossum@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>, linux-kbuild@...r.kernel.org,
	x86@...nel.org, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Dave Jones <davej@...hat.com>
Subject: Re: [PATCH v3 00/13] Kernel address sanitizer - runtime memory debugger.

On Fri, Sep 26, 2014 at 10:22 AM, Andrey Ryabinin
<ryabinin.a.a@...il.com> wrote:
> 2014-09-26 21:07 GMT+04:00 Dmitry Vyukov <dvyukov@...gle.com>:
>> On Fri, Sep 26, 2014 at 10:01 AM, Sasha Levin <sasha.levin@...cle.com> wrote:
>>> On 09/24/2014 08:43 AM, Andrey Ryabinin wrote:
>>>> Hi.
>>>>
>>>> This is a third iteration of kerenel address sanitizer (KASan).
>>>>
>>>> KASan is a runtime memory debugger designed to find use-after-free
>>>> and out-of-bounds bugs.
>>>>
>>>> Currently KASAN supported only for x86_64 architecture and requires kernel
>>>> to be build with SLUB allocator.
>>>> KASAN uses compile-time instrumentation for checking every memory access, therefore you
>>>> will need a fresh GCC >= v5.0.0.
>>>
>>> Hi Andrey,
>>>
>>> I tried this patchset, with the latest gcc, and I'm seeing the following:
>>>
>>> arch/x86/kernel/head.o: In function `_GLOBAL__sub_I_00099_0_reserve_ebda_region':
>>> /home/sasha/linux-next/arch/x86/kernel/head.c:71: undefined reference to `__asan_init_v4'
>>> init/built-in.o: In function `_GLOBAL__sub_I_00099_0___ksymtab_system_state':
>>> /home/sasha/linux-next/init/main.c:1034: undefined reference to `__asan_init_v4'
>>> init/built-in.o: In function `_GLOBAL__sub_I_00099_0_init_uts_ns':
>>> /home/sasha/linux-next/init/version.c:50: undefined reference to `__asan_init_v4'
>>> init/built-in.o: In function `_GLOBAL__sub_I_00099_0_root_mountflags':
>>> /home/sasha/linux-next/init/do_mounts.c:638: undefined reference to `__asan_init_v4'
>>> init/built-in.o: In function `_GLOBAL__sub_I_00099_0_rd_prompt':
>>> /home/sasha/linux-next/init/do_mounts_rd.c:361: undefined reference to `__asan_init_v4'
>>> init/built-in.o:/home/sasha/linux-next/init/do_mounts_md.c:312: more undefined references to `__asan_init_v4' follow
>>>
>>>
>>> What am I missing?
>>
>>
>> Emission of __asan_init_vx needs to be disabled when
>> -fsanitize=kernel-address. Our kernel does not boot with them at all.
>> It probably hits some limit for something that can be increased. But I
>> don't want to investigate what that limit is, as __asan_init is not
>> needed for kasan at all.
>>
>
> __asan_init_vx maybe not needed for kernel, but we still need somehow
> to identify
> compiler's asan version (e.g. for globals).
> We could add some define to GCC or just something like this in kernel:
> #if __GNUC__ == 5
> #define ASAN_V4
> ....


This looks good to me.
The versioning won't work the same way it works for clang/compiler-rt
and gcc/libgcc. Because clang/compiler-rt are both part of the same
repo and always versioned simultaneously. While kernel and gcc are
versioned independently, so once you bump API version you break all
users who use old gcc.

So in kernel we will need to support all API versions, and the
following looks like a much simpler way to identify current API
version:
> #if __GNUC__ == 5
> #define ASAN_V4

Note that in user-space asan the other important purpose of
__asan_init is to trigger asan runtime initialization as early as
possible. This is not needed for kernel.
--
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/