Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S934034AbeALPHO (ORCPT <rfc822;ralf@linux-mips.org> + 1 other);
        Fri, 12 Jan 2018 10:07:14 -0500
Received: from wtarreau.pck.nerim.net ([62.212.114.60]:39760 "EHLO 1wt.eu"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S933917AbeALPHO (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 12 Jan 2018 10:07:14 -0500
Date: Fri, 12 Jan 2018 16:06:08 +0100
From: Willy Tarreau <w@1wt.eu>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "x86@kernel.org" <x86@kernel.org>,
        Andy Lutomirski <luto@kernel.org>,
        Borislav Petkov <bp@alien8.de>,
        Brian Gerst <brgerst@gmail.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Ingo Molnar <mingo@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Kees Cook <keescook@chromium.org>
Subject: Re: [RFC PATCH v2 2/6] x86/arch_prctl: add ARCH_GET_NOPTI and
 ARCH_SET_NOPTI to enable/disable PTI
Message-ID: <20180112150608.GA16210@1wt.eu>
References: <1515502580-12261-1-git-send-email-w@1wt.eu>
 <1515502580-12261-3-git-send-email-w@1wt.eu>
 <192215ffd63049b8b6e7f982675ddb4d@AcuMS.aculab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <192215ffd63049b8b6e7f982675ddb4d@AcuMS.aculab.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Return-Path: <linux-kernel-owner@vger.kernel.org>

On Fri, Jan 12, 2018 at 03:03:23PM +0000, David Laight wrote:
> From: Willy Tarreau
> > Sent: 09 January 2018 12:56
> > 
> > This allows to report the current state of the PTI protection and to
> > enable or disable it for the current process. The state change is only
> > allowed if the mm is not shared (no threads have been created yet).
> > 
> > Setting the flag to disable the protection is subject to CAP_SYS_RAWIO.
> > However it is possible to re-enable the protection without this privilege.
> 
> While a process with CAP_SYS_RAWIO can easily access kernel memory so
> get little extra protection from PTI, you probably want to be able
> to disable PTI without giving a process CAP_SYS_RAWIO.
> No point leaving the door wide open.

Sure but if it's only a wrapper you don't mind. Start with the capability,
disable PTI, drop the capability and that's done.

Willy