Message ID | 20230203120615.1121272-1-leitao@debian.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp802599wrn; Fri, 3 Feb 2023 04:11:34 -0800 (PST) X-Google-Smtp-Source: AK7set/2ceBVDh9qC5FM2PaPbYb5I82GumHABhWHl4E52r0VHRO+EzQx7NRMEbV29bmxx2xGibx4 X-Received: by 2002:a17:906:3a91:b0:82d:e2a6:4b0d with SMTP id y17-20020a1709063a9100b0082de2a64b0dmr8957094ejd.18.1675426294550; Fri, 03 Feb 2023 04:11:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675426294; cv=none; d=google.com; s=arc-20160816; b=pYTc/lai2C05+oINXJGVJg6kQ3yCRmQ9HOzSsps0cYFwi3mJIsPrPJ2lx0fYrkGdFw YIztDKfN7e2LcdjnbJvbDoDGelacYip7bQNUvU0Emo2TU4G842zXGm3LFOmNpdAfxOGB +YF7fwEGOuUTEzmEIstHczx2TpgtvMmt2e5MYZpiC+nM46+RRboKQr0XxdMvrdJzmUig IWzSItMZmsFbwv/TpWuTDZf0as1EDMZMw8LfEKRh4IW6gA5R3AeaPpVeI5uajLQyIolJ fvkkx57DTwTEm+pgcqHQT2IiSwRjm0uTxHcB7JakaqXeekH3u3nZbcIa53x07vJ20xdf IkBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=OFRsk/X+fnAREo/+AWk3QTswlx80QT6mGneWCbGiQ+4=; b=quZPQ7bCtpKcnUW+szk5LGDUXLsQhUuyyZ6fhxl4nDa8ULAEpX7vlx5e0DnQOgjw7H h5PWNPwZaBEcxsbrmssP111kpEWR8rgqHVRxfb72+HspTERzZD5zEEmrFCuoN2lKga6B HcHDsO2LusBcexKfuOaLUi5Hn1B4EXCQVv78nRC9aKZHnmijcqd/xh8bkUHF5P5f66qm PF7XtB5BSi7OK3UsvEBJz+VmVIewN9WExCJQrWNI1hhMlyo9hwmeBlLGYQ4ZVEM0Ppdo Wj29x005crURkTw1rf5neOMOk58npS/MON3CRXvuXOZ+LLXXEaFT+7FAQMZ/P0lFwP86 aiCg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q6-20020a1709064cc600b007ae10525573si2643655ejt.671.2023.02.03.04.11.11; Fri, 03 Feb 2023 04:11:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232566AbjBCMHV (ORCPT <rfc822;il.mystafa@gmail.com> + 99 others); Fri, 3 Feb 2023 07:07:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232102AbjBCMHT (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 3 Feb 2023 07:07:19 -0500 Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 65DCB71658 for <linux-kernel@vger.kernel.org>; Fri, 3 Feb 2023 04:07:18 -0800 (PST) Received: by mail-ej1-f54.google.com with SMTP id lu11so14786554ejb.3 for <linux-kernel@vger.kernel.org>; Fri, 03 Feb 2023 04:07:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OFRsk/X+fnAREo/+AWk3QTswlx80QT6mGneWCbGiQ+4=; b=LGQjQdvPkVBdxtP8ZuCni04JjjQA6UFJyazwOrHg1ms+OVoLrnMTcAXngnFlA1U5Bv E+YXXbKAG4iXBEVyCpVDxWf1nf7Z1bBQvN2a/1PjPB4sJ2IH4hYKI4Q6Jco+FPzDW7iO jycmwR7jAUPMcDWNTuNAPfiWe4ETRQbqa5jcmPoHru0oJp0RtLRJLoCCwfOKgFiZIFm9 G/8YJRMAJWHqMn3/2NUOD/tyyJEM1IYJGb3Bb4ieb3USb2rEpYr5+ibEAhlhgBxCmCK6 uRKxQLkQGUOTpBepoSz5ecMfvJ4uT6+feY0lZHUTIL4RI9IoL6GT7GEKzOhmyr6k43Cj zqIw== X-Gm-Message-State: AO0yUKWFpMVjwjDIBrXYNODb/moQJsL4LOy4XFOmgxZDt0zNvOqFyWZk 2EtHYS3iRb3QdZCyMR5gDao= X-Received: by 2002:a17:906:281b:b0:86a:833d:e7d8 with SMTP id r27-20020a170906281b00b0086a833de7d8mr9128750ejc.17.1675426036948; Fri, 03 Feb 2023 04:07:16 -0800 (PST) Received: from localhost (fwdproxy-cln-012.fbsv.net. [2a03:2880:31ff:c::face:b00c]) by smtp.gmail.com with ESMTPSA id qp22-20020a170907207600b0087862f45a29sm1297001ejb.174.2023.02.03.04.07.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Feb 2023 04:07:16 -0800 (PST) From: Breno Leitao <leitao@debian.org> To: tglx@linutronix.de, bp@alien8.de, pawan.kumar.gupta@linux.intel.com, paul@paul-moore.com Cc: leit@meta.com, x86@kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] cpu/bugs: Disable CPU mitigations at compilation time Date: Fri, 3 Feb 2023 04:06:15 -0800 Message-Id: <20230203120615.1121272-1-leitao@debian.org> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756744183579872336?= X-GMAIL-MSGID: =?utf-8?q?1756811802100856715?= |
Series |
cpu/bugs: Disable CPU mitigations at compilation time
|
|
Commit Message
Breno Leitao
Feb. 3, 2023, 12:06 p.m. UTC
Right now it is not possible to disable CPU vulnerabilities mitigations
at build time. Mitigation needs to be disabled passing kernel
parameters, such as 'mitigations=off'.
Create a new config option (CONFIG_CPU_MITIGATIONS_DEFAULT_OFF) that
sets the global variable `cpu_mitigations` to OFF, instead of AUTO. This
allows the creation of kernel binaries that boots with the CPU
mitigations turned off by default, and does not require dealing kernel
parameters.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
kernel/cpu.c | 7 +++++--
security/Kconfig | 11 +++++++++++
2 files changed, 16 insertions(+), 2 deletions(-)
Comments
On Fri, Feb 03, 2023 at 04:06:15AM -0800, Breno Leitao wrote: > Right now it is not possible to disable CPU vulnerabilities mitigations > at build time. Mitigation needs to be disabled passing kernel > parameters, such as 'mitigations=off'. > > Create a new config option (CONFIG_CPU_MITIGATIONS_DEFAULT_OFF) that > sets the global variable `cpu_mitigations` to OFF, instead of AUTO. This > allows the creation of kernel binaries that boots with the CPU > mitigations turned off by default, and does not require dealing kernel > parameters. What's the real-life use case for this?
On Fri, Feb 03 2023 at 04:06, Breno Leitao wrote: > Right now it is not possible to disable CPU vulnerabilities mitigations > at build time. Mitigation needs to be disabled passing kernel > parameters, such as 'mitigations=off'. > > Create a new config option (CONFIG_CPU_MITIGATIONS_DEFAULT_OFF) that > sets the global variable `cpu_mitigations` to OFF, instead of AUTO. This > allows the creation of kernel binaries that boots with the CPU > mitigations turned off by default, and does not require dealing kernel > parameters. Why? What's the justification Just because we do not have not enough kernel config items yet, does not count. Thanks, tglx
From: Borislav Petkov > Sent: 09 June 2023 18:34 > > On Fri, Feb 03, 2023 at 04:06:15AM -0800, Breno Leitao wrote: > > Right now it is not possible to disable CPU vulnerabilities mitigations > > at build time. Mitigation needs to be disabled passing kernel > > parameters, such as 'mitigations=off'. > > > > Create a new config option (CONFIG_CPU_MITIGATIONS_DEFAULT_OFF) that > > sets the global variable `cpu_mitigations` to OFF, instead of AUTO. This > > allows the creation of kernel binaries that boots with the CPU > > mitigations turned off by default, and does not require dealing kernel > > parameters. > > What's the real-life use case for this? I can definitely justify compiling them all out. For instance embedded systems with limited userspace and (pretty much) everything running as root. Compiling them out gives better code than patching them out during boot. I've stopped updating an LTS kernel because I really don't want/need any of the mitigations - especially the ones associated with 'ret' instructions. They are far more pervasive than the ones for indirect jumps. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On Mon, Jun 12, 2023 at 11:22:15AM +0000, David Laight wrote: > I can definitely justify compiling them all out. > For instance embedded systems with limited userspace and > (pretty much) everything running as root. Nothing's stopping you from adding "mitigations=off" to your grub config.
From: Borislav Petkov > Sent: 12 June 2023 12:52 > > On Mon, Jun 12, 2023 at 11:22:15AM +0000, David Laight wrote: > > I can definitely justify compiling them all out. > > For instance embedded systems with limited userspace and > > (pretty much) everything running as root. > > Nothing's stopping you from adding "mitigations=off" to your grub > config. I do (and I compile without page table separation), but some of the run-time patched versions are not as 'good' as compiling the code out. It might just be some nops, but maybe it is worse. This can be particularly true for new mitigations. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On Sun, Jun 11, 2023 at 12:37:34AM +0200, Thomas Gleixner wrote: > On Fri, Feb 03 2023 at 04:06, Breno Leitao wrote: > > Right now it is not possible to disable CPU vulnerabilities mitigations > > at build time. Mitigation needs to be disabled passing kernel > > parameters, such as 'mitigations=off'. > > > > Create a new config option (CONFIG_CPU_MITIGATIONS_DEFAULT_OFF) that > > sets the global variable `cpu_mitigations` to OFF, instead of AUTO. This > > allows the creation of kernel binaries that boots with the CPU > > mitigations turned off by default, and does not require dealing kernel > > parameters. > > Why? What's the justification There are two major justification from my point of view: 1) We keep consistency with other CONFIG options. Linux already has a CONFIG option to enable/disable mitigations for speculations (CONFIG_SPECULATION_MITIGATIONS), so, this will be a similar one. 2) There are companies that have different kernel flavours (different CONFIG options basically), for different type of workloads, and a machine can change their kernel flavors a few times a day. I.e, for a specifically workload, boots in flavor X since it works the best. Mitigation enabled/disabled is key to some of these flavors. I would like to see a flavor as self-contained in a binary that I can mix and match. Right not they are not, since for some kernel flavours, you need to add kernel command lines (mitigations=off), which requires some hard logic, mainly when you are dealing with kexec and grub.
On Mon, Jun 12, 2023 at 12:16:19PM +0000, David Laight wrote: > I do (and I compile without page table separation), > but some of the run-time patched versions are not as 'good' > as compiling the code out. > It might just be some nops, but maybe it is worse. "might", schmight, ... other statements without proof... If you want me to take you seriously, explain in detail the problem. Otherwise, I can keep on ignoring you.
On Mon, Jun 12, 2023 at 05:54:56AM -0700, Breno Leitao wrote: > 1) We keep consistency with other CONFIG options. Linux already has a > CONFIG option to enable/disable mitigations for speculations > (CONFIG_SPECULATION_MITIGATIONS), so, this will be a similar one. So you can get what you want by disabling all those options there, right?
On Mon, Jun 12, 2023 at 03:32:30PM +0200, Borislav Petkov wrote: > On Mon, Jun 12, 2023 at 05:54:56AM -0700, Breno Leitao wrote: > > 1) We keep consistency with other CONFIG options. Linux already has a > > CONFIG option to enable/disable mitigations for speculations > > (CONFIG_SPECULATION_MITIGATIONS), so, this will be a similar one. > > So you can get what you want by disabling all those options there, > right? This patch proposes creating CONFIG_CPU_MITIGATIONS_DEFAULT_OFF that will turn all the mitigations off in a binary, which is the same as passing mitigations=off in the command line when the kernel boots. Setting CONFIG_SPECULATION_MITIGATIONS=n does *not* disable all the mitigations, as, there are some mitigations that are *not* disabled when you pass CONFIG_SPECULATION_MITIGATIONS=n. As an example (from my memory - need to double check in 6.4), MDS and TAA mitigations are not disabled when CONFIG_SPECULATION_MITIGATIONS=n. MDS and TAA mitigations are disabled when `mitigations=off` parameter is passed, tho.
On Mon, Jun 12, 2023 at 06:46:16AM -0700, Breno Leitao wrote: > MDS and TAA mitigations are disabled when `mitigations=off` parameter > is passed, tho. So add them to that menu.
On Mon, Jun 12, 2023 at 03:53:01PM +0200, Borislav Petkov wrote: > On Mon, Jun 12, 2023 at 06:46:16AM -0700, Breno Leitao wrote: > > MDS and TAA mitigations are disabled when `mitigations=off` parameter > > is passed, tho. > > So add them to that menu. Sorry, to waht menu specifically?
On Mon, Jun 12, 2023 at 07:16:18AM -0700, Breno Leitao wrote:
> Sorry, to waht menu specifically?
CONFIG_SPECULATION_MITIGATIONS
It even has the proper text in there, warning people.
menuconfig SPECULATION_MITIGATIONS
bool "Mitigations for speculative execution vulnerabilities"
default y
help
Say Y here to enable options which enable mitigations for
speculative execution hardware vulnerabilities.
If you say N, all mitigations will be disabled. You really
should know what you are doing to say so.
On Mon, Jun 12, 2023 at 06:08:07PM +0200, Borislav Petkov wrote: > On Mon, Jun 12, 2023 at 07:16:18AM -0700, Breno Leitao wrote: > > Sorry, to waht menu specifically? > > CONFIG_SPECULATION_MITIGATIONS > > It even has the proper text in there, warning people. > > menuconfig SPECULATION_MITIGATIONS > bool "Mitigations for speculative execution vulnerabilities" > default y > help > Say Y here to enable options which enable mitigations for > speculative execution hardware vulnerabilities. I am not sure if these bugs (MDS, TAA) are speculations related. Pawan could help us here.
On Mon, Jun 12, 2023 at 09:37:07AM -0700, Breno Leitao wrote: > I am not sure if these bugs (MDS, TAA) are speculations related. Pawan > could help us here. "Microarchitectural Data Sampling is a hardware vulnerability which allows unprivileged speculative access..." "TAA is a hardware vulnerability that allows unprivileged speculative access to data which is available in various CPU..." That's all in the tree. Your grep no workie?
On Mon, Jun 12 2023 at 09:37, Breno Leitao wrote: > On Mon, Jun 12, 2023 at 06:08:07PM +0200, Borislav Petkov wrote: >> On Mon, Jun 12, 2023 at 07:16:18AM -0700, Breno Leitao wrote: >> > Sorry, to waht menu specifically? >> >> CONFIG_SPECULATION_MITIGATIONS >> >> It even has the proper text in there, warning people. >> >> menuconfig SPECULATION_MITIGATIONS >> bool "Mitigations for speculative execution vulnerabilities" >> default y >> help >> Say Y here to enable options which enable mitigations for >> speculative execution hardware vulnerabilities. > > I am not sure if these bugs (MDS, TAA) are speculations related. Pawan > could help us here. https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/index.html might answer your question.
On 6/12/23 09:08, Borislav Petkov wrote: > On Mon, Jun 12, 2023 at 07:16:18AM -0700, Breno Leitao wrote: >> Sorry, to waht menu specifically? > > CONFIG_SPECULATION_MITIGATIONS > > It even has the proper text in there, warning people. > > menuconfig SPECULATION_MITIGATIONS > bool "Mitigations for speculative execution vulnerabilities" > default y > help > Say Y here to enable options which enable mitigations for > speculative execution hardware vulnerabilities. > > If you say N, all mitigations will be disabled. You really > should know what you are doing to say so. I would say: doing to say No. Was there a typo there? thanks.
On Mon, Jun 12, 2023 at 11:06:35AM -0700, Randy Dunlap wrote: > > If you say N, all mitigations will be disabled. You really > > should know what you are doing to say so. > > I would say: doing to say No. > > Was there a typo there? I don't think so - it reads right to me this way too. Yours would simply make it more explicit but the "so" is the "N" at the beginning of the sentence: "You really should know what you're doing to say so, i.e., the N".
On Mon, Jun 12, 2023 at 07:05:32PM +0200, Borislav Petkov wrote: > On Mon, Jun 12, 2023 at 09:37:07AM -0700, Breno Leitao wrote: > > I am not sure if these bugs (MDS, TAA) are speculations related. Pawan > > could help us here. > > "Microarchitectural Data Sampling is a hardware vulnerability which allows > unprivileged speculative access..." > > "TAA is a hardware vulnerability that allows unprivileged speculative > access to data which is available in various CPU..." Is it OK if I send a patch that would disable these mitigations if CONFIG_SPECULATION_MITIGATIONS is set to "no"? Thank you!
On Tue, Jun 13, 2023 at 09:02:50AM -0700, Breno Leitao wrote: > Is it OK if I send a patch that would disable these mitigations if > CONFIG_SPECULATION_MITIGATIONS is set to "no"? Isn't this the direction we're going to? So yes, I was suggesting exactly that - add those mitigations to that submenu so that they can be controlled with config options too, like the others.
diff --git a/kernel/cpu.c b/kernel/cpu.c index 6c0a92ca6bb5..90afb29eb62f 100644 --- a/kernel/cpu.c +++ b/kernel/cpu.c @@ -2727,8 +2727,11 @@ enum cpu_mitigations { CPU_MITIGATIONS_AUTO_NOSMT, }; -static enum cpu_mitigations cpu_mitigations __ro_after_init = - CPU_MITIGATIONS_AUTO; +#ifdef CONFIG_CPU_MITIGATIONS_DEFAULT_OFF +static enum cpu_mitigations cpu_mitigations __ro_after_init = CPU_MITIGATIONS_OFF; +#else +static enum cpu_mitigations cpu_mitigations __ro_after_init = CPU_MITIGATIONS_AUTO; +#endif static int __init mitigations_parse_cmdline(char *arg) { diff --git a/security/Kconfig b/security/Kconfig index e6db09a779b7..644f91b6c26a 100644 --- a/security/Kconfig +++ b/security/Kconfig @@ -258,6 +258,17 @@ config LSM If unsure, leave this as the default. +config CPU_MITIGATIONS_DEFAULT_OFF + bool "Disable mitigations for CPU vulnerabilities by default" + default n + help + This option disables mitigations for CPU vulnerabilities by default. + Disabling CPU mitigations improves system performance, + but it may also expose users to several CPU vulnerabilities. + This option has the same effect of passing `mitigations=off` kernel + parameter. The CPU mitigations could be enabled back using the + 'mitigations' parameter. + source "security/Kconfig.hardening" endmenu