Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964837AbeAJHbe (ORCPT + 1 other); Wed, 10 Jan 2018 02:31:34 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:35239 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964783AbeAJHbc (ORCPT ); Wed, 10 Jan 2018 02:31:32 -0500 X-Google-Smtp-Source: ACJfBouwDlQfh88Le622pujVwXZ42gOqbVgpGo/8EefvZZX8lICZIBD9MbS8ZQTRIDUA9Dk6NSRiUA== Date: Wed, 10 Jan 2018 08:31:28 +0100 From: Ingo Molnar To: Borislav Petkov Cc: Willy Tarreau , Andy Lutomirski , LKML , X86 ML , Brian Gerst , Dave Hansen , 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 Message-ID: <20180110073128.sv3fcmfpai4ounvk@gmail.com> References: <20180109141713.ngqrf6weyiy2q3in@pd.tnic> <20180109143653.GA12976@1wt.eu> <20180109145157.5ltqbz4o5sqkcggb@pd.tnic> <20180109145422.GD12976@1wt.eu> <20180109212940.ffvqb6wmehmxre4i@pd.tnic> <20180109213227.GA13282@1wt.eu> <20180109214602.k7cuxwikg6xshztu@pd.tnic> <20180109220605.GE13282@1wt.eu> <20180109222036.6h7jjyaayusn4yb5@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180109222036.6h7jjyaayusn4yb5@pd.tnic> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: * Borislav Petkov wrote: > Oh, and you've built the kernel with the option to be able to disable > PTI so it's not like you haven't seen it already. In general in many corporate environments requiring kernel reboots or kernel rebuilds limits the real-world usability of any kernel feature we offer down to "non-existent". Saying "build your own kernel or reboot" is excluding a large subset of our real-world users. Build and boot options are fine for developers and testing. Otherwise _everything_ not readily accessible when your distro kernel has booted up is essentially behind a usability (and corporate policy) wall so steep that it's essentially non-existent to many users. So either we make this properly sysctl (and/or prctl) controllable, or just don't do it at all. Thanks, Ingo