Date: Fri, 12 Jan 2018 21:22:38 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Andy Lutomirski <luto@amacapital.net>
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>
Subject: Re: [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when
 pti_disable is set
Message-ID: <20180112202238.hc2dkjvmu7wlz7xw@gmail.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <50EB5B67-E441-43A6-8DD7-650A75B6ABE7@amacapital.net>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org


* 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.

Thanks,

	Ingo