[<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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
