From: Richard Weinberger <richard@nod.at>
To: Patricia Alfonso <trishalfonso@google.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
Dmitry Vyukov <dvyukov@google.com>, Jeff Dike <jdike@addtoit.com>,
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>
Subject: Re: [PATCH] UML: add support for KASAN under x86_64
Date: Tue, 31 Mar 2020 18:54:12 +0200 (CEST) [thread overview]
Message-ID: <418158403.63080.1585673652800.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <CAKFsvULjkQ7T6QhspHg87nnDpo-VW1qg2M3jJGB+NcwTQNeXGQ@mail.gmail.com>
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
next prev parent reply other threads:[~2020-03-31 16:54 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-26 0:46 [PATCH] UML: add support for KASAN under x86_64 Patricia Alfonso
2020-02-26 1:19 ` Brendan Higgins
2020-02-26 15:24 ` Dmitry Vyukov
2020-03-06 0:03 ` Patricia Alfonso
2020-03-11 10:32 ` Johannes Berg
2020-03-11 10:46 ` Dmitry Vyukov
2020-03-11 11:18 ` Johannes Berg
2020-03-11 11:40 ` Johannes Berg
2020-03-11 17:34 ` Dmitry Vyukov
2020-03-20 13:39 ` Johannes Berg
2020-03-20 15:18 ` Dmitry Vyukov
2020-03-30 7:43 ` Johannes Berg
2020-03-30 8:38 ` Dmitry Vyukov
2020-03-30 8:41 ` Johannes Berg
2020-03-31 6:14 ` David Gow
2020-03-31 7:43 ` Johannes Berg
2020-03-31 16:39 ` Patricia Alfonso
2020-03-31 16:54 ` Richard Weinberger [this message]
2020-03-11 22:32 ` Patricia Alfonso
2020-03-11 22:44 ` Johannes Berg
2022-05-24 10:34 ` Vincent Whitchurch
2022-05-24 10:45 ` Johannes Berg
2022-05-24 19:35 ` David Gow
2022-05-25 11:17 ` Vincent Whitchurch
2022-05-26 1:01 ` [RFC PATCH v3] " David Gow
2022-05-26 9:29 ` Johannes Berg
2022-05-27 5:31 ` Dmitry Vyukov
2022-05-27 7:32 ` Johannes Berg
2022-05-27 10:36 ` Johannes Berg
2022-05-27 13:05 ` Johannes Berg
2022-05-27 13:09 ` Dmitry Vyukov
2022-05-27 13:15 ` Johannes Berg
2022-05-27 13:18 ` Dmitry Vyukov
2022-05-27 13:27 ` Johannes Berg
2022-05-27 13:52 ` Dmitry Vyukov
2022-05-27 14:27 ` Johannes Berg
2022-05-27 15:46 ` Dmitry Vyukov
2020-03-29 19:06 ` [PATCH] " Richard Weinberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=418158403.63080.1585673652800.JavaMail.zimbra@nod.at \
--to=richard@nod.at \
--cc=anton.ivanov@cambridgegreys.com \
--cc=aryabinin@virtuozzo.com \
--cc=brendanhiggins@google.com \
--cc=davidgow@google.com \
--cc=dvyukov@google.com \
--cc=jdike@addtoit.com \
--cc=johannes@sipsolutions.net \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=trishalfonso@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).