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:45:31 +0100 From: Ingo Molnar Message-ID: <20170106064531.GB28091@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: Arjan van de Ven Cc: Thomas Garnier , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Kees Cook , Borislav Petkov , Andy Lutomirski , 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: * 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 ? Yes - but the idea would be to have two virtual memory aliases: 1) A world-readable RO mapping of the GDT put into the fixmap area (randomization is not really required as the SGDT instruction exposes it anyway). This read-only GDT mapping has two advantages: - Because the GDT address is read-only it cannot be used by exploits as an easy trampoline for 100% safe, deterministic rooting of the system from a local process. - Even on older CPUs the SGDT instruction won't expose the absolute address of critical kernel data structures. 2) A kernel-only RW mapping in the linear kernel memory map where the original page is - randomized (as a natural part of kernel physical and virtual memory randomization) and only known and accessible to the kernel, SGDT doesn't expose it even on older CPUs. This way we IMHO have the best of both worlds. Assuming there are no strange CPU errata surfacing if we use a RO GDT - OTOH that should be fairly easy to test for, and worst-case we could quirk-off the feature on CPUs where this cannot be done safely. 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 S939454AbdAFGpl (ORCPT ); Fri, 6 Jan 2017 01:45:41 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:33022 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S938042AbdAFGpg (ORCPT ); Fri, 6 Jan 2017 01:45:36 -0500 Date: Fri, 6 Jan 2017 07:45:31 +0100 From: Ingo Molnar To: Arjan van de Ven Cc: Thomas Garnier , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Kees Cook , Borislav Petkov , Andy Lutomirski , 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: <20170106064531.GB28091@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 * 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 ? Yes - but the idea would be to have two virtual memory aliases: 1) A world-readable RO mapping of the GDT put into the fixmap area (randomization is not really required as the SGDT instruction exposes it anyway). This read-only GDT mapping has two advantages: - Because the GDT address is read-only it cannot be used by exploits as an easy trampoline for 100% safe, deterministic rooting of the system from a local process. - Even on older CPUs the SGDT instruction won't expose the absolute address of critical kernel data structures. 2) A kernel-only RW mapping in the linear kernel memory map where the original page is - randomized (as a natural part of kernel physical and virtual memory randomization) and only known and accessible to the kernel, SGDT doesn't expose it even on older CPUs. This way we IMHO have the best of both worlds. Assuming there are no strange CPU errata surfacing if we use a RO GDT - OTOH that should be fairly easy to test for, and worst-case we could quirk-off the feature on CPUs where this cannot be done safely. Thanks, Ingo