[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <543116e1a8cf4b7a8b086c850374f99e@AcuMS.aculab.com>
Date: Mon, 12 Jun 2023 11:22:15 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Borislav Petkov' <bp@...en8.de>, Breno Leitao <leitao@...ian.org>
CC: "tglx@...utronix.de" <tglx@...utronix.de>,
"pawan.kumar.gupta@...ux.intel.com"
<pawan.kumar.gupta@...ux.intel.com>,
"paul@...l-moore.com" <paul@...l-moore.com>,
"leit@...a.com" <leit@...a.com>, "x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] cpu/bugs: Disable CPU mitigations at compilation time
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)
Powered by blists - more mailing lists