Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965696AbeAKTdO (ORCPT + 1 other); Thu, 11 Jan 2018 14:33:14 -0500 Received: from mail-pf0-f194.google.com ([209.85.192.194]:37248 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753763AbeAKTdN (ORCPT ); Thu, 11 Jan 2018 14:33:13 -0500 X-Google-Smtp-Source: ACJfBov7dGpyfScj/EAL+UTbwGZt2SWd6sWerFY6aTiO6dEyQ3Xv75sZBJnJ32dPZqV2qfi3UXhTeQ== 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 X-Mailer: iPhone Mail (15C202) In-Reply-To: Date: Thu, 11 Jan 2018 11:33:09 -0800 Cc: Willy Tarreau , Andy Lutomirski , Dave Hansen , Peter Zijlstra , LKML , X86 ML , Borislav Petkov , Brian Gerst , Ingo Molnar , Thomas Gleixner , Josh Poimboeuf , "H. Peter Anvin" , Greg Kroah-Hartman , Kees Cook Content-Transfer-Encoding: 8BIT Message-Id: <50EB5B67-E441-43A6-8DD7-650A75B6ABE7@amacapital.net> References: <1515502580-12261-1-git-send-email-w@1wt.eu> <1515502580-12261-7-git-send-email-w@1wt.eu> <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> <20180111174025.GB15344@1wt.eu> To: Linus Torvalds Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: > On Jan 11, 2018, at 10:26 AM, Linus Torvalds wrote: > > On Thu, Jan 11, 2018 at 10:25 AM, Linus Torvalds > wrote: >> >> The other case may be the CLONE_NEW* operations. I *think* they are >> noops as far as PTI settings would be, but I think people should think >> about them. > > 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.