Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965467AbeAKScO (ORCPT + 1 other); Thu, 11 Jan 2018 13:32:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53501 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752253AbeAKScM (ORCPT ); Thu, 11 Jan 2018 13:32:12 -0500 Date: Thu, 11 Jan 2018 12:32:07 -0600 From: Josh Poimboeuf To: Alexei Starovoitov Cc: Andy Lutomirski , Dave Hansen , Willy Tarreau , Linus Torvalds , Peter Zijlstra , LKML , X86 ML , Borislav Petkov , Brian Gerst , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Greg Kroah-Hartman , Kees Cook Subject: Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set Message-ID: <20180111183207.dah7imbuvuhvrrk6@treble> References: <20180110082207.GX29822@worktop.programming.kicks-ass.net> <20180110091102.GH14066@1wt.eu> <20180111064259.GC14920@1wt.eu> <0f08d89e-61e1-20e3-5c59-0b2f7b32bf0c@linux.intel.com> <20180111154412.GA15296@1wt.eu> <20180111182147.masunghp5km6igjq@ast-mbp.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180111182147.masunghp5km6igjq@ast-mbp.dhcp.thefacebook.com> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 11 Jan 2018 18:32:12 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Thu, Jan 11, 2018 at 10:21:49AM -0800, Alexei Starovoitov wrote: > On Thu, Jan 11, 2018 at 09:02:55AM -0800, Andy Lutomirski wrote: > > On Thu, Jan 11, 2018 at 7:51 AM, Dave Hansen > > wrote: > > > On 01/11/2018 07:44 AM, Willy Tarreau wrote: > > >>> I think we also need to be able to dump the actual > > >>> CR3 value that we entered the kernel with before we start doing too much > > >>> other funky stuff with the entry code. > > >> When you say dump, you mean save it somewhere in a per_cpu variable ? > > > > > > Yeah, I think a per-cpu variable is fine for now. But, that only gives > > > you a dump from a single entry to the kernel. Ideally, it would be nice > > > to have a stack of them so you could do things like debug > > > syscall->fault->oops. Was it the syscall entry or the fault entry that > > > lead to the oops? > > > > > > But, the stack gets really fun because of NMIs. > > > > > > I'm sure Andy Lutomirski has some ideas too. > > > > I was thinking that maybe we should add a new field or two to pt_regs. > > They could store CR2 and maybe CR3 as well. I'd also like to expose > > the error code of exceptions in stack traces. We should get this > > integrated right into the unwinder. > > hmm. Exposing cr3 to user space will make it trivial for user process > to know whether kpti is active. Not sure how exploitable such > information leak. It's already trivial to detect PTI from user space. -- Josh