From: a.ryabinin@samsung•com (Andrey Ryabinin)
To: linux-arm-kernel@lists•infradead.org
Subject: [RFC/PATCH RESEND -next 01/21] Add kernel address sanitizer infrastructure.
Date: Thu, 10 Jul 2014 17:39:18 +0400 [thread overview]
Message-ID: <53BE9786.4060700@samsung.com> (raw)
In-Reply-To: <53BE959A.4010206@oracle.com>
On 07/10/14 17:31, Sasha Levin wrote:
> On 07/10/2014 09:01 AM, Andrey Ryabinin wrote:
>> On 07/10/14 15:55, Sasha Levin wrote:
>>>> On 07/09/2014 07:29 AM, Andrey Ryabinin wrote:
>>>>>> Address sanitizer for kernel (kasan) is a dynamic memory error detector.
>>>>>>
>>>>>> The main features of kasan is:
>>>>>> - is based on compiler instrumentation (fast),
>>>>>> - detects out of bounds for both writes and reads,
>>>>>> - provides use after free detection,
>>>>>>
>>>>>> This patch only adds infrastructure for kernel address sanitizer. It's not
>>>>>> available for use yet. The idea and some code was borrowed from [1].
>>>>>>
>>>>>> This feature requires pretty fresh GCC (revision r211699 from 2014-06-16 or
>>>>>> latter).
>>>>>>
>>>>>> Implementation details:
>>>>>> The main idea of KASAN is to use shadow memory to record whether each byte of memory
>>>>>> is safe to access or not, and use compiler's instrumentation to check the shadow memory
>>>>>> on each memory access.
>>>>>>
>>>>>> Address sanitizer dedicates 1/8 of the low memory to the shadow memory and uses direct
>>>>>> mapping with a scale and offset to translate a memory address to its corresponding
>>>>>> shadow address.
>>>>>>
>>>>>> Here is function to translate address to corresponding shadow address:
>>>>>>
>>>>>> unsigned long kasan_mem_to_shadow(unsigned long addr)
>>>>>> {
>>>>>> return ((addr - PAGE_OFFSET) >> KASAN_SHADOW_SCALE_SHIFT)
>>>>>> + kasan_shadow_start;
>>>>>> }
>>>>>>
>>>>>> where KASAN_SHADOW_SCALE_SHIFT = 3.
>>>>>>
>>>>>> So for every 8 bytes of lowmemory there is one corresponding byte of shadow memory.
>>>>>> The following encoding used for each shadow byte: 0 means that all 8 bytes of the
>>>>>> corresponding memory region are valid for access; k (1 <= k <= 7) means that
>>>>>> the first k bytes are valid for access, and other (8 - k) bytes are not;
>>>>>> Any negative value indicates that the entire 8-bytes are unaccessible.
>>>>>> Different negative values used to distinguish between different kinds of
>>>>>> unaccessible memory (redzones, freed memory) (see mm/kasan/kasan.h).
>>>>>>
>>>>>> To be able to detect accesses to bad memory we need a special compiler.
>>>>>> Such compiler inserts a specific function calls (__asan_load*(addr), __asan_store*(addr))
>>>>>> before each memory access of size 1, 2, 4, 8 or 16.
>>>>>>
>>>>>> These functions check whether memory region is valid to access or not by checking
>>>>>> corresponding shadow memory. If access is not valid an error printed.
>>>>>>
>>>>>> [1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel
>>>>>>
>>>>>> Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung•com>
>>>>
>>>> I gave it a spin, and it seems that it fails for what you might call a "regular"
>>>> memory size these days, in my case it was 18G:
>>>>
>>>> [ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate 0xe0c00000 bytes below 0x0.
>>>> [ 0.000000]
>>>> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.16.0-rc4-next-20140710-sasha-00044-gb7b0579-dirty #784
>>>> [ 0.000000] ffffffffb9c2d3c8 cd9ce91adea4379a 0000000000000000 ffffffffb9c2d3c8
>>>> [ 0.000000] ffffffffb9c2d330 ffffffffb7fe89b7 ffffffffb93c8c28 ffffffffb9c2d3b8
>>>> [ 0.000000] ffffffffb7fcff1d 0000000000000018 ffffffffb9c2d3c8 ffffffffb9c2d360
>>>> [ 0.000000] Call Trace:
>>>> [ 0.000000] <UNK> dump_stack (lib/dump_stack.c:52)
>>>> [ 0.000000] panic (kernel/panic.c:119)
>>>> [ 0.000000] memblock_alloc_base (mm/memblock.c:1092)
>>>> [ 0.000000] memblock_alloc (mm/memblock.c:1097)
>>>> [ 0.000000] kasan_alloc_shadow (mm/kasan/kasan.c:151)
>>>> [ 0.000000] zone_sizes_init (arch/x86/mm/init.c:684)
>>>> [ 0.000000] paging_init (arch/x86/mm/init_64.c:677)
>>>> [ 0.000000] setup_arch (arch/x86/kernel/setup.c:1168)
>>>> [ 0.000000] ? printk (kernel/printk/printk.c:1839)
>>>> [ 0.000000] start_kernel (include/linux/mm_types.h:462 init/main.c:533)
>>>> [ 0.000000] ? early_idt_handlers (arch/x86/kernel/head_64.S:344)
>>>> [ 0.000000] x86_64_start_reservations (arch/x86/kernel/head64.c:194)
>>>> [ 0.000000] x86_64_start_kernel (arch/x86/kernel/head64.c:183)
>>>>
>>>> It got better when I reduced memory to 1GB, but then my system just failed to boot
>>>> at all because that's not enough to bring everything up.
>>>>
>> Thanks.
>> I think memory size is not a problem here. I tested on my desktop with 16G.
>> Seems it's a problem with memory holes cited by Dave.
>> kasan tries to allocate ~3.5G. It means that lowmemsize is 28G in your case.
>
> That's correct (I've mistyped and got 18 instead of 28 above).
>
> However, I'm a bit confused here, I thought highmem/lowmem split was a 32bit
> thing, so I'm not sure how it applies here.
>
Right. By lowmemsize here I mean size of direct
mapping of all phys. memory (which usually called as lowmem on 32bit systems).
> Anyways, the machine won't boot with more than 1GB of RAM, is there a solution to
> get KASAN running on my machine?
>
Could you share you .config? I'll try to boot it by myself. It could be that some options conflicting with kasan.
Also boot cmdline might help.
>
> Thanks,
> Sasha
>
>
next prev parent reply other threads:[~2014-07-10 13:39 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-09 11:29 [RFC/PATCH RESEND -next 00/21] Address sanitizer for kernel (kasan) - dynamic memory error detector Andrey Ryabinin
2014-07-09 11:29 ` [RFC/PATCH RESEND -next 01/21] Add kernel address sanitizer infrastructure Andrey Ryabinin
2014-07-09 14:26 ` Christoph Lameter
2014-07-10 7:31 ` Andrey Ryabinin
2014-07-09 19:29 ` Andi Kleen
2014-07-09 20:40 ` Yuri Gribov
2014-07-10 12:10 ` Andrey Ryabinin
2014-07-09 20:26 ` Dave Hansen
2014-07-10 12:12 ` Andrey Ryabinin
2014-07-10 15:55 ` Dave Hansen
2014-07-10 19:48 ` Andrey Ryabinin
2014-07-10 20:04 ` Dave Hansen
2014-07-09 20:37 ` Dave Hansen
2014-07-09 20:38 ` Dave Hansen
2014-07-10 11:55 ` Sasha Levin
2014-07-10 13:01 ` Andrey Ryabinin
2014-07-10 13:31 ` Sasha Levin
2014-07-10 13:39 ` Andrey Ryabinin [this message]
2014-07-10 14:02 ` Sasha Levin
2014-07-10 19:04 ` Andrey Ryabinin
2014-07-10 13:50 ` Andrey Ryabinin
2014-07-09 11:29 ` [RFC/PATCH RESEND -next 02/21] init: main: initialize kasan's shadow area on boot Andrey Ryabinin
2014-07-09 11:29 ` [RFC/PATCH RESEND -next 03/21] x86: add kasan hooks fort memcpy/memmove/memset functions Andrey Ryabinin
2014-07-09 19:31 ` Andi Kleen
2014-07-10 13:54 ` Andrey Ryabinin
2014-07-09 11:29 ` [RFC/PATCH RESEND -next 04/21] x86: boot: vdso: disable instrumentation for code not linked with kernel Andrey Ryabinin
2014-07-09 11:29 ` [RFC/PATCH RESEND -next 05/21] x86: cpu: don't sanitize early stages of a secondary CPU boot Andrey Ryabinin
2014-07-09 19:33 ` Andi Kleen
2014-07-10 13:15 ` Andrey Ryabinin
2014-07-09 11:30 ` [RFC/PATCH RESEND -next 06/21] x86: mm: init: allocate shadow memory for kasan Andrey Ryabinin
2014-07-09 11:30 ` [RFC/PATCH RESEND -next 07/21] x86: Kconfig: enable kernel address sanitizer Andrey Ryabinin
2014-07-09 11:30 ` [RFC/PATCH RESEND -next 08/21] mm: page_alloc: add kasan hooks on alloc and free pathes Andrey Ryabinin
2014-07-15 5:52 ` Joonsoo Kim
2014-07-15 6:54 ` Andrey Ryabinin
2014-07-09 11:30 ` [RFC/PATCH RESEND -next 09/21] mm: Makefile: kasan: don't instrument slub.c and slab_common.c files Andrey Ryabinin
2014-07-09 11:30 ` [RFC/PATCH RESEND -next 10/21] mm: slab: share virt_to_cache() between slab and slub Andrey Ryabinin
2014-07-15 5:53 ` Joonsoo Kim
2014-07-15 6:56 ` Andrey Ryabinin
2014-07-09 11:30 ` [RFC/PATCH RESEND -next 11/21] mm: slub: share slab_err and object_err functions Andrey Ryabinin
2014-07-09 14:29 ` Christoph Lameter
2014-07-10 7:41 ` Andrey Ryabinin
2014-07-10 14:07 ` Christoph Lameter
2014-07-09 11:30 ` [RFC/PATCH RESEND -next 12/21] mm: util: move krealloc/kzfree to slab_common.c Andrey Ryabinin
2014-07-09 14:32 ` Christoph Lameter
2014-07-10 7:43 ` Andrey Ryabinin
2014-07-10 14:08 ` Christoph Lameter
2014-07-09 11:30 ` [RFC/PATCH RESEND -next 13/21] mm: slub: add allocation size field to struct kmem_cache Andrey Ryabinin
2014-07-09 14:33 ` Christoph Lameter
2014-07-10 8:44 ` Andrey Ryabinin
2014-07-09 11:30 ` [RFC/PATCH RESEND -next 14/21] mm: slub: kasan: disable kasan when touching unaccessible memory Andrey Ryabinin
2014-07-15 6:04 ` Joonsoo Kim
2014-07-15 7:37 ` Andrey Ryabinin
2014-07-15 8:18 ` Joonsoo Kim
2014-07-15 9:51 ` Andrey Ryabinin
2014-07-15 14:26 ` Christoph Lameter
2014-07-15 15:02 ` Andrey Ryabinin
2014-07-09 11:30 ` [RFC/PATCH RESEND -next 15/21] mm: slub: add kernel address sanitizer hooks to slub allocator Andrey Ryabinin
2014-07-09 14:48 ` Christoph Lameter
2014-07-10 9:24 ` Andrey Ryabinin
2014-07-15 6:09 ` Joonsoo Kim
2014-07-15 7:45 ` Andrey Ryabinin
2014-07-09 11:30 ` [RFC/PATCH RESEND -next 16/21] arm: boot: compressed: disable kasan's instrumentation Andrey Ryabinin
2014-07-09 11:30 ` [RFC/PATCH RESEND -next 17/21] arm: add kasan hooks fort memcpy/memmove/memset functions Andrey Ryabinin
2014-07-09 11:30 ` [RFC/PATCH RESEND -next 18/21] arm: mm: reserve shadow memory for kasan Andrey Ryabinin
2014-07-09 11:30 ` [RFC/PATCH RESEND -next 19/21] arm: Kconfig: enable kernel address sanitizer Andrey Ryabinin
2014-07-09 11:30 ` [RFC/PATCH RESEND -next 20/21] fs: dcache: manually unpoison dname after allocation to shut up kasan's reports Andrey Ryabinin
2014-07-15 6:12 ` Joonsoo Kim
2014-07-15 6:08 ` Dmitry Vyukov
2014-07-15 9:34 ` Andrey Ryabinin
2014-07-15 9:45 ` Dmitry Vyukov
2014-07-09 11:30 ` [RFC/PATCH RESEND -next 21/21] lib: add kmalloc_bug_test module Andrey Ryabinin
2014-07-09 21:19 ` [RFC/PATCH RESEND -next 00/21] Address sanitizer for kernel (kasan) - dynamic memory error detector Dave Hansen
2014-07-09 21:44 ` Andi Kleen
2014-07-09 21:59 ` Vegard Nossum
2014-07-09 23:33 ` Dave Hansen
2014-07-10 0:03 ` Andi Kleen
2014-07-10 13:59 ` Andrey Ryabinin
[not found] ` <1421859105-25253-1-git-send-email-a.ryabinin@samsung.com>
2015-01-21 16:51 ` [PATCH v9 14/17] mm: vmalloc: pass additional vm_flags to __vmalloc_node_range() Andrey Ryabinin
[not found] ` <1422544321-24232-1-git-send-email-a.ryabinin@samsung.com>
2015-01-29 15:11 ` [PATCH v10 " Andrey Ryabinin
[not found] ` <1422985392-28652-1-git-send-email-a.ryabinin@samsung.com>
2015-02-03 17:43 ` [PATCH v11 16/19] " Andrey Ryabinin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53BE9786.4060700@samsung.com \
--to=a.ryabinin@samsung$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox