From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938866AbdAEVUR (ORCPT ); Thu, 5 Jan 2017 16:20:17 -0500 Received: from mail-ua0-f171.google.com ([209.85.217.171]:36200 "EHLO mail-ua0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S938838AbdAEVUI (ORCPT ); Thu, 5 Jan 2017 16:20:08 -0500 MIME-Version: 1.0 In-Reply-To: References: <20170104221630.831-1-thgarnie@google.com> From: Andy Lutomirski Date: Thu, 5 Jan 2017 13:19:46 -0800 Message-ID: Subject: Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location To: Thomas Garnier Cc: Andy Lutomirski , Arjan van de Ven , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Kees Cook , Borislav Petkov , Dave Hansen , Chen Yucong , Paul Gortmaker , Andrew Morton , Masahiro Yamada , Sebastian Andrzej Siewior , Anna-Maria Gleixner , Boris Ostrovsky , Rasmus Villemoes , Michael Ellerman , Juergen Gross , Richard Weinberger , X86 ML , "linux-kernel@vger.kernel.org" , "kernel-hardening@lists.openwall.com" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 5, 2017 at 1:08 PM, Thomas Garnier wrote: > On Thu, Jan 5, 2017 at 12:18 PM, Andy Lutomirski wrote: >> On Thu, Jan 5, 2017 at 11:03 AM, Thomas Garnier wrote: >>> On Thu, Jan 5, 2017 at 10:58 AM, Arjan van de Ven 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