From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com Sender: Ingo Molnar Date: Fri, 6 Jan 2017 07:49:00 +0100 From: Ingo Molnar Message-ID: <20170106064900.GC28091@gmail.com> References: <20170104221630.831-1-thgarnie@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: [kernel-hardening] Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location To: Thomas Garnier Cc: Andy Lutomirski , 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" List-ID: * Thomas Garnier wrote: > >> 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. > > A write is made when we use load_TR_desc (ltr). I didn't see any other yet. Is this write to the GDT, generated by the LTR instruction, done unconditionally by the hardware? Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034717AbdAFG50 (ORCPT ); Fri, 6 Jan 2017 01:57:26 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:36177 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751210AbdAFG5S (ORCPT ); Fri, 6 Jan 2017 01:57:18 -0500 Date: Fri, 6 Jan 2017 07:49:00 +0100 From: Ingo Molnar To: Thomas Garnier Cc: Andy Lutomirski , 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" Subject: Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location Message-ID: <20170106064900.GC28091@gmail.com> References: <20170104221630.831-1-thgarnie@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Thomas Garnier wrote: > >> 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. > > A write is made when we use load_TR_desc (ltr). I didn't see any other yet. Is this write to the GDT, generated by the LTR instruction, done unconditionally by the hardware? Thanks, Ingo