Cathy, On Fri, May 20 2022 at 18:38, Cathy Zhang wrote: > First, the cadence of microcode updates has increased to deliver > security mitigations. Second, the value of those updates has increased, > meaning that any delay in applying them is unacceptable. Third, users > have become accustomed to approaches like hot patching their kernels > and have a growing aversion to reboots in general. > > Users want microcode updates to behave more like a hot patching a > kernel and less like a BIOS update. please don't take this personaly. What users want and what's technically correct are two different things. Fact is that late microcode updates especially those which change features, add/remove functionality are simply broken. This has been discussed to death already and I'm not going to find all the various threads which provided that information. lore.kernel.org has excellent search capabilities. As a summary, there is a long standing request that for late loading microcode needs to come with machine readable information about the nature of the update which tells the kernel whether there are changes which cannot be applied post boot. This was agreed on by Intel folks and until this materializes any attempt to load microcode late has to be considered as unsupported. This is going on for years now and has been ignored. As a consequence we are not adding a special SGX workaround for something which is known to be broken. What we are going to do and I'm fasttracking this is: https://lore.kernel.org/all/20220524185324.28395-1-bp@xxxxxxxxx which make the SGX workaround moot. Thanks tglx
