# Processor Vulnerability Mitigations with old Hardware **URL:** \ **Category:** Hardware\ **Created:** [29 June 2024 18:28 UTC](https://community.ipfire.org/t/processor-vulnerability-mitigations-with-old-hardware/11804 "2024-06-29T18:28:18Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![bmmbmm01](https://community.ipfire.org/user_avatar/community.ipfire.org/bmmbmm01/32/10535_2.png) [@bmmbmm01](https://community.ipfire.org/u/bmmbmm01)\ **Post date:** [29 June 2024 18:28 UTC](https://community.ipfire.org/t/processor-vulnerability-mitigations-with-old-hardware/11804/1 "2024-06-29T18:28:19Z")
Not sure if there has been a update in 3 years from this: **MMIO Stale Data** regarding Hardware Vulnerability Mitigations. Not sure if this should be asked in security or hardware. More curiosity then anything. I was having networking inconsistencies with a Firewalla Gold running on ubuntu 22. So I decided to use IPfire as I have been a fan and used it in the past to quick box for hardware. The PC Manual can be found here: > Now to the question: I’m running a Intel Celeron N3160 I’m getting: **Unknown: No mitigations** even with the check tool. However, the intel 2018 MCU has a microcode patch for this: > **[CVE-2018-3640: Intel(R) Celeron(R) CPU N3160 vulnerable?](https://community.intel.com/t5/Processors/CVE-2018-3640-Intel-R-Celeron-R-CPU-N3160-vulnerable/td-p/1318818)** > > I am attempting to improve the security posture of a specialty computer system. According to the Linux tools, the processor in my system is Intel(R) Celeron(R) CPU N3160 @ 1.60GHz which is reported as cpu family : 6 > model : 76... Just trying to get confirmation, as it should not be affected if running the 2018 microcode. Board : Firewalla FirewallaGold HW Version : 1.2 Serial : BSN123456789123##### BIOS Version: FWGOLDA03 (01/15/2020) ---
**Author:** ![bmmbmm01](https://community.ipfire.org/user_avatar/community.ipfire.org/bmmbmm01/32/10535_2.png) [@bmmbmm01](https://community.ipfire.org/u/bmmbmm01)\ **Post date:** [29 June 2024 18:38 UTC](https://community.ipfire.org/t/processor-vulnerability-mitigations-with-old-hardware/11804/2 "2024-06-29T18:38:57Z")
Spectre and Meltdown mitigation detection tool v0.46 Checking for vulnerabilities on current system Kernel is Linux 6.6.32-ipfire #1 SMP PREEMPT\_DYNAMIC Mon Jun 10 19:01:56 GMT 2024 x86\_64 CPU is Intel(R) Celeron(R) CPU N3160 @ 1.60GHz Hardware check - Hardware support (CPU microcode) for mitigation techniques - Indirect Branch Restricted Speculation (IBRS) - SPEC\_CTRL MSR is available: YES - CPU indicates IBRS capability: YES (SPEC\_CTRL feature bit) - Indirect Branch Prediction Barrier (IBPB) - CPU indicates IBPB capability: YES (SPEC\_CTRL feature bit) - Single Thread Indirect Branch Predictors (STIBP) - SPEC\_CTRL MSR is available: YES - CPU indicates STIBP capability: YES (Intel STIBP feature bit) - Speculative Store Bypass Disable (SSBD) - CPU indicates SSBD capability: NO - L1 data cache invalidation - CPU indicates L1D flush capability: NO - Microarchitectural Data Sampling - VERW instruction is available: YES (MD\_CLEAR feature bit) - Indirect Branch Predictor Controls - Indirect Predictor Disable feature is available: NO - Bottomless RSB Disable feature is available: NO - BHB-Focused Indirect Predictor Disable feature is available: NO - Enhanced IBRS (IBRS\_ALL) - CPU indicates ARCH\_CAPABILITIES MSR availability: NO - ARCH\_CAPABILITIES MSR advertises IBRS\_ALL capability: NO - CPU explicitly indicates not being affected by Meltdown/L1TF (RDCL\_NO): NO - CPU explicitly indicates not being affected by Variant 4 (SSB\_NO): NO - CPU/Hypervisor indicates L1D flushing is not necessary on this system: NO - Hypervisor indicates host CPU might be affected by RSB underflow (RSBA): NO - CPU explicitly indicates not being affected by Microarchitectural Data Sampling (MDS\_NO): NO - CPU explicitly indicates not being affected by TSX Asynchronous Abort (TAA\_NO): NO - CPU explicitly indicates not being affected by iTLB Multihit (PSCHANGE\_MSC\_NO): NO - CPU explicitly indicates having MSR for TSX control (TSX\_CTRL\_MSR): NO - CPU supports Transactional Synchronization Extensions (TSX): NO - CPU supports Software Guard Extensions (SGX): NO - CPU supports Special Register Buffer Data Sampling (SRBDS): NO - CPU microcode is known to cause stability problems: NO (family 0x6 model 0x4c stepping 0x4 ucode 0x411 cpuid 0x406c4) - CPU microcode is the latest known available version: YES (latest version is 0x411 dated 2019/04/23 according to builtin firmwares DB v271+i20230614) - CPU vulnerability to the speculative execution attack variants - Affected by CVE-2017-5753 (Spectre Variant 1, bounds check bypass): YES - Affected by CVE-2017-5715 (Spectre Variant 2, branch target injection): YES - Affected by CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load): YES - Affected by CVE-2018-3640 (Variant 3a, rogue system register read): YES - Affected by CVE-2018-3639 (Variant 4, speculative store bypass): NO - Affected by CVE-2018-3615 (Foreshadow (SGX), L1 terminal fault): NO - Affected by CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault): NO - Affected by CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault): NO - Affected by CVE-2018-12126 (Fallout, microarchitectural store buffer data sampling (MSBDS)): YES - Affected by CVE-2018-12130 (ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)): YES - Affected by CVE-2018-12127 (RIDL, microarchitectural load port data sampling (MLPDS)): YES - Affected by CVE-2019-11091 (RIDL, microarchitectural data sampling uncacheable memory (MDSUM)): YES - Affected by CVE-2019-11135 (ZombieLoad V2, TSX Asynchronous Abort (TAA)): NO - Affected by CVE-2018-12207 (No eXcuses, iTLB Multihit, machine check exception on page size changes (MCEPSC)): NO - Affected by CVE-2020-0543 (Special Register Buffer Data Sampling (SRBDS)): NO - Affected by CVE-2023-20593 (Zenbleed, cross-process information leak): NO CVE-2017-5753 aka ‘Spectre Variant 1, bounds check bypass’ - Mitigated according to the /sys interface: YES (Mitigation: usercopy/swapgs barriers and \_\_user pointer sanitization) - Kernel has array\_index\_mask\_nospec: /usr/sbin/spectre-meltdown-checker: line 3659: objdump: command not found NO - Kernel has the Red Hat/Ubuntu patch: NO - Kernel has mask\_nospec64 (arm64): UNKNOWN (missing ‘objdump’ tool, please install it, usually it’s in the binutils package) - Kernel has array\_index\_nospec (arm64): UNKNOWN (missing ‘objdump’ tool, please install it, usually it’s in the binutils package) - Checking count of LFENCE instructions following a jump in kernel… UNKNOWN (missing ‘objdump’ tool, please install it, usually it’s in the binutils package) > STATUS: NOT VULNERABLE (Mitigation: usercopy/swapgs barriers and \_\_user pointer sanitization) CVE-2017-5715 aka ‘Spectre Variant 2, branch target injection’ - Mitigated according to the /sys interface: YES (Mitigation: Retpolines; IBPB: conditional; IBRS\_FW; STIBP: disabled; RSB filling; PBRSB-eIBRS: Not affected; BHI: Not affected) - Mitigation 1 - Kernel is compiled with IBRS support: YES - IBRS enabled and active: UNKNOWN - Kernel is compiled with IBPB support: YES - IBPB enabled and active: YES - Mitigation 2 - Kernel has branch predictor hardening (arm): NO - Kernel compiled with retpoline option: YES - Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation) > STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the vulnerability) CVE-2017-5754 aka ‘Variant 3, Meltdown, rogue data cache load’ - Mitigated according to the /sys interface: YES (Mitigation: PTI) - Kernel supports Page Table Isolation (PTI): YES - PTI enabled and active: YES - Reduced performance impact of PTI: NO (PCID/INVPCID not supported, performance impact of PTI will be significant) - Running as a Xen PV DomU: NO > STATUS: NOT VULNERABLE (Mitigation: PTI) CVE-2018-3640 aka ‘Variant 3a, rogue system register read’ - CPU microcode mitigates the vulnerability: NO > STATUS: VULNERABLE (an up-to-date CPU microcode is needed to mitigate this vulnerability) CVE-2018-3639 aka ‘Variant 4, speculative store bypass’ - Mitigated according to the /sys interface: YES (Not affected) - Kernel supports disabling speculative store bypass (SSB): YES (found in /proc/self/status) - SSB mitigation is enabled and active: NO (not vulnerable) > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not affected) CVE-2018-3615 aka ‘Foreshadow (SGX), L1 terminal fault’ - CPU microcode mitigates the vulnerability: N/A > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not affected) CVE-2018-3620 aka ‘Foreshadow-NG (OS), L1 terminal fault’ - Mitigated according to the /sys interface: YES (Not affected) - Kernel supports PTE inversion: YES (found in kernel image) - PTE inversion enabled and active: NO > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not affected) CVE-2018-3646 aka ‘Foreshadow-NG (VMM), L1 terminal fault’ - Information from the /sys interface: Not affected - This system is a host running a hypervisor: NO - Mitigation 1 (KVM) - EPT is disabled: NO - Mitigation 2 - L1D flush is supported by kernel: YES (found flush\_l1d in kernel image) - L1D flush enabled: NO - Hardware-backed L1D flush supported: NO (flush will be done in software, this is slower) - Hyper-Threading (SMT) is enabled: NO > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not affected) CVE-2018-12126 aka ‘Fallout, microarchitectural store buffer data sampling (MSBDS)’ - Mitigated according to the /sys interface: YES (Mitigation: Clear CPU buffers; SMT disabled) - Kernel supports using MD\_CLEAR mitigation: YES (md\_clear found in /proc/cpuinfo) - Kernel mitigation is enabled and active: YES - SMT is either mitigated or disabled: YES > STATUS: NOT VULNERABLE (Your microcode and kernel are both up to date for this mitigation, and mitigation is enabled) CVE-2018-12130 aka ‘ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)’ - Mitigated according to the /sys interface: YES (Mitigation: Clear CPU buffers; SMT disabled) - Kernel supports using MD\_CLEAR mitigation: YES (md\_clear found in /proc/cpuinfo) - Kernel mitigation is enabled and active: YES - SMT is either mitigated or disabled: YES > STATUS: NOT VULNERABLE (Your microcode and kernel are both up to date for this mitigation, and mitigation is enabled) CVE-2018-12127 aka ‘RIDL, microarchitectural load port data sampling (MLPDS)’ - Mitigated according to the /sys interface: YES (Mitigation: Clear CPU buffers; SMT disabled) - Kernel supports using MD\_CLEAR mitigation: YES (md\_clear found in /proc/cpuinfo) - Kernel mitigation is enabled and active: YES - SMT is either mitigated or disabled: YES > STATUS: NOT VULNERABLE (Your microcode and kernel are both up to date for this mitigation, and mitigation is enabled) CVE-2019-11091 aka ‘RIDL, microarchitectural data sampling uncacheable memory (MDSUM)’ - Mitigated according to the /sys interface: YES (Mitigation: Clear CPU buffers; SMT disabled) - Kernel supports using MD\_CLEAR mitigation: YES (md\_clear found in /proc/cpuinfo) - Kernel mitigation is enabled and active: YES - SMT is either mitigated or disabled: YES > STATUS: NOT VULNERABLE (Your microcode and kernel are both up to date for this mitigation, and mitigation is enabled) CVE-2019-11135 aka ‘ZombieLoad V2, TSX Asynchronous Abort (TAA)’ - Mitigated according to the /sys interface: YES (Not affected) - TAA mitigation is supported by kernel: YES (found tsx\_async\_abort in kernel image) - TAA mitigation enabled and active: NO > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not affected) CVE-2018-12207 aka ‘No eXcuses, iTLB Multihit, machine check exception on page size changes (MCEPSC)’ - Mitigated according to the /sys interface: YES (Not affected) - This system is a host running a hypervisor: NO - iTLB Multihit mitigation is supported by kernel: YES (found itlb\_multihit in kernel image) - iTLB Multihit mitigation enabled and active: NO > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not affected) CVE-2020-0543 aka ‘Special Register Buffer Data Sampling (SRBDS)’ - Mitigated according to the /sys interface: YES (Not affected) - SRBDS mitigation control is supported by the kernel: YES (found SRBDS implementation evidence in kernel image. Your kernel is up to date for SRBDS mitigation) - SRBDS mitigation control is enabled and active: NO > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not affected) CVE-2023-20593 aka ‘Zenbleed, cross-process information leak’ - Zenbleed mitigation is supported by kernel: YES (found zenbleed message in kernel image) - Zenbleed kernel mitigation enabled and active: N/A (CPU is incompatible) - Zenbleed mitigation is supported by CPU microcode: NO > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not affected) > SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:KO CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:OK CVE-2018-12130:OK CVE-2018-12127:OK CVE-2019-11091:OK CVE-2019-11135:OK CVE-2018-12207:OK CVE-2020-0543:OK CVE-2023-20593:OK ---
**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\ **Post date:** [30 June 2024 08:14 UTC](https://community.ipfire.org/t/processor-vulnerability-mitigations-with-old-hardware/11804/3 "2024-06-30T08:14:54Z")
Hallo @bmmbmm01 Welcome to the IPFire community. > [@bmmbmm01](#): > > I’m getting: **Unknown: No mitigations** This message means that the processor involved has not been reviewed by Intel because it is considered too old so they have not confirmed if the processor is affected by the vulnerability or not and cannot therefore say that the mitigation that is in place will work or not, so they say that there is no mitigation. The message used to be that the processor was Unaffected for situations where the processor had not been investigated but Intel provided a patch to the kernel code to change the message to Unknown: No mitigations. [https://community.ipfire.org/t/mmio-stale-data-vulnerability/8810](https://community.ipfire.org/t/mmio-stale-data-vulnerability/8810) [https://www.phoronix.com/news/Linux-MMIO-Stale-Data-Old-CPUs](https://www.phoronix.com/news/Linux-MMIO-Stale-Data-Old-CPUs) The Linux documentation puts the statement, Unknown: No mitigations, as meaning `"The processor vulnerability status is unknown because it is out of Servicing period. Mitigation is not attempted." ` In terms of all mitigations provided by any processor manufacturer, they are always implemented in IPFire in the next Core Update release after the microcode update has been released so if you are up to date with the Core Updates you will have the latest microcode updates that are available. ---
**Author:** ![bmmbmm01](https://community.ipfire.org/user_avatar/community.ipfire.org/bmmbmm01/32/10535_2.png) [@bmmbmm01](https://community.ipfire.org/u/bmmbmm01)\ **Post date:** [30 June 2024 18:27 UTC](https://community.ipfire.org/t/processor-vulnerability-mitigations-with-old-hardware/11804/4 "2024-06-30T18:27:12Z")
Thank You. [fireinfo](https://www.ipfire.org/fireinfo/profile/53ae888b3ea78ba70ace16249662bbaeb3fa3926) I’m aware that this is fairly old hardware and trying to be fairly secure. > [@bmmbmm01](#): > > CVE-2018-3640 aka ‘Variant 3a, rogue system register read’ > > - CPU microcode mitigates the vulnerability: NO Per your other post i agree that the attack would need to be on network or have access to the physical Hardware. So its less of a concern. Was hoping for a fix as it appears fine with the defualt OS systems with firewalla. \*Ran checker on ubuntu 22 with no vulnerability listed. Make me wonder what ubuntu did… ? may just runthe code: [https://ubuntu.com/security/notices/USN-3756-1](https://ubuntu.com/security/notices/USN-3756-1) Good to know that the microcode in ipfire is updated per core updates. I may have to look for a different solution. I like ipfire as it just works. Have a few pro/cons with other systems. but ipfire is still my go to. In the past I have tested and ran different Router/Firewalla OS EX: ddwrt/openwrt, pfsense/opensens, ubuntu Linux with pihole(source build my own). Ran firewalla and unifi for some time as well. Guess it just time to go after new hardware. ---
**Author:** ![bmmbmm01](https://community.ipfire.org/user_avatar/community.ipfire.org/bmmbmm01/32/10535_2.png) [@bmmbmm01](https://community.ipfire.org/u/bmmbmm01)\ **Post date:** [30 June 2024 18:36 UTC](https://community.ipfire.org/t/processor-vulnerability-mitigations-with-old-hardware/11804/5 "2024-06-30T18:36:17Z")
I mainly brought it up as it is weird. as I find support saying it not affected and others saying it is. > **[CVE-2018-3640: Intel(R) Celeron(R) CPU N3160 vulnerable?](https://community.intel.com/t5/Processors/CVE-2018-3640-Intel-R-Celeron-R-CPU-N3160-vulnerable/td-p/1318818)** > > I am attempting to improve the security posture of a specialty computer system. According to the Linux tools, the processor in my system is Intel(R) Celeron(R) CPU N3160 @ 1.60GHz which is reported as cpu family : 6 > model : 76... > > > Possibly similar to #302 and #310, I get: > \# output > user@host:~$ sudo /usr/bin/…spectre-meltdown-checker --version > Spectre and Meltdown mitigation detection tool v0.43 > > \*\*selective copypasta from output with --explain:\*\* > \* CPU microcode is known to cause stability problems: NO (model 0x4c family 0x6 stepping 0x4 ucode 0x411 cpuid 0x406c4) > \* CPU microcode is the latest known available version: YES (latest version is 0x411 dated 2019/04/23 according to builtin firmwares DB v130.20191104+i20191027) > > CVE-2018-3640 aka \\'Variant 3a, rogue system register read\\' > \* CPU microcode mitigates the vulnerability: NO > \\\> STATUS: VULNERABLE (an up-to-date CPU microcode is needed to mitigate this vulnerability) > > CVE-2018-3640:KO > > \# system details > \`\`\` > user@host:~$ su root -c 'dmesg -t |grep -i "smpboot\\: CPU0"' > Password: > smpboot: CPU0: Intel(R) Celeron(R) CPU N3160 @ 1.60GHz (family: 0x6, model: 0x4c, stepping: 0x4) > > user@host:~$ cat /proc/cpuinfo | grep -m 4 'family\\|model\\|stepping' > cpu family : 6 > model : 76 > model name : Intel(R) Celeron(R) CPU N3160 @ 1.60GHz > stepping : 4 > > user@host:~$ su root -c 'dmesg -t | grep -i microcode' > Password: > microcode: microcode updated early to revision 0x411, date = 2019-04-23 > microcode: sig=0x406c4, pf=0x1, revision=0x411 > microcode: Microcode Update Driver: v2.2. > > user@host:~$ dpkg -l intel-microcode > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Name Version Architecture Description > +++-===============-===========================-============-=========================================== > ii intel-microcode 3.20210608.0ubuntu0.20.04.1 amd64 Processor microcode firmware for Intel CPUs > > user@host:~$ uname --kernel-name --kernel-release --kernel-version --machine --processor --hardware-platform --operating-system > Linux 5.11.0-27-generic #29~20.04.1-Ubuntu SMP Wed Aug 11 15:58:17 UTC 2021 x86\_64 x86\_64 x86\_64 GNU/Linux > \`\`\` > > \# question > I read \[Intel SA-00115\](https://www.intel.com/content/dam/www/public/us/en/documents/sa00115-microcode-update-guidance.pdf), which shows "Apollo Lake" Intel® Celeron® Processor N Series only N3350, N3450 are vulnerable and have a microcode update. I read \[Affected Processors: Transient Execution Attacks & Related Security Issues by CPU\](https://software.intel.com/content/www/us/en/develop/topics/software-security-guidance/processors-affected-consolidated-product-cpu-model.html), the 06\_4CH processor (corresponding to family 6, model 76 and the dmesg output, if I understand correctly) only lists the Atom processors affected. > > I checked \[ark.intel.com\](https://ark.intel.com/content/www/us/en/ark/compare.html?productIds=91831), and when I look at the full specs, I see that it is codename \[Braswell\](https://ark.intel.com/content/www/us/en/ark/products/91831/intel-celeron-processor-n3160-2m-cache-up-to-2-24-ghz.html), which is part of "Cherry View", not "Apollo Lake". > > \`\`\` > user@host:~$ sudo /usr/sbin/iucode-tool -V > iucode\_tool 2.3.1 > Copyright (c) 2010-2018 by Henrique de Moraes Holschuh > > Based on code from the Linux microcode\_intel driver and from > the microcode.ctl package, copyright (c) 2000 by Simon Trimmer > and Tigran Aivazian. > > This is free software; see the source for copying conditions. > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR > A PARTICULAR PURPOSE. > > user@host:~$ sudo /usr/sbin/iucode-tool -S > /usr/sbin/iucode-tool: system has processor(s) with signature 0x000406c4 > > user@host:~$ od -N16 -t x4 /lib/firmware/intel-ucode/06-4c-04 > 0000000 00000001 00000411 04232019 000406c4 > 0000020 > \`\`\` > According to \[Microcode Update Guidance\](https://software.intel.com/content/www/us/en/develop/articles/software-security-guidance/best-practices/microcode-update-guidance.html), in the above file header, 00000411 is the microcode version, 04232019 is the date on which the IPU was created, and 000406c4 is the family/model/stepping in the format returned by the CPUID instruction. > > Is this a false positive, or does this processor require a microcode update that is not available? Maybe it \[falls into the pit\](https://community.intel.com/t5/Processors/Braswell-CPU-Cherry-View/m-p/546236) outlined by the \[security advisory\](https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00115.html)? "A listing of microcode updates that have been production qualified can be found here and will be updated as necessary. It is expected that remaining microcode updates, currently in beta, will be production qualified in the coming weeks." > > Thank you for any guidance. ---
**Author:** ![bonnietwin](https://community.ipfire.org/user_avatar/community.ipfire.org/bonnietwin/32/12350_2.png) [@bonnietwin](https://community.ipfire.org/u/bonnietwin)\ **Post date:** [30 June 2024 18:48 UTC](https://community.ipfire.org/t/processor-vulnerability-mitigations-with-old-hardware/11804/6 "2024-06-30T18:48:03Z")
Both of those links have a response from Intel that says > > The official information about this topic is directly related to SA-00088: > > [https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00088.html](https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00088.html) > > You can find the “Affected products” section there, the Celeron N3160 is not listed nor any Braswell processors, so this processor is not affected by the Spectre and Meltdown. However prior to 2022 (comment was made in 2021) then saying a processor is not affected could mean that the processor has been reviewed and found to actually not be affected or it could mean that the processor has not been reviewed and it is not known if it is affected or not. If the processor is marked as “not affected” or “unknown” by Intel then any microcode defined by Intel will not be applied to that processor, so if non-Intel people say the processor is affected it will make no difference to the mitigation application from the microcode files as Intel define what microcodes are applied to what processors based on their investigation on whether a processor is affected or not.