lkml.org 
[lkml]   [2020]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] UML: add support for KASAN under x86_64
    Patricia,

    ----- Ursprüngliche Mail -----
    > Von: "Patricia Alfonso" <trishalfonso@google.com>
    > An: "Johannes Berg" <johannes@sipsolutions.net>
    > CC: "Dmitry Vyukov" <dvyukov@google.com>, "Jeff Dike" <jdike@addtoit.com>, "richard" <richard@nod.at>, "anton ivanov"
    > <anton.ivanov@cambridgegreys.com>, "Andrey Ryabinin" <aryabinin@virtuozzo.com>, "Brendan Higgins"
    > <brendanhiggins@google.com>, "davidgow" <davidgow@google.com>, "linux-um" <linux-um@lists.infradead.org>,
    > "linux-kernel" <linux-kernel@vger.kernel.org>, "kasan-dev" <kasan-dev@googlegroups.com>
    > Gesendet: Dienstag, 31. März 2020 18:39:21
    > Betreff: Re: [PATCH] UML: add support for KASAN under x86_64

    > On Mon, Mar 30, 2020 at 1:41 AM Johannes Berg <johannes@sipsolutions.net> wrote:
    >>
    >> On Mon, 2020-03-30 at 10:38 +0200, Dmitry Vyukov wrote:
    >> > On Mon, Mar 30, 2020 at 9:44 AM Johannes Berg <johannes@sipsolutions.net> wrote:
    >> > > On Fri, 2020-03-20 at 16:18 +0100, Dmitry Vyukov wrote:
    >> > > > > Wait ... Now you say 0x7fbfffc000, but that is almost fine? I think you
    >> > > > > confused the values - because I see, on userspace, the following:
    >> > > >
    >> > > > Oh, sorry, I copy-pasted wrong number. I meant 0x7fff8000.
    >> > >
    >> > > Right, ok.
    >> > >
    >> > > > Then I would expect 0x1000 0000 0000 to work, but you say it doesn't...
    >> > >
    >> > > So it just occurred to me - as I was mentioning this whole thing to
    >> > > Richard - that there's probably somewhere some check about whether some
    >> > > space is userspace or not.
    >> > >
    >
    > Yeah, it seems the "Kernel panic - not syncing: Segfault with no mm",
    > "Kernel mode fault at addr...", and "Kernel tried to access user
    > memory at addr..." errors all come from segv() in
    > arch/um/kernel/trap.c due to what I think is this type of check
    > whether the address is
    > in userspace or not.

    Segfault with no mm means that a (not fixable) pagefault happened while
    kernel code ran.

    >> > > I'm beginning to think that we shouldn't just map this outside of the
    >> > > kernel memory system, but properly treat it as part of the memory that's
    >> > > inside. And also use KASAN_VMALLOC.
    >> > >
    >> > > We can probably still have it at 0x7fff8000, just need to make sure we
    >> > > actually map it? I tried with vm_area_add_early() but it didn't really
    >> > > work once you have vmalloc() stuff...
    >> >
    >
    > What x86 does when KASAN_VMALLOC is disabled is make all vmalloc
    > region accesses succeed by default
    > by using the early shadow memory to have completely unpoisoned and
    > unpoisonable read-only pages for all of vmalloc (which includes
    > modules). When KASAN_VMALLOC is enabled in x86, the shadow memory is not
    > allocated for the vmalloc region at startup. New chunks of shadow
    > memory are allocated and unpoisoned every time there's a vmalloc()
    > call. A similar thing might have to be done here by mprotect()ing
    > the vmalloc space as read only, unpoisoned without KASAN_VMALLOC. This
    > issue here is that
    > kasan_init runs so early in the process that the vmalloc region for
    > uml is not setup yet.
    >
    >
    >> > But we do mmap it, no? See kasan_init() -> kasan_map_memory() -> mmap.
    >>
    >> Of course. But I meant inside the UML PTE system. We end up *unmapping*
    >> it when loading modules, because it overlaps vmalloc space, and then we
    >> vfree() something again, and unmap it ... because of the overlap.
    >>
    >> And if it's *not* in the vmalloc area, then the kernel doesn't consider
    >> it valid, and we seem to often just fault when trying to determine
    >> whether it's valid kernel memory or not ... Though I'm not really sure I
    >> understand the failure part of this case well yet.
    >>
    >
    > I have been testing this issue in a multitude of ways and have only
    > been getting more confused. It's still very unclear where exactly the
    > problem occurs, mostly because the errors I found most frequently were
    > reported in segv(), but the stack traces never contained segv.
    >
    > Does anyone know if/how UML determines if memory being accessed is
    > kernel or user memory?

    In contrast to classic x86, without KPTI and SMAP/SMEP, UML has a strong
    separation between user- and kernel-memory. This is also why copy_from/to_user()
    is so expensive.

    In arch/um/kernel/trap.c segv() you can see the logic.
    Also see UPT_IS_USER().

    Thanks,
    //richard

    \
     
     \ /
      Last update: 2020-03-31 18:54    [W:2.606 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site