lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZNqWD2CKFfa0nSqS@localhost>
Date:   Mon, 14 Aug 2023 14:01:03 -0700
From:   Josh Triplett <josh@...htriplett.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Borislav Petkov <bp@...en8.de>,
        Ashok Raj <ashok.raj@...el.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Nikolay Borisov <nik.borisov@...e.com>
Subject: Re: [patch V2 02/37] x86/microcode: Hide the config knob

On Sat, Aug 12, 2023 at 09:58:39PM +0200, Thomas Gleixner wrote:
> In reality CONFIG_MICROCODE is enabled in any reasonable configuration when
> Intel or AMD support is enabled. Accomodate to reality.

> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1308,44 +1308,8 @@ config X86_REBOOTFIXUPS
>  	  Say N otherwise.
>  
>  config MICROCODE
> -	bool "CPU microcode loading support"
> -	default y
> +	def_bool y

There is one completely reasonable configuration that does not need or
want CONFIG_MICROCODE: a kernel configured to run *exclusively* in a
virtual machine, with no support for booting on physical hardware.

Would it retain an excessive amount of complexity to support omitting
this code in that use case? (Doesn't have to eliminate *every last bit*
of support code; just hoping to eliminate as much as easily possible
without adding non-trivial complexity.)

I'd be happy to help keep this case building. Would you consider
accepting a patch atop this series re-introducing minimal support for
disabling this?

(I am all for eliminating the added complexity of the separately
configurable knobs for CONFIG_MICROCODE_INTEL and CONFIG_MICROCODE_AMD,
and just having those be unconditionally enabled if CONFIG_MICROCODE
is.)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ