- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
My CPU is listed first in the updated guidance here https://www.intel.com/content/dam/www/public/us/en/documents/sa00115-microcode-update-guidance.pdf https://www.intel.com/content/dam/www/public/us/en/documents/sa00115-microcode-update-guidance.pdf .
The latest microcode update file contains only rev. 0x2C (dated 2017-03-25 very old, can't contain a single Spectre mitigation).
Where can I get or download the mentioned revision 0x32?
The computer manufacturer apparently needs a couple of more time providing a BIOS update in a timely manner (mentioned reason was trouble with the management engine).
So I need the firmware directly from Intel.
Who can help?
Kind regards
G.
- Tags:
- CPU
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello guardian18
Thank you for joining this community.
In this case, along with other companies whose platforms are impacted, Intel has worked with operating system vendors, equipment manufacturers, and other ecosystem partners to develop software and firmware updates that can protect computers from these methods.
In this case since the latest microcode update file contains only rev. 0x2C, dated back in 17/03/25, we strongly encourage our customers to check with their operating system vendors and system manufacturers, and apply any available updates as soon as they are available. You should do this whether you use an Intel-based system, or other computer or mobile device.
For full details on this topic please check the following link:
https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html
Hope this helps.
Regards,
Diego S.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When you use only CPUID Signature then it is quite hard to grasp about which processor you ask.
There is something strange with Apollo Lake SoC support by Intel. They didn't release microcode update for Linux OS or Microsoft Windows. Even when proper microcodes were prepared by them. What's more I found some hints which suggest that this SoC isn't vulnerable to Meltdown. I've disabled Meltdown mitigation on all my devices based on that platform. That was a relieve because this CPU doesn't support INVPCID feature and that would slow it even more.
You can find the newest microcode for this SoC (version 0x32 dated 2018-05-11) inside Microcode Extractor (https://github.com/platomav/MCExtractor MCExtractor) https://github.com/platomav/CPUMicrocodes repository. Nevertheless updating BIOS with new microcode on your platform independently from manufacturer might be tricky or sometimes plainly impossible (vide ASUS CAP BIOS file on motherboards without USB Flashback feature).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you, Gorbush.
Now Linux with updated microcode in its update function says:
[0.000000] microcode: microcode updated early to revision 0x32, date = 2018-05-11According to the output of the spectre-meltdown-checker.sh it is the CPU by a flag telling that it it isn't vulnerable to Meltdown. So the kernel doesn't enable PTI and no performance impact here:
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
For other OS facilities and transparency might be more limited.
Regarding Intel:
You are saying nothing with your answer. I see it as ignorant, arrogant and not customer orientated (your real customers are always the customer's of your direct customers, as you probably know) to not at least give a reason why the microcode update is not made publicly available (only in an engaged forum). I'd be willing to believe technical reasons if you name it.
Of course I am checking with my system manufacturer, who luckily states be working on BIOS updates, but also having technical problems (no details mentioned) and probably much efforts to pace with the newer discovered vulnerabilities. So besides Spectre v1/2 and Meltdown and the old Intel ME bug, 6 new Spectre vulnerabilities and another new in ME.
Intel, you are not doing your job!
I completely second the expectation mentioned in another post, that we don't receive fixes in silicon for 4 years from you. Would be glad to have reasons for better assumptions.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO"
This mean that your CPU reports that it isn't secured against Meltdown.
It seems that microcode update isn't enough. Contrary to what was said http://freebsd.1045724.x6.nabble.com/FreeBSD-Security-Advisory-FreeBSD-SA-18-03-speculative-execution-tp6244729p6247057.html there in FreeBSD security http://openbsd-archive.7691.n7.nabble.com/Meltdown-workaround-enabled-td338563.html forum.
I've that flag set to YES after updating BIOS inside my NUC6CAYS to version /thread/122453 # 47.
Now under Windows with CPU-Z version 1.84 and above I can read that setting (inside a report):
IBRSsupported, disabledIBPBsupportedSTIBPsupported, disabledRDCL_NOyesIBRS_ALLnot supportedEdit:
Strange, I've just noticed that IBRS (one of countermeasures against Spectre variant 2) is supposedly disabled .
P.S.
Nice to have Linux where you can upgrade microcode with easy.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Gorbush wrote:
"CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO"
This mean that your CPU reports that it isn't secured against Meltdown.
It seems that microcode update isn't enough.
Command "grep . /sys/devices/system/cpu/vulnerabilities/meltdown" returns "Not affected" with microcode versions 0x2e and 0x32 (but not 0x2c) for my Apollo Lake CPU.
I checked the source code for the running kernel: The only factor which makes the kernel believe this (for CPUs supporting MSR but not from AMD) is from RDCL_NO.
But spectre-meltdown-checker.sh doesn't see this - strange. IMO it should, because command "rdmsr 0x10a" returns value 19, where RDCL_NO is the lowest bit which is set.
In the end I rely on the microcode patched CPU being honest.
@Intel support: Can safely be assumed that Meltdown is fixed by the microcode update when reported as this, and microcode updated early by Linux?
P.S.
Nice to have Linux where you can upgrade microcode with easy.
Indeed, and not only this, you can check what it does by looking at the sources, as above.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
RE: Can safely be assumed that Meltdown is fixed by the microcode update when reported as this, and microcode updated early by Linux?
No! The microcode fixes specifically address only Spectre Variants 2 & 3. They DO NOT address Meltdown! Meltdown is addressed by specific workarounds introduced at the O/S level.
...S
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Scott Pearson wrote:
RE: Can safely be assumed that Meltdown is fixed by the microcode update when reported as this, and microcode updated early by Linux?
No! The microcode fixes specifically address only Spectre Variants 2 & 3. They DO NOT address Meltdown! Meltdown is addressed by specific workarounds introduced at the O/S level.
...S
Meltdown and Spectre Variant 3 mean the same: Rogue Data Cache Load (RDCL) CVE-2017-5754 .
So: Microcode fixes potentially address also Meltdown.
With the latest microcode revision 0x32 (Apollo Lake CPUID 506C9) RDCL_NO is set when loaded early by the Linux kernel (but not by BIOS).
The issue is that the kernel disables PTI mitigation for Meltdown then. Therefore the question:
@Intel support: Can safely be assumed that Spectre Variant 3 (Meltdown) is fixed when the microcode update 0x32 for CPUID 506C9 is updated early by Linux?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That is a honest mistake by Scott. He meant Spectre variant 2 (https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00088.html Branch Target Injection) & 4 (https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00115.html Speculative Store Bypass). Variant 3 (https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00115.html Rogue Data Cache Load vel Meltdown) can't be circumvented by microcode because there is nothing to disable or to flush like branch predictor buffer.
Back to Apollo Lake SoC and Meltdown. That vulnerability isn't mitigated by microcode. It seems that this CPU isn't easily affected by that loop hole. There are some users of OpenBSD which did some tests. You can read about their findings http://openbsd-archive.7691.n7.nabble.com/Meltdown-workaround-enabled-tp338563p338703.html there: http://openbsd-archive.7691.n7.nabble.com/Meltdown-workaround-enabled-tp338563p338703.html "openbsd user - misc - Meltdown workaround enabled?".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Gorbush. Apparently the flag was changed because of PoC results. This leaves some uncertainty (that the PoC can potentially be improved to yield side channel data), but can be acceptable for such a small system.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
guardian18 wrote:
But spectre-meltdown-checker.sh doesn't see this - strange. IMO it should, because command "rdmsr 0x10a" returns value 19, where RDCL_NO is the lowest bit which is set.
It seems that there is an error inside spectre-meltdown-checker script:
[ $(( capabilities & 1 )) -eq 1 ] && capabilities_rdcl_no=1It is a bash syntax but the first line points to /bin/sh rather than /bin/bash.
If MSR 0x10A returns 0x19 then it mean that CPU isn't vulnerable to Meltdown(RDCL) and Spectre variant 4 (SSB). I've got exact same value there. Besides there is CPUID method to determine RDCL_NO and SSB_NO flags. CPUID function 7 return in EDX register these values. I've got "0x2C000000" there. Without at least 2Eh microcode there will be all zeros.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, sorry, my bad, Spectre variants 2 and 4. My understanding is that variants 1 and 3 require additional resources that make it impossible to implement via a change in microcode (silicon changes will definitely be required).
...S
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you Mr. Intel. At least Linux is safe to use right now with Apollo Lake SoC.
https://downloadcenter.intel.com/download/28039/Linux-Processor-Microcode-Data-File?product=873 https://downloadcenter.intel.com/download/28039/Linux-Processor-Microcode-Data-File?product=873
That contain 0x32 (latest) microcode version for Apollo Lake platform.
I hope that the same will happen with MS Windows KB4100347 update.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nine months ago I wrote: "I hope that the same will happen with MS Windows KB4100347 update."
Only recently (16th of May) it happened. For Windows 10 version 1809 there is patch KB4465065 available which gracefully incorporate microcode updated version 0x32 for Apollo Lake SoC (0x506C9 - CPUID). Now I only need to wait 9 more months to get 0x38 version with "mitigation" for MDS. I can do it :).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page