On Fri, Jul 18, 2014 at 05:19:39PM +0400, Dmitry Vyukov wrote:
> On Fri, Jul 18, 2014 at 4:26 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> > On Fri, Jul 18, 2014 at 03:40:15PM +0400, Yury Gribov wrote:
> >> This tiny patch adds support for KernelASan. KASan brings Asan error
> >> detection capabilities to Linux kernel
> >> (https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel).
> >>
> >> KASan works similar to normal userspace ASan but disables some options
> >> which
> >> are not yet supported by kernel (notably inline instrumentation,
> >> stack/global protection and UAR). We would prefer to hide all necessary
> >> tweaks under a user-friendly flag (-fsanitize=kernel-address) instead of
> >> forcing them directly in kernel's CFLAGS.
> >>
> >> Kernel patches are currently under review in LKML
> >> (https://lkml.org/lkml/2014/7/9/990).
> >
> > I thought KAsan used different entry points (__kasan_* etc.), has that
> > changed?
>
> Yes, we've switched to __asan_.
Ok.
> > Also, oring in SANITIZER_ADDRESS means you add -lasan to link flags, I'd
> > guess that for -fsanitize=kernel-address you don't want to add any libraries
> > at link time?
>
> I suspect that we don't pass -fsanitize=kernel-address during linking
> in kernel today. But I agree that it's better to disable any
> processing during linking for now. Later we may want to do something
> special during linking if -fsanitize=kernel-address is supplied.
>
> > Do you error out on -fsanitize=thread -fsanitize=kernel-address ?
> > Perhaps -fsanitize=kernel-address -fsanitize=address should be invalid too?
>
> Yes, all these combinations are invalid.
But you don't error out on that.
If we want to diagnose the last, IMHO we can't have just SANITIZE_ADDRESS
and SANITIZE_KERNEL_ADDRESS flags, but instead should have
SANITIZE_ADDRESS (used when we don't care about kernel vs. user asan
differences), SANITIZE_USER_ADDRESS and SANITIZE_KERNEL_ADDRESS bits.
"address" would set SANITIZE_ADDRESS | SANITIZE_USER_ADDRESS,
"kernel-address" SANITIZE_ADDRESS | SANITIZE_KERNEL_ADDRESS.
Then in sanitize_spec_function supposedly for "address" check
SANITIZE_USER_ADDRESS bit, for "kernel-address" added there
SANITIZE_KERNEL_ADDRESS, add all the incompatibility diagnostics for the new
invalid combinations. Plus, toplev.c has e.g.:
/* Address Sanitizer needs porting to each target architecture. */
if ((flag_sanitize & SANITIZE_ADDRESS)
&& (targetm.asan_shadow_offset == NULL
|| !FRAME_GROWS_DOWNWARD))
{
warning (0, "-fsanitize=address not supported for this target");
flag_sanitize &= ~SANITIZE_ADDRESS;
}
Now, is the same really the case for SANITIZE_KERNEL_ADDRESS?
I guess we still inline the shadow memory accesses to poison/unpoison
stack in function prologue/epilogue, right? In that case without
asan_shadow_offset we can't do anything. If it was a function call instead
it would be portable to all architectures.
Jakub
