From: "Linux regression tracking (Thorsten Leemhuis)" <regressions@leemhuis.info>
To: Borislav Petkov <bp@alien8.de>,
Linux regressions mailing list <regressions@lists.linux.dev>
Cc: lukas.bulwahn@gmail.com, dave.hansen@linux.intel.com,
hpa@zytor.com, kernel-janitors@vger.kernel.org,
linux-kernel@vger.kernel.org, mingo@redhat.com,
tglx@linutronix.de, x86@kernel.org
Subject: Re: [regression] microcode files missing in initramfs imgages from dracut (was Re: [PATCH] x86: Clean up remaining references to CONFIG_MICROCODE_AMD)
Date: Wed, 22 Nov 2023 10:15:42 +0100 [thread overview]
Message-ID: <0e9cbe6f-ac6c-47f2-b663-a22568799eca@leemhuis.info> (raw)
In-Reply-To: <20231112181036.GBZVEVHIIj/Oos1cx4@fat_crate.local>
On 12.11.23 19:10, Borislav Petkov wrote:
> On Sun, Nov 12, 2023 at 04:03:32PM +0100, Linux regression tracking (Thorsten Leemhuis) wrote:
>> That's because dracut until the recent commit
>> https://github.com/dracutdevs/dracut/commit/6c80408c8644a0add1907b0593eb83f90d6247b1
>> looked for CONFIG_MICROCODE_AMD and CONFIG_MICROCODE_INTEL in the config
>> file to decide what to include or not.
>
> They've been told a bunch of times already that grepping .config for
> specific symbols is not how one should check whether one should add
> microcode blobs to the initrd or not because Kconfig symbols are not an
> ABI.
Maybe, but you know how Linus sees things like this: what's considered
an ABI/API or not is nearly[1] irrelevant - if a change breaks something
that used to work then it needs to be fixed.
[1] unless you fiddle with things obviously internal; not sure if this
case would qualify for him, but somehow I doubt it -- but I might be
wrong there.
> And looking at that commit, now they're grepping for CONFIG_MICROCODE.
> And that'll break again if one day we decide to make the microcode
> loader built in unconditionally.
>
> How to fix this reliably and properly?
>
> Honestly, I don't have a good idea. If we do something like this:
> grep microcode_init System.map
>
> then that makes "microode_init" ABI and we won't be able to change it
> eva. I'd need to do some digging here...
Any progress on this?
BTW: I see that this could help preventing problems like the current one
to happen in the far future. But how would that help the current
situation (e.g. users that have an old dracut and updated the kernel
without updating dracut)?
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
#regzbot poke
next prev parent reply other threads:[~2023-11-22 9:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-25 14:12 [PATCH] x86: Clean up remaining references to CONFIG_MICROCODE_AMD Lukas Bulwahn
2023-08-26 12:10 ` [tip: x86/microcode] x86/microcode: Remove " tip-bot2 for Lukas Bulwahn
2023-11-12 15:03 ` [regression] microcode files missing in initramfs imgages from dracut (was Re: [PATCH] x86: Clean up remaining references to CONFIG_MICROCODE_AMD) Linux regression tracking (Thorsten Leemhuis)
2023-11-12 18:10 ` Borislav Petkov
2023-11-22 9:15 ` Linux regression tracking (Thorsten Leemhuis) [this message]
2023-11-22 11:58 ` Borislav Petkov
2023-11-22 13:24 ` [PATCH] x86: Add a "x86" ELF note namespace Borislav Petkov
2023-11-22 14:07 ` Borislav Petkov
2023-11-22 15:34 ` [regression] microcode files missing in initramfs imgages from dracut (was Re: [PATCH] x86: Clean up remaining references to CONFIG_MICROCODE_AMD) Linux regression tracking (Thorsten Leemhuis)
2023-11-22 15:57 ` Borislav Petkov
2023-11-22 20:35 ` Linus Torvalds
2023-11-22 20:51 ` Borislav Petkov
2023-11-22 21:08 ` Linus Torvalds
2023-11-22 21:35 ` Borislav Petkov
2023-11-23 11:20 ` Borislav Petkov
2023-11-24 8:49 ` Antonio Feijoo
2023-11-24 12:15 ` Borislav Petkov
2023-11-24 13:15 ` Antonio Feijoo
2023-11-24 13:33 ` Borislav Petkov
2023-11-28 13:17 ` Borislav Petkov
2023-11-22 13:45 ` Lukas Bulwahn
2023-11-23 4:07 ` Linux regression tracking #update (Thorsten Leemhuis)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0e9cbe6f-ac6c-47f2-b663-a22568799eca@leemhuis.info \
--to=regressions@leemhuis.info \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas.bulwahn@gmail.com \
--cc=mingo@redhat.com \
--cc=regressions@lists.linux.dev \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).