linux-kernel - Re: [PATCH 24/30] x86, kaiser: disable native VSYSCALL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrVFDtj5m2eA_fq9n_s4+E2u6GDA-xEfNYPkJceicT4taQ@mail.gmail.com>
Date:   Thu, 9 Nov 2017 16:53:15 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Dave Hansen <dave.hansen@...ux.intel.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        moritz.lipp@...k.tugraz.at,
        Daniel Gruss <daniel.gruss@...k.tugraz.at>,
        michael.schwarz@...k.tugraz.at, richard.fellner@...dent.tugraz.at,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Kees Cook <keescook@...gle.com>,
        Hugh Dickins <hughd@...gle.com>, X86 ML <x86@...nel.org>
Subject: Re: [PATCH 24/30] x86, kaiser: disable native VSYSCALL

On Thu, Nov 9, 2017 at 11:26 AM, Dave Hansen
<dave.hansen@...ux.intel.com> wrote:
> On 11/09/2017 11:04 AM, Andy Lutomirski wrote:
>> On Wed, Nov 8, 2017 at 11:47 AM, Dave Hansen
>> <dave.hansen@...ux.intel.com> wrote:
>>>
>>> From: Dave Hansen <dave.hansen@...ux.intel.com>
>>>
>>> The VSYSCALL page is mapped by kernel page tables at a kernel address.
>>> It is troublesome to support with KAISER in place, so disable the
>>> native case.
>>>
>>> Also add some help text about how KAISER might affect the emulation
>>> case as well.
>>
>> Can you re-explain why this is helpful?
>
> How about this?
>
> The KAISER code attempts to "poison" the user portion of the kernel page
> tables.  It detects the entries pages that it wants that it wants to
> poison in two ways:
>  * Looking for addresses >= PAGE_OFFSET
>  * Looking for entries without _PAGE_USER set

What do you mean "poison"?

Anyway, the stuff here:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/entry_stack

is an attempt to create the infrastructure needed to move (almost?)
everything needed in the user tables into the fixmap.  If that ends up
working well, then perhaps the fixmap should just be completely
special-cased, in which case I think this issue goes away.  What I
have in mind is something like:

set_user_fixmap(index, pa, prot);

that sets an entry in the *user* fixmap.  All user mms would get the
same PGD entry for the user fixmap.

(And yes, it quite correctly fails kbuild bot right now.  That's why I
haven't emailed out the patches yet.)