Re: [PATCH v6 00/11] Kernel address sanitizer - runtime memory debugger.

[Andrey Ryabinin]

2014-11-19 2:38 GMT+03:00 Sasha Levin <sasha.levin@xxxxxxxxxx>:
> Hi Andrey,
>
> After the recent exchange of mails about kasan it came to me that I haven't
> seen a kasan warning for a while now. To give kasan a quick test I added a rather
> simple error which should generate a kasan warning about accessing userspace
> memory (yes, I know kasan has a test module but my setup doesn't like modules):
>
>         diff --git a/net/socket.c b/net/socket.c
>         index fe20c31..794e9f4 100644
>         --- a/net/socket.c
>         +++ b/net/socket.c
>         @@ -1902,7 +1902,7 @@ SYSCALL_DEFINE5(setsockopt, int, fd, int, level, int, optname,
>          {
>                 int err, fput_needed;
>                 struct socket *sock;
>         -
>         +       *((char *)10) = 5;
>                 if (optlen < 0)
>                         return -EINVAL;
>
> A gfp was triggered, but no kasan warning was shown.
>

Yes with CONFIG_KASAN_INLINE you will get GPF instead of kasan report.
For userspaces addresses we don't have shadow memory. In outline case
I just check address itself before checking shadow. In inline case compiler
just checks shadow, so there is no way to avoid GPF.

To be able to print report instead of GPF, I need to treat GPFs in a special
way if inline instrumentation was enabled, but it's not done yet.

> I remembered that one of the biggest changes in kasan was the introduction of
> inline instrumentation, so I went ahead to disable it and see if it helps. But
> the only result of that was having the boot process hang pretty early:
>
> [...]
> [    0.000000] IOAPIC[0]: apic_id 21, version 17, address 0xfec00000, GSI 0-23
> [    0.000000] Processors: 20
> [    0.000000] smpboot: Allowing 24 CPUs, 4 hotplug CPUs
> [    0.000000] e820: [mem 0xd0000000-0xffffffff] available for PCI devices
> [    0.000000] Booting paravirtualized kernel on KVM
> [    0.000000] setup_percpu: NR_CPUS:8192 nr_cpumask_bits:24 nr_cpu_ids:24 nr_node_ids:1
> [    0.000000] PERCPU: Embedded 491 pages/cpu @ffff8808dce00000 s1971864 r8192 d31080 u2097152
> *HANG*
>

This hang happens only with your error patch above or even without it?
In any case I'll look tomorrow.

> I'm using the latest gcc:
>
> $ gcc --version
> gcc (GCC) 5.0.0 20141117 (experimental)
>
>
> I'll continue looking into it tomorrow, just hoping it rings a bell...
>
>
> Thanks,
> Sasha
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



-- 
Best regards,
Andrey Ryabinin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/