[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+b4+5PQvUeeHi=3g0my0WbaRaNEWY3P-MOVJXYSO7U5aA@mail.gmail.com>
Date: Thu, 16 Jan 2020 09:52:52 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Patricia Alfonso <trishalfonso@...gle.com>
Cc: Jeff Dike <jdike@...toit.com>, Richard Weinberger <richard@....at>,
anton.ivanov@...bridgegreys.com,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
David Gow <davidgow@...gle.com>,
Brendan Higgins <brendanhiggins@...gle.com>,
linux-um@...ts.infradead.org,
kasan-dev <kasan-dev@...glegroups.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] UML: add support for KASAN under x86_64
> +void kasan_init(void)
> +{
> + kasan_map_memory((void *)KASAN_SHADOW_START, KASAN_SHADOW_SIZE);
> +
> + // unpoison the kernel text which is form uml_physmem -> uml_reserved
> + kasan_unpoison_shadow((void *)uml_physmem, physmem_size);
> +
> + // unpoison the vmalloc region, which is start_vm -> end_vm
> + kasan_unpoison_shadow((void *)start_vm, (end_vm - start_vm + 1));
> +
> + init_task.kasan_depth = 0;
> + pr_info("KernelAddressSanitizer initialized\n");
> +}
Was this tested with stack instrumentation? Stack instrumentation
changes what shadow is being read/written and when. We don't need to
get it working right now, but if it does not work it would be nice to
restrict the setting and leave some comment traces for future
generations.
Powered by blists - more mailing lists