Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934088AbeALPCq convert rfc822-to-8bit (ORCPT + 1 other); Fri, 12 Jan 2018 10:02:46 -0500 Received: from smtp-out6.electric.net ([192.162.217.188]:59974 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933860AbeALPCp (ORCPT ); Fri, 12 Jan 2018 10:02:45 -0500 From: David Laight To: 'Willy Tarreau' , "linux-kernel@vger.kernel.org" , "x86@kernel.org" CC: Andy Lutomirski , Borislav Petkov , "Brian Gerst" , Dave Hansen , "Ingo Molnar" , Linus Torvalds , Peter Zijlstra , Thomas Gleixner , Josh Poimboeuf , "H. Peter Anvin" , "Kees Cook" Subject: RE: [RFC PATCH v2 2/6] x86/arch_prctl: add ARCH_GET_NOPTI and ARCH_SET_NOPTI to enable/disable PTI Thread-Topic: [RFC PATCH v2 2/6] x86/arch_prctl: add ARCH_GET_NOPTI and ARCH_SET_NOPTI to enable/disable PTI Thread-Index: AQHTiUmieDiug3i8kkeCx7O9Wcf1K6NwWBlA Date: Fri, 12 Jan 2018 15:03:23 +0000 Message-ID: <192215ffd63049b8b6e7f982675ddb4d@AcuMS.aculab.com> References: <1515502580-12261-1-git-send-email-w@1wt.eu> <1515502580-12261-3-git-send-email-w@1wt.eu> In-Reply-To: <1515502580-12261-3-git-send-email-w@1wt.eu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 156.67.243.126 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuMS.aculab.com X-TLS: TLSv1.2:ECDHE-RSA-AES256-SHA384:256 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: 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. If you are trying to find the size of the performance hit you also need to be able to disable (and re-enable) PTI for all the current and future threads of a given process. David