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
