lkml.org 
[lkml]   [2014]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v6 00/11] Kernel address sanitizer - runtime memory debugger.
    From
    2014-11-19 2:38 GMT+03:00 Sasha Levin <sasha.levin@oracle.com>:
    > 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@kvack.org. For more info on Linux MM,
    > see: http://www.linux-mm.org/ .
    > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>



    --
    Best regards,
    Andrey Ryabinin


    \
     
     \ /
      Last update: 2014-11-19 01:21    [W:4.784 / U:0.856 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site