linux-kernel - Re: [PATCH -v1 2/2] x86/microcode: Add microcode loader debugging functionality

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: <f0565436-fef6-4999-b878-f4d2d52c22f2@intel.com>
Date: Fri, 29 Aug 2025 16:25:13 -0700
From: Sohil Mehta <sohil.mehta@...el.com>
To: Borislav Petkov <bp@...en8.de>
CC: Borislav Petkov <bp@...nel.org>, X86 ML <x86@...nel.org>, "Chang S. Bae"
	<chang.seok.bae@...el.com>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -v1 2/2] x86/microcode: Add microcode loader debugging
 functionality

On 8/29/2025 2:45 AM, Borislav Petkov wrote:
> On Wed, Aug 20, 2025 at 10:19:11PM -0700, Sohil Mehta wrote:
>> Does this need to be (IS_ENABLED(CONFIG_MICROCODE_DBG) && dbg)?
> 
> Both you and Nikolay have a point - we don't need both. So actually, dbg can
> go and can be added when really needed.
> 

My only concern is someone could easily enable it by mistake. It might
lead to unnecessary reports and debug. Maybe we print a scary dmesg log
whenever CONFIG_MICROCODE_DBG is enabled? That would be easy to spot in
reports, and hopefully it would deter folks from enabling it unnecessarily.

No strong preference.

> Right now, the debugging stuff is for in a guest only and will be build-time
> enabled.
> 
> If we decide we want to have runtime controllable and *baremetal* debugging,
> then we can extend that and add the cmdline switch.
>