linux-kernel - Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

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: <CALCETrUpC-Zp-mHCMVE6QdXTnzJDQLyckqaZhW0KJfZeX=oxXg@mail.gmail.com>
Date:   Thu, 5 Jan 2017 13:19:46 -0800
From:   Andy Lutomirski <luto@...capital.net>
To:     Thomas Garnier <thgarnie@...gle.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        Kees Cook <keescook@...omium.org>,
        Borislav Petkov <bp@...en8.de>, Dave Hansen <dave@...1.net>,
        Chen Yucong <slaoub@...il.com>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Anna-Maria Gleixner <anna-maria@...utronix.de>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Michael Ellerman <mpe@...erman.id.au>,
        Juergen Gross <jgross@...e.com>,
        Richard Weinberger <richard@....at>, X86 ML <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kernel-hardening@...ts.openwall.com" 
        <kernel-hardening@...ts.openwall.com>
Subject: Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On Thu, Jan 5, 2017 at 1:08 PM, Thomas Garnier <thgarnie@...gle.com> wrote:
> On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski <luto@...nel.org> wrote:
>> On Thu, Jan 5, 2017 at 11:03 AM, Thomas Garnier <thgarnie@...gle.com> wrote:
>>> On Thu, Jan 5, 2017 at 10:58 AM, Arjan van de Ven <arjan@...ux.intel.com> wrote:
>>>> On 1/5/2017 9:54 AM, Thomas Garnier wrote:
>>>>
>>>>>
>>>>> That's my goal too. I started by doing a RO remap and got couple
>>>>> problems with hibernation. I can try again for the next iteration or
>>>>> delay it for another patch. I also need to look at KVM GDT usage, I am
>>>>> not familiar with it yet.
>>>>
>>>>
>>>> don't we write to the GDT as part of the TLS segment stuff for glibc ?
>>>>
>>>
>>> Not sure which glibc feature it is.
>>>
>>> In this design, you can write to the GDT per-cpu variable that will
>>> remain read-write. You just need to make the remapping writeable when
>>> we load task registers (ltr) then the processor use the current GDT
>>> address. At least that the case I know, I might find more through
>>> testing.
>>
>> Hmm.  I bet that if we preset the accessed bits in all the segments
>> then we don't need it to be writable in general.  But your point about
>> set_thread_area (TLS) is well taken.  However, I strongly suspect that
>> we could make set_thread_area unconditionally set the accessed bit and
>> no one would ever notice.
>
> Not sure I fully understood and I don't want to miss an important
> point. Do you mean making GDT (remapping and per-cpu) read-only and
> switch the writeable flag only when we write to the per-cpu entry?
>

What I mean is: write to the GDT through normal percpu access (or
whatever the normal mapping is) but load a read-only alias into the
GDT register.  As long as nothing ever tries to write through the GDTR
alias, no page faults will be generated.  So we just need to make sure
that nothing ever writes to it through GDTR.  AFAIK the only reason
the CPU ever writes to the address in GDTR is to set an accessed bit.

--Andy