Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (1.0)
Subject: Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set
From: Andy Lutomirski <luto@amacapital.net>
In-Reply-To: <20180112202238.hc2dkjvmu7wlz7xw@gmail.com>
Date: Fri, 12 Jan 2018 13:18:06 -0800
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
        Willy Tarreau <w@1wt.eu>, Andy Lutomirski <luto@kernel.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
        Borislav Petkov <bp@alien8.de>,
        Brian Gerst <brgerst@gmail.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Kees Cook <keescook@chromium.org>
Content-Transfer-Encoding: 8BIT
Message-Id: <C9045544-686E-4650-93CD-4609341C0060@amacapital.net>
References: <CALCETrXQFL2sJPJe_Z8XLEo11V_tLyZR0y4PTRxJzrhmpdsuJg@mail.gmail.com> <CA+55aFwfSKNAYEFWCwCe2vSxejA3X85FnX9t1EdnCRUwC1ou1Q@mail.gmail.com> <20180111064259.GC14920@1wt.eu> <0f08d89e-61e1-20e3-5c59-0b2f7b32bf0c@linux.intel.com> <20180111154412.GA15296@1wt.eu> <CALCETrVcQg_1opnvOP4ksOAC07K4O_LTSxy2czwtObwR3YL+-w@mail.gmail.com> <20180111174025.GB15344@1wt.eu> <CA+55aFzOAAJ+WwA6BGAqW_h-r3_dYNpvgsmHcbpugwu4emcS6g@mail.gmail.com> <CA+55aFwwWHM2BUVKXemPX3RXXn=TiPXu8YnRXVLB9toRwcKU1g@mail.gmail.com> <50EB5B67-E441-43A6-8DD7-650A75B6ABE7@amacapital.net> <20180112202238.hc2dkjvmu7wlz7xw@gmail.com>
To: Ingo Molnar <mingo@kernel.org>
Sender: linux-kernel-owner@vger.kernel.org


> On Jan 12, 2018, at 12:22 PM, Ingo Molnar <mingo@kernel.org> wrote:
> 
> 
> * Andy Lutomirski <luto@amacapital.net> wrote:
> 
>>> Oh, and yes, I think the npti flag should also break ptrace(). I do agree with 
>>> Andy that it's a "capability", although I do not think it should actually be 
>>> implemented as one.
>> 
>> For all that Linux capabilities are crap, nopti walks like one and quacks like 
>> one.  It needs to affect ptrace() permissions, it needs a way to disable it 
>> systemwide, it needs LSM integration, etc.  Using CAP_DISABLE_PTI gives us all 
>> of this without tons of churn, auditing, and a whole new configuration thingy 
>> for each LSM.  And I avoids permanently polluting ptrace checks, the LSM 
>> interface, etc for what is, essentially, a performance hack to work around a 
>> blatant error in the design of some CPUs.
>> 
>> Plus, with ambient caps, we already did the nasty part of the with and finished 
>> all the relevant bikeshedding.
>> 
>> So I'd rather just hold my nose and add the new capability bit.
> 
> Those all seem pretty valid arguments to me.
> 
> 

FWIW, if we take this approach, then either dropping the capability should turn PTI back on or we need to deal with the corner case of PTI off and capability not present.  The latter is a bit awkward but not necessarily a show stopper.  I think that all we need to do is to update the ptrace rules and maybe make PTI turn back on when we execve.  At least there's no need to muck around with LSM hooks.