Linux kernel documentation tree maintained by Jonathan Corbet http://mirrors.hust.edu.cn/git/lwn.git/atom?h=master 2026-03-05T20:25:45+00:00 2026-03-05T20:25:45+00:00 Dave Hansen dave.hansen@linux.intel.com 2026-03-04T18:10:24+00:00 urn:sha1:7989c39341348e3507282d88a564cb20d83a0829 Intel sometimes has CPUs with identical family/model/stepping but which need different microcode. These CPUs are differentiated with the platform ID. The Intel "microcode-20250512" release was used to generate the existing contents of intel-ucode-defs.h. Use that same release and add the platform mask to the definitions. This makes the list a few entries longer because some CPUs previously that shared a definition now need two or more. for example for the ancient Pentium III there are two CPUs that differ only in their platform and have two different microcode versions (note: .driver_data is the microcode version): { ..., .model = 0x05, .steppings = 0x0001, .platform_mask = 0x01, .driver_data = 0x40 }, { ..., .model = 0x05, .steppings = 0x0001, .platform_mask = 0x08, .driver_data = 0x45 }, Another example is the state-of-the-art Granite Rapids: { ..., .model = 0xad, .steppings = 0x0002, .platform_mask = 0x20, .driver_data = 0xa0000d1 }, { ..., .model = 0xad, .steppings = 0x0002, .platform_mask = 0x95, .driver_data = 0x10003a2 }, As you can see, this differentiation with platform ID has been necessary for a long time and is still relevant today. Without the platform matching, the old microcode table is incomplete. For instance, it might lead someone with a Pentium III, platform 0x0, and microcode 0x40 to think that they should have microcode 0x45, which is really only for platform 0x4 (.platform_mask==0x08). In practice, this meant that folks with fully updated microcode were seeing "Vulnerable" in the "old_microcode" file. 1. https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files Closes: https://lore.kernel.org/all/38660F8F-499E-48CD-B58B-4822228A5941@nutanix.com/ Fixes: 4e2c719782a8 ("x86/cpu: Help users notice when running old Intel microcode") Reported-by: Jon Kohler <jon@nutanix.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Sohil Mehta <sohil.mehta@intel.com> Tested-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/all/3ECBB974-C6F0-47A7-94B6-3646347F1CC2@nutanix.com/ Link: https://patch.msgid.link/20260304181024.76E3F038@davehans-spike.ostc.intel.com 2026-03-05T20:25:32+00:00 Dave Hansen dave.hansen@linux.intel.com 2026-03-04T18:10:20+00:00 urn:sha1:d8630b67ca1edeea728dbb309b09d239e9db6bdf The end goal here is to be able to do x86_match_cpu() and match on a specific platform ID. While it would be possible to stash this ID off somewhere or read it dynamically, that approaches would not be consistent with the other fields which can be matched. Read the platform ID and store it in cpuinfo_x86. There are lots of sites to set this new field. Place it near the place c->microcode is established since the platform ID is so closely intertwined with microcode updates. Note: This should not grow the size of 'struct cpuinfo_x86' in practice since the u8 fits next to another u8 in the structure. Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Sohil Mehta <sohil.mehta@intel.com> Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Link: https://patch.msgid.link/20260304181020.8D518228@davehans-spike.ostc.intel.com 2026-03-05T20:25:18+00:00 Dave Hansen dave.hansen@linux.intel.com 2026-03-04T18:10:18+00:00 urn:sha1:238be4ba87605da69de2131e8736be7a0d299e00 Today, the only code that cares about the platform ID is the microcode update code itself. To facilitate storing the platform ID in a more generic place and using it outside of the microcode update itself, put the enumeration into a helper function. Mirror intel_get_microcode_revision()'s naming and location. But, moving away from intel_collect_cpu_info() means that the model and family information in CPUID is not readily available. Just call CPUID again. Note that the microcode header is a mask of supported platform IDs. Only stick the ID part in the helper. Leave the 1<<id part in the microcode handling. Also note that the PII is weird. It does not really have a platform ID because it doesn't even have the MSR. Just consider it to be platform ID 0. Instead of saying >=PII, say <=PII. The PII is the real oddball here being the only CPU with Linux microcode updates but no platform ID. It's worth calling it out by name. This does subtly change the sig->pf for the PII though from 0x0 to 0x1. Make up for that by ignoring sig->pf when the microcode update platform mask is 0x0. [ dhansen: reflow comment for bpetkov ] Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Sohil Mehta <sohil.mehta@intel.com> Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Link: https://patch.msgid.link/20260304181018.EB6404F8@davehans-spike.ostc.intel.com 2026-02-22T01:09:51+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-02-22T00:37:42+00:00 urn:sha1:bf4afc53b77aeaa48b5409da5c8da6bb4eff7f43 This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 2026-02-21T09:02:28+00:00 Kees Cook kees@kernel.org 2026-02-21T07:49:23+00:00 urn:sha1:69050f8d6d075dc01af7a5f2f550a8067510366f This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook <kees@kernel.org> 2026-01-14T13:46:44+00:00 Borislav Petkov (AMD) bp@alien8.de 2025-10-06T15:50:10+00:00 urn:sha1:ac44a110c18ad7bd9de0b809e861479ba97157d2 Debugging the loader on baremetal does make sense, so enable it there too. Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260108165028.27417-1-bp@kernel.org 2025-12-29T19:08:02+00:00 Rong Zhang i@rong.moe 2025-12-29T18:22:21+00:00 urn:sha1:150b1b97e27513535dcd3795d5ecd28e61b6cb8c Zen5 also contains family 1Ah, models 70h-7Fh, which are mistakenly missing from cpu_has_entrysign(). Add the missing range. Fixes: 8a9fb5129e8e ("x86/microcode/AMD: Limit Entrysign signature checking to known generations") Signed-off-by: Rong Zhang <i@rong.moe> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: stable@kernel.org Link: https://patch.msgid.link/20251229182245.152747-1-i@rong.moe 2025-12-06T01:29:04+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-12-06T01:29:04+00:00 urn:sha1:208eed95fc710827b100266c9450ae84d46727bd Pull SoC driver updates from Arnd Bergmann: "This is the first half of the driver changes: - A treewide interface change to the "syscore" operations for power management, as a preparation for future Tegra specific changes - Reset controller updates with added drivers for LAN969x, eic770 and RZ/G3S SoCs - Protection of system controller registers on Renesas and Google SoCs, to prevent trivially triggering a system crash from e.g. debugfs access - soc_device identification updates on Nvidia, Exynos and Mediatek - debugfs support in the ST STM32 firewall driver - Minor updates for SoC drivers on AMD/Xilinx, Renesas, Allwinner, TI - Cleanups for memory controller support on Nvidia and Renesas" * tag 'soc-drivers-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (114 commits) memory: tegra186-emc: Fix missing put_bpmp Documentation: reset: Remove reset_controller_add_lookup() reset: fix BIT macro reference reset: rzg2l-usbphy-ctrl: Fix a NULL vs IS_ERR() bug in probe reset: th1520: Support reset controllers in more subsystems reset: th1520: Prepare for supporting multiple controllers dt-bindings: reset: thead,th1520-reset: Add controllers for more subsys dt-bindings: reset: thead,th1520-reset: Remove non-VO-subsystem resets reset: remove legacy reset lookup code clk: davinci: psc: drop unused reset lookup reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S SoC reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3S support reset: eswin: Add eic7700 reset driver dt-bindings: reset: eswin: Documentation for eic7700 SoC reset: sparx5: add LAN969x support dt-bindings: reset: microchip: Add LAN969x support soc: rockchip: grf: Add select correct PWM implementation on RK3368 soc/tegra: pmc: Add USB wake events for Tegra234 amba: tegra-ahb: Fix device leak on SMMU enable ... 2025-12-02T19:35:49+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-12-02T19:35:49+00:00 urn:sha1:2a47c26e55a2bc085a2349ed1d4e065ee298155f Pull x86 microcode loading updates from Borislav Petkov: - Add microcode staging support on Intel: it moves the sole microcode blobs loading to a non-critical path so that microcode loading latencies are kept at minimum. The actual "directing" the hardware to load microcode is the only step which is done on the critical path. This scheme is also opportunistic as in: on a failure, the machinery falls back to normal loading - Add the capability to the AMD side of the loader to select one of two per-family/model/stepping patches: one is pre-Entrysign and the other is post-Entrysign; with the goal to take care of machines which haven't updated their BIOS yet - something they should absolutely do as this is the only proper Entrysign fix - Other small cleanups and fixlets * tag 'x86_microcode_for_v6.19_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/microcode: Mark early_parse_cmdline() as __init x86/microcode/AMD: Select which microcode patch to load x86/microcode/intel: Enable staging when available x86/microcode/intel: Support mailbox transfer x86/microcode/intel: Implement staging handler x86/microcode/intel: Define staging state struct x86/microcode/intel: Establish staging control logic x86/microcode: Introduce staging step to reduce late-loading time x86/cpu/topology: Make primary thread mask available with SMP=n 2025-11-14T13:04:49+00:00 Borislav Petkov (AMD) bp@alien8.de 2025-11-14T13:01:14+00:00 urn:sha1:dd14022a7ce96963aa923e35cf4bcc8c32f95840 Add the minimum Entrysign revision for that model+stepping to the list of minimum revisions. Fixes: 50cef76d5cb0 ("x86/microcode/AMD: Load only SHA256-checksummed patches") Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: <stable@kernel.org> Link: https://lore.kernel.org/r/e94dd76b-4911-482f-8500-5c848a3df026@citrix.com