Hi,
Well guys, its time to panic once again.
I just found out my system is vulnerable to the new Crosstalk vulnerability by running the popular Meltdown OVH script.
More about the vulnerability over here:
https://www.vusec.net/projects/crosstalk/
These exploits get worse each time, this one affects all cores.
This is how I tested for the vulnerability.
Downloaded spectre-meltdown-checker.sh via :
wget https://meltdown.ovh -O spectre-meltdown-checker.sh
and then just executed with sudo.
This is the output I got:
* SRBDS mitigation control is enabled and active: NO
STATUS: VULNERABLE (Your CPU microcode may need to be updated to mitigate the vulnerability)
CVE-2020-0543:KO
Full output here: https://pastebin.com/raw/hyfFBbaF
As you can see the tool specifies that my microcode is not the latest.
That being said, where do I find the latest microcode from ?
My OS is fully updated, and the firmware and microcode is also latest according to DNF:
$ sudo dnf update linux-firmware Dependencies resolved. Nothing to do. Complete!
$ sudo dnf update microcode_ctl Dependencies resolved. Nothing to do. Complete!
So where is the microcode update in Fedora for this ??
Canonical has already published microcode updates for this, as shown here: https://youtu.be/UR-5vAZ1cGg?t=1160
<rant> It kind of seems frustrating that a bleeding edge distro like Fedora still hasn't provided updates yet. While Ubuntu a distro that doesn't always use the latest software already has a fix. </rant>
What can I do now ? What is progress for Fedora ?
Will the microcode from Canonical work for Fedora ? Dumb question I know but I am desperate.
Let me know if any further info is required.
Some more info about my CPU: https://pastebin.com/raw/TNJS930F
What is everyone else in the community doing about this ?
Thanks.
On 2020-06-29 07:33, Sreyan Chakravarty wrote:
Hi,
Well guys, its time to panic once again.
I just found out my system is vulnerable to the new Crosstalk vulnerability by running the popular Meltdown OVH script.
More about the vulnerability over here:
https://www.vusec.net/projects/crosstalk/
These exploits get worse each time, this one affects all cores.
This is how I tested for the vulnerability.
Downloaded spectre-meltdown-checker.sh via :
wget https://meltdown.ovh -O spectre-meltdown-checker.sh
and then just executed with sudo.
This is the output I got:
- SRBDS mitigation control is enabled and active: NO
STATUS: VULNERABLE (Your CPU microcode may need to be updated to mitigate the vulnerability)
CVE-2020-0543:KO
I get
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 vulnerable)
This was reported fixed in microcode_ctl-2.1-39.fc32 as shown in the links you've provided.
Do you have that package updated?
On 6/28/20 10:03 PM, Ed Greshko wrote:
On 2020-06-29 07:33, Sreyan Chakravarty wrote:
- SRBDS mitigation control is enabled and active: NO
STATUS: VULNERABLE (Your CPU microcode may need to be updated to mitigate the vulnerability)
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 vulnerable)
Notice the reason that yours is not vulnerable. You have a different CPU model that doesn't have the problem.
On 2020-06-29 13:54, Samuel Sieb wrote:
On 6/28/20 10:03 PM, Ed Greshko wrote:
On 2020-06-29 07:33, Sreyan Chakravarty wrote:
- SRBDS mitigation control is enabled and active: NO
STATUS: VULNERABLE (Your CPU microcode may need to be updated to mitigate the vulnerability)
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 vulnerable)
Notice the reason that yours is not vulnerable. You have a different CPU model that doesn't have the problem.
Good point. Didn't read far enough. :-(
Yet....
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedorap...
Indicates....
Update Information:
Security fix for CVE-2020-0548, CVE-2020-0549, CVE-2020-0543 ---- Update to upstream 2.1-28. 20200609
So, shouldn't that take care of CPU's that are vulnerable?
On Mon, Jun 29, 2020 at 11:25 AM Samuel Sieb samuel@sieb.net wrote:
On 6/28/20 10:03 PM, Ed Greshko wrote:
On 2020-06-29 07:33, Sreyan Chakravarty wrote:
- SRBDS mitigation control is enabled and active: NO
STATUS: VULNERABLE (Your CPU microcode may need to be updated to
mitigate the vulnerability)
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 vulnerable)
Notice the reason that yours is not vulnerable. You have a different CPU model that doesn't have the problem. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Who else can I contact for this problem ?
If a fix has been released why haven't I received it ? What's going on here ?
On 2020-06-29 19:22, Sreyan Chakravarty wrote:
On Mon, Jun 29, 2020 at 11:25 AM Samuel Sieb <samuel@sieb.net mailto:samuel@sieb.net> wrote:
On 6/28/20 10:03 PM, Ed Greshko wrote: > On 2020-06-29 07:33, Sreyan Chakravarty wrote: >> * SRBDS mitigation control is enabled and active: NO >>> STATUS: VULNERABLE (Your CPU microcode may need to be updated to mitigate the vulnerability) > > 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 vulnerable) Notice the reason that yours is not vulnerable. You have a different CPU model that doesn't have the problem.Who else can I contact for this problem ?
If a fix has been released why haven't I received it ? What's going on here ?
So, you're saying you get...
[egreshko@meimei ~]$ rpm -q microcode_ctl microcode_ctl-2.1-39.fc32.x86_64
That is the version that is tagged is fixing the issue.
And the problem still exists? If so, file a Bugzilla against that package.
On Mon, Jun 29, 2020 at 10:34 AM Ed Greshko ed.greshko@greshko.com wrote:
On 2020-06-29 07:33, Sreyan Chakravarty wrote:
Hi,
Well guys, its time to panic once again.
I just found out my system is vulnerable to the new Crosstalk
vulnerability by running the popular Meltdown OVH script.
More about the vulnerability over here:
https://www.vusec.net/projects/crosstalk/
These exploits get worse each time, this one affects all cores.
This is how I tested for the vulnerability.
Downloaded spectre-meltdown-checker.sh via :
wget https://meltdown.ovh -O spectre-meltdown-checker.sh
and then just executed with sudo.
This is the output I got:
- SRBDS mitigation control is enabled and active: NO
STATUS: VULNERABLE (Your CPU microcode may need to be updated to
mitigate the vulnerability)
CVE-2020-0543:KO
I get
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
vulnerable)
This was reported fixed in microcode_ctl-2.1-39.fc32 as shown in the links you've provided.
Do you have that package updated?
How do I update the microcode ?
As you can see DNF already tells me my microcode is already the latest version.
What else can I do ?
On 2020-06-29 19:20, Sreyan Chakravarty wrote:
How do I update the microcode ?
The microcode gets updated on each reboot. It is not permanent.
As you can see DNF already tells me my microcode is already the latest version.
Well, you are running F31 or F32? Meaning you're not running an EOL version by any chance?
On 2020-06-29 20:02, Ed Greshko wrote:
On 2020-06-29 19:20, Sreyan Chakravarty wrote:
How do I update the microcode ?
The microcode gets updated on each reboot. It is not permanent.
As you can see DNF already tells me my microcode is already the latest version.
Well, you are running F31 or F32? Meaning you're not running an EOL version by any chance?
I should have checked the full output you posted....
You're running....
Kernel is Linux 5.6.19-300.fc32.x86_64 #1 SMP Wed Jun 17 16:10:48 UTC 2020 x86_64
So, is the proper microcode_ctl installed?
rpm -q microcode_ctl
On 6/29/20 5:41 PM, Ed Greshko wrote:
I should have checked the full output you posted....
You're running....
Kernel is Linux 5.6.19-300.fc32.x86_64 #1 SMP Wed Jun 17 16:10:48 UTC 2020 x86_64
So, is the proper microcode_ctl installed?
rpm -q microcode_ctl
As I already confirmed before, I do have the latest microcode.
Here is the rpm version output once again:
$ rpm -q microcode_ctl microcode_ctl-2.1-39.fc32.x86_64
So is it now confirmed that this is a bug ?
Is there nothing else I can do ?
On 2020-06-29 20:24, Sreyan Chakravarty wrote:
On 6/29/20 5:41 PM, Ed Greshko wrote:
I should have checked the full output you posted....
You're running....
Kernel is Linux 5.6.19-300.fc32.x86_64 #1 SMP Wed Jun 17 16:10:48 UTC 2020 x86_64
So, is the proper microcode_ctl installed?
rpm -q microcode_ctl
As I already confirmed before, I do have the latest microcode.
Here is the rpm version output once again:
$ rpm -q microcode_ctl microcode_ctl-2.1-39.fc32.x86_64
So is it now confirmed that this is a bug ?
Is there nothing else I can do ?
Well, first, you did reboot after the latest version of microcode_ctl was installed? The microcode gets applied at boot time, each time.
On my system, microcode_ctl was updated on 2020-06-19.
dnf history list microcode_ctl
will tell you when that package was updated.
You've rebooted since then?
On 6/29/20 6:19 PM, Ed Greshko wrote:
Well, first, you did reboot after the latest version of microcode_ctl was installed? The microcode gets applied at boot time, each time.
On my system, microcode_ctl was updated on 2020-06-19.
dnf history list microcode_ctl
will tell you when that package was updated.
You've rebooted since then?
I rebooted multiple times since the installation and I have rebooted now just to be sure.
$ dnf history list microcode_ctl ID | Command line | Date and time | Action(s) | Altered -------------------------------------------------------------------------------- 28 | | 2020-06-23 01:41 | E, I, U | 115 < 26 | | 2020-06-12 17:51 | I, U | 455 >< 19 | | 2020-05-09 18:02 | D, E, I, U | 2335 >< 3 | | 2020-04-13 17:19 | E, I, U | 1115 >< 1 | | 2020-04-13 16:42 | Install | 2197 >E
As you see on my system the microcode_ctl package was installed on 23rd June, 2020.
What is the next step ?
On 2020-06-29 21:17, Sreyan Chakravarty wrote:
On 6/29/20 6:19 PM, Ed Greshko wrote:
Well, first, you did reboot after the latest version of microcode_ctl was installed? The microcode gets applied at boot time, each time.
On my system, microcode_ctl was updated on 2020-06-19.
dnf history list microcode_ctl
will tell you when that package was updated.
You've rebooted since then?
I rebooted multiple times since the installation and I have rebooted now just to be sure.
$ dnf history list microcode_ctl ID | Command line | Date and time | Action(s) | Altered
28 | | 2020-06-23 01:41 | E, I, U | 115 < 26 | | 2020-06-12 17:51 | I, U | 455 >< 19 | | 2020-05-09 18:02 | D, E, I, U | 2335 >< 3 | | 2020-04-13 17:19 | E, I, U | 1115 >< 1 | | 2020-04-13 16:42 | Install | 2197 >E
As you see on my system the microcode_ctl package was installed on 23rd June, 2020.
What is the next step ?
Well, I suppose that would be filing a bugzilla against microcode_ctl.
Even though my CPU isn't affected I get...
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 vulnerable)
The first line shows mitigation is there....but not being used.
You system reports...
* Mitigated according to the /sys interface: NO (Vulnerable: No microcode)
So, it sounds to me as if the conditions don't exist for microcode_ctl to update the microcode on boot even with the most recent update.
In the BZ I would include the output of "cat /proc/cpuinfo".
On 6/29/20 6:57 PM, Ed Greshko wrote:
On 2020-06-29 21:17, Sreyan Chakravarty wrote:
On 6/29/20 6:19 PM, Ed Greshko wrote:
Well, first, you did reboot after the latest version of microcode_ctl was installed? The microcode gets applied at boot time, each time.
On my system, microcode_ctl was updated on 2020-06-19.
dnf history list microcode_ctl
will tell you when that package was updated.
You've rebooted since then?
I rebooted multiple times since the installation and I have rebooted now just to be sure.
$ dnf history list microcode_ctl ID | Command line | Date and time | Action(s) | Altered
28 | | 2020-06-23 01:41 | E, I, U | 115 < 26 | | 2020-06-12 17:51 | I, U | 455 >< 19 | | 2020-05-09 18:02 | D, E, I, U | 2335 >< 3 | | 2020-04-13 17:19 | E, I, U | 1115 >< 1 | | 2020-04-13 16:42 | Install | 2197 >E
As you see on my system the microcode_ctl package was installed on 23rd June, 2020.
What is the next step ?
Well, I suppose that would be filing a bugzilla against microcode_ctl.
Even though my CPU isn't affected I get...
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 vulnerable)
The first line shows mitigation is there....but not being used.
You system reports...
- Mitigated according to the /sys interface: NO (Vulnerable: No
microcode)
So, it sounds to me as if the conditions don't exist for microcode_ctl to update the microcode on boot even with the most recent update.
In the BZ I would include the output of "cat /proc/cpuinfo".
-- The key to getting good answers is to ask good questions.
Is BugZilla down right now ?
Can't open it, the connection is timed out.
On 2020-06-29 22:22, Sreyan Chakravarty wrote:
On 6/29/20 6:57 PM, Ed Greshko wrote:
On 2020-06-29 21:17, Sreyan Chakravarty wrote:
On 6/29/20 6:19 PM, Ed Greshko wrote:
Well, first, you did reboot after the latest version of microcode_ctl was installed? The microcode gets applied at boot time, each time.
On my system, microcode_ctl was updated on 2020-06-19.
dnf history list microcode_ctl
will tell you when that package was updated.
You've rebooted since then?
I rebooted multiple times since the installation and I have rebooted now just to be sure.
$ dnf history list microcode_ctl ID | Command line | Date and time | Action(s) | Altered
28 | | 2020-06-23 01:41 | E, I, U | 115 < 26 | | 2020-06-12 17:51 | I, U | 455 >< 19 | | 2020-05-09 18:02 | D, E, I, U | 2335 >< 3 | | 2020-04-13 17:19 | E, I, U | 1115 >< 1 | | 2020-04-13 16:42 | Install | 2197 >E
As you see on my system the microcode_ctl package was installed on 23rd June, 2020.
What is the next step ?
Well, I suppose that would be filing a bugzilla against microcode_ctl.
Even though my CPU isn't affected I get...
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 vulnerable)
The first line shows mitigation is there....but not being used.
You system reports...
- Mitigated according to the /sys interface: NO (Vulnerable: No microcode)
So, it sounds to me as if the conditions don't exist for microcode_ctl to update the microcode on boot even with the most recent update.
In the BZ I would include the output of "cat /proc/cpuinfo".
-- The key to getting good answers is to ask good questions.
Is BugZilla down right now ?
Can't open it, the connection is timed out.
I can connect, no problem.
But, another thing you may want to try is to boot to a previous kernel and reinstall 5.6.19-300. In doing some google searches a similar sounding problem was due to a badly built initramfs.
While everything I've read indicates the microcode is updated on each reboot I didn't come across what actually triggers it. Something to research.
On 6/29/20 8:09 PM, Ed Greshko wrote:
But, another thing you may want to try is to boot to a previous kernel and reinstall 5.6.19-300. In doing some google searches a similar sounding problem was due to a badly built initramfs.
I did a rebuild of my initramfs using:
dracut -f
Then rebooted and ran the test once again. No change. The vulnerability still exists.
Have we exhausted all options ?
On 6/29/20 5:32 PM, Ed Greshko wrote:
The microcode gets updated on each reboot. It is not permanent.
What do you mean ? Then how am I suppose to fix this issue ?
Well, you are running F31 or F32? Meaning you're not running an EOL version by any chance?
Fedora 32 with the latest patches as reported from Gnome Software center.
On 6/29/20 5:02 AM, Ed Greshko wrote:
On 2020-06-29 19:20, Sreyan Chakravarty wrote:
How do I update the microcode ?
The microcode gets updated on each reboot. It is not permanent.
That's true, but also it's loaded from the initramfs, so you either need to install a new kernel or update the initramfs using dracut to update the microcode.
On 6/29/20 10:12 AM, Samuel Sieb wrote:
On 6/29/20 5:02 AM, Ed Greshko wrote:
On 2020-06-29 19:20, Sreyan Chakravarty wrote:
How do I update the microcode ?
The microcode gets updated on each reboot. It is not permanent.
That's true, but also it's loaded from the initramfs, so you either need to install a new kernel or update the initramfs using dracut to update the microcode.
Right after I hit send, I realized that I should have included the command. "dracut -f" will update the initramfs for the current kernel.
On 6/29/20 10:42 PM, Samuel Sieb wrote:
On 6/29/20 5:02 AM, Ed Greshko wrote:
On 2020-06-29 19:20, Sreyan Chakravarty wrote:
How do I update the microcode ?
The microcode gets updated on each reboot. It is not permanent.
That's true, but also it's loaded from the initramfs, so you either need to install a new kernel or update the initramfs using dracut to update the microcode.
Didn't work. I updated initramfs using :
dracut -f
rebooted. But the bug still exists. No change.
Now what ?
On Mon, 29 Jun 2020 16:50:57 +0530 Sreyan Chakravarty sreyan32@gmail.com wrote:
How do I update the microcode ?
As you can see DNF already tells me my microcode is already the latest version.
What else can I do ?
It seems that you have got an answer, install a new kernel, or rebuild the initramfs to include the new microcode.
On the link you provided, it says this:
"The mitigation locks the entire memory bus before updating the staging buffer and only unlocks it after clearing its content. This strategy ensures no information is exposed to offcore requests issued from other CPU cores. Due to the considerable performance overhead of locking the entire system’s memory bus, Intel only applied the mitigation to harden a small number of security-critical instructions, specifically RDRAND, RDSEED, and EGETKEY (a leaf of the ENCLU instruction). This means that output from any other instruction (e.g., RDMSR) that issues offcore requests can be still leaked across CPU cores."
Thus, even if the mitigation is loaded, the system is still vulnerable at some level. There is nothing you can do beyond what you have done, though. I don't know how the tool you are using to check functions, but it could be that it is seeing these additional vulnerabilities and reporting that your system is still vulnerable even though the mitigation is in place, and the worst vulnerabilities are protected.
An extreme measure you could take might be to buy a system with a CPU that is not vulnerable. The article mentions that they do exist, even some from Intel.
On 6/30/20 2:09 AM, stan via users wrote:
It seems that you have got an answer, install a new kernel, or rebuild the initramfs to include the new microcode.
Except that this does not work. The meltdown ovh script still reports that my system is vulnerable.
I did a rebuild of my initramfs using:
dracut -f
Then rebooted and checked once again. No change. The vulnerability still exists.
Thus, even if the mitigation is loaded, the system is still vulnerable at some level.
Would be great if I could be absolutely certain about this.
For now, saying that it works without verification, is just like wishful thinking for me.
There is nothing you can do beyond what you have done, though.
So is it confirmed this is a bug in the microcode ?
I don't know how the tool you are using to check functions, but it could be that it is seeing these additional vulnerabilities and reporting that your system is still vulnerable even though the mitigation is in place, and the worst vulnerabilities are protected.
Yeah, this all sounds great. But again, I have to be sure.
I don't want security to be a crystal ball.
An extreme measure you could take might be to buy a system with a CPU that is not vulnerable. The article mentions that they do exist, even some from Intel.
That's not very sensible when a fix already exists and is not working. Why should I pay extra for things that are suppose to be fixed in the code that actually advertises it fixes them ?
On Tue, Jun 30, 2020 at 09:25:01PM +0530, Sreyan Chakravarty wrote:
Would be great if I could be absolutely certain about this.
For now, saying that it works without verification, is just like wishful thinking for me.
Take a look at /proc/cpuinfo
Your CPU code will be the: 'cpu family'-'model'-'stepping'
So, for example, on my computer, that is: 6 - 58 - 9
Now, Intel uses the hex for that, so lets get it easily:
$ printf '%02x-%02x-%02x\n' 6 58 9 06-3a-09
So, lets look at the github page for the intel microcode releases:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases
I don't see my CPU ID mentioned there, so the latest microcode doesn't seem to have been updated for my CPU. Either the CPU isn't vulnerable or they didn't address it.
But if I look at another computer:
$ printf '%02x-%02x-%02x\n' 6 94 3 06-5e-03
I do see it. And the microcode_ctl update does appear to be applying an update. Actually, that one is a RHEL system and in its notes, it says that it doesn't apply the microcode update because it causes hangs.
Hopefully this will help you research your own system.
On 6/30/20 9:56 PM, Jonathan Billings wrote:
On Tue, Jun 30, 2020 at 09:25:01PM +0530, Sreyan Chakravarty wrote:
Would be great if I could be absolutely certain about this.
For now, saying that it works without verification, is just like wishful thinking for me.
Take a look at /proc/cpuinfo
Your CPU code will be the: 'cpu family'-'model'-'stepping'
So, for example, on my computer, that is: 6 - 58 - 9
Now, Intel uses the hex for that, so lets get it easily:
$ printf '%02x-%02x-%02x\n' 6 58 9 06-3a-09
So, lets look at the github page for the intel microcode releases:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases
I don't see my CPU ID mentioned there, so the latest microcode doesn't seem to have been updated for my CPU. Either the CPU isn't vulnerable or they didn't address it.
But if I look at another computer:
$ printf '%02x-%02x-%02x\n' 6 94 3 06-5e-03
I do see it. And the microcode_ctl update does appear to be applying an update. Actually, that one is a RHEL system and in its notes, it says that it doesn't apply the microcode update because it causes hangs.
Hopefully this will help you research your own system.
Thank you. Just one question what happens if I find out that my CPU is affected but they did not address it ?
Should I open a report on BZ ?
On Tue, 30 Jun 2020 at 17:04, Sreyan Chakravarty sreyan32@gmail.com wrote:
On 6/30/20 9:56 PM, Jonathan Billings wrote:
On Tue, Jun 30, 2020 at 09:25:01PM +0530, Sreyan Chakravarty wrote:
Would be great if I could be absolutely certain about this.
For now, saying that it works without verification, is just like wishful thinking for me.
Take a look at /proc/cpuinfo
Your CPU code will be the: 'cpu family'-'model'-'stepping'
So, for example, on my computer, that is: 6 - 58 - 9
Now, Intel uses the hex for that, so lets get it easily:
$ printf '%02x-%02x-%02x\n' 6 58 9 06-3a-09
So, lets look at the github page for the intel microcode releases:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases
I don't see my CPU ID mentioned there, so the latest microcode doesn't seem to have been updated for my CPU. Either the CPU isn't vulnerable or they didn't address it.
But if I look at another computer:
$ printf '%02x-%02x-%02x\n' 6 94 3 06-5e-03
I do see it. And the microcode_ctl update does appear to be applying an update. Actually, that one is a RHEL system and in its notes, it says that it doesn't apply the microcode update because it causes hangs.
Hopefully this will help you research your own system.
Thank you. Just one question what happens if I find out that my CPU is affected but they did not address it ?
Should I open a report on BZ ?
RedHat and other linux distros track Intel's efforts. Some of the mitigations require changes to the kernel. I'm sure many of the discussions around which mitigations and CPU's get priority are not public, but you can certainly open an issue at:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues
In general, the earlier the mitigations are applied, the harder it is to exploit the bugs, and some mitigations can only be applied at the BIOS level, so you need to check your BIOS vendor's updates and forums.
All distributions have access to the same microcode, but may make different decisions for what should be done in BIOS and when to implement kernel changes to support new microcode. Ubuntu Security Page for CVE-2020-0543 https://people.canonical.com/~ubuntu-security/cve/2020/CVE-2020-0543.html is well organized and may be helpful checking to see if new microcode is available for your CPU.
On Wed, Jul 1, 2020 at 4:06 AM George N. White III gnwiii@gmail.com wrote:
In general, the earlier the mitigations are applied, the harder it is to exploit the bugs, and some mitigations can only be applied at the BIOS level, so you need to check your BIOS vendor's updates and forums.
Sorry for the late reply.
Does anyone here use an HP laptop ?
Specifically this model: https://support.hp.com/in-en/document/c04919819#AbT1
I have a very weird problem it seems. In my BIOS startup screen there seems to be no option like "Update BIOS".
The particular model I am using HP only publishes exe files that can be used from within Windows via which the BIOS update can happen within the OS.
They do not care about Linux. Hence my only option was to do the BIOS update from outside the OS. Now I can't find the option to update the BIOS from a USB.
I have contacted HP via their Community forum but I doubt that I will get a response.
In the meantime if anyone knows anything about this problem let me know, or what the best place would be to ask about this issue.
Thanks.
On Mon, 20 Jul 2020 at 18:59, Sreyan Chakravarty sreyan32@gmail.com wrote:
On Wed, Jul 1, 2020 at 4:06 AM George N. White III gnwiii@gmail.com wrote:
In general, the earlier the mitigations are applied, the harder it is to exploit the bugs, and some mitigations can only be applied at the BIOS level, so you need to check your BIOS vendor's updates and forums.
Sorry for the late reply.
Does anyone here use an HP laptop ?
Specifically this model: https://support.hp.com/in-en/document/c04919819#AbT1
This mentions FreeDOS under "Software" at the bottom of the page.
I have a very weird problem it seems. In my BIOS startup screen there seems to be no option like "Update BIOS".
The particular model I am using HP only publishes exe files that can be used from within Windows via which the BIOS update can happen within the OS.
They do not care about Linux. Hence my only option was to do the BIOS update from outside the OS. Now I can't find the option to update the BIOS from a USB.
I have contacted HP via their Community forum but I doubt that I will get a response.
In the meantime if anyone knows anything about this problem let me know, or what the best place would be to ask about this issue.
https://support.hp.com/ca-en/document/c00042629 suggests that you can create a BIOS update USB drive from a BIOS update .exe file using a different PC running Windows. Some .exe files run in freeDOS and generate a .bin file. Some HP laptops have "BIOS update from file" in the System Diagnostics (maybe press F2 while booting) with the .bin file on a FAT format USB key.
https://askubuntu.com/questions/539120/how-to-perform-a-hp-bios-upgrade-with... has a number of examples for differnet HP models.
On Mon, 20 Jul 2020 20:27:44 -0300 "George N. White III" gnwiii@gmail.com wrote:
On Mon, 20 Jul 2020 at 18:59, Sreyan Chakravarty sreyan32@gmail.com wrote:
On Wed, Jul 1, 2020 at 4:06 AM George N. White III gnwiii@gmail.com wrote:
In general, the earlier the mitigations are applied, the harder it is to exploit the bugs, and some mitigations can only be applied at the BIOS level, so you need to check your BIOS vendor's updates and forums.
Sorry for the late reply.
Does anyone here use an HP laptop ?
Specifically this model: https://support.hp.com/in-en/document/c04919819#AbT1
This mentions FreeDOS under "Software" at the bottom of the page.
I have a very weird problem it seems. In my BIOS startup screen there seems to be no option like "Update BIOS".
The particular model I am using HP only publishes exe files that can be used from within Windows via which the BIOS update can happen within the OS.
They do not care about Linux. Hence my only option was to do the BIOS update from outside the OS. Now I can't find the option to update the BIOS from a USB.
I have contacted HP via their Community forum but I doubt that I will get a response.
In the meantime if anyone knows anything about this problem let me know, or what the best place would be to ask about this issue.
https://support.hp.com/ca-en/document/c00042629 suggests that you can create a BIOS update USB drive from a BIOS update .exe file using a different PC running Windows. Some .exe files run in freeDOS and generate a .bin file. Some HP laptops have "BIOS update from file" in the System Diagnostics (maybe press F2 while booting) with the .bin file on a FAT format USB key.
https://askubuntu.com/questions/539120/how-to-perform-a-hp-bios-upgrade-with... has a number of examples for differnet HP models.
Here is another link mentioning FreeDOS for updating bios: https://pingtool.org/bootable-dos-iso-bios-upgrade/
On Tue, Jul 21, 2020 at 12:16 PM Fred Erickson fredferickson@gmail.com wrote:
Here is another link mentioning FreeDOS for updating bios: https://pingtool.org/bootable-dos-iso-bios-upgrade/
Didn't work since HP does make MS-DOS executables. I guess this is only for Dell.
On Sun, Jul 26, 2020 at 5:12 PM Sreyan Chakravarty sreyan32@gmail.com wrote:
On Tue, Jul 21, 2020 at 12:16 PM Fred Erickson fredferickson@gmail.com wrote:
Here is another link mentioning FreeDOS for updating bios: https://pingtool.org/bootable-dos-iso-bios-upgrade/
Didn't work since HP doesn't make MS-DOS executables. I guess this is only for Dell.
On Tue, Jul 21, 2020 at 4:59 AM George N. White III gnwiii@gmail.com wrote:
On Mon, 20 Jul 2020 at 18:59, Sreyan Chakravarty sreyan32@gmail.com wrote:
On Wed, Jul 1, 2020 at 4:06 AM George N. White III gnwiii@gmail.com wrote:
In general, the earlier the mitigations are applied, the harder it is to exploit the bugs, and some mitigations can only be applied at the BIOS level, so you need to check your BIOS vendor's updates and forums.
Sorry for the late reply.
Does anyone here use an HP laptop ?
Specifically this model: https://support.hp.com/in-en/document/c04919819#AbT1
This mentions FreeDOS under "Software" at the bottom of the page.
I have a very weird problem it seems. In my BIOS startup screen there seems to be no option like "Update BIOS".
The particular model I am using HP only publishes exe files that can be used from within Windows via which the BIOS update can happen within the OS.
They do not care about Linux. Hence my only option was to do the BIOS update from outside the OS. Now I can't find the option to update the BIOS from a USB.
I have contacted HP via their Community forum but I doubt that I will get a response.
In the meantime if anyone knows anything about this problem let me know, or what the best place would be to ask about this issue.
https://support.hp.com/ca-en/document/c00042629 suggests that you can create a BIOS update USB drive from a BIOS update .exe file using a different PC running Windows. Some .exe files run in freeDOS and generate a .bin file. Some HP laptops have "BIOS update from file" in the System Diagnostics (maybe press F2 while booting) with the .bin file on a FAT format USB key.
https://askubuntu.com/questions/539120/how-to-perform-a-hp-bios-upgrade-with... has a number of examples for differnet HP models.
Well there was no "Update BIOS" option in my BIOS setup. I had to use Win + B to initiate the update.
On 7/1/20 4:05 AM, George N. White III wrote:
RedHat and other linux distros track Intel's efforts. Some of the mitigations require changes to the kernel. I'm sure many of the discussions around which mitigations and CPU's get priority are not public, but you can certainly open an issue at:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues
In general, the earlier the mitigations are applied, the harder it is to exploit the bugs, and some mitigations can only be applied at the BIOS level, so you need to check your BIOS vendor's updates and forums.
All distributions have access to the same microcode, but may make different decisions for what should be done in BIOS and when to implement kernel changes to support new microcode. Ubuntu Security Page for CVE-2020-0543 https://people.canonical.com/~ubuntu-security/cve/2020/CVE-2020-0543.html is well organized and may be helpful checking to see if new microcode is available for your CPU.
Okay, I have done everything that I can do from my side.
I have updated my BIOS to the latest one from HP's website.
I have updated the OS to the latest updates and patches.
But still the Meltdown OVH script tells me that I am vulnerable.
So my next question would be:
1) Do I open a bug at :
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues
or
bugzilla.redhat.com
or both ?
2) What info should I include ? I am obviously doing to include the output of /proc/cpuinfo, but is there anything else ?
3) Is there any other way to test if I am vulnerable ? The Meltdown OVH script maybe be buggy so any other way I can test ?
On Tue, 30 Jun 2020 21:25:01 +0530 Sreyan Chakravarty sreyan32@gmail.com wrote:
Except that this does not work. The meltdown ovh script still reports that my system is vulnerable.
I did a rebuild of my initramfs using:
dracut -f
Then rebooted and checked once again. No change. The vulnerability still exists.
Too bad, that would have been an easy win.
Thus, even if the mitigation is loaded, the system is still vulnerable at some level.
Would be great if I could be absolutely certain about this.
For now, saying that it works without verification, is just like wishful thinking for me.
Agreed.
There is nothing you can do beyond what you have done, though.
So is it confirmed this is a bug in the microcode ?
I don't think the original problem is a bug in the microcode, it is a flaw in the design of the CPU architecture. The microcode is supposed to fix that by mandating certain actions. Jonathon gave you some useful advice to see if the CPU you are using is included in the fix. I think I read that Intel is targeting later CPUs before earlier CPUs, so it might not have been released for your CPU model yet, but *you* should search and confirm if that is true. And Roger's suggestion that updating the firmware before applying the fix worked also deserves consideration, because it might be looking for specific markers before it will apply, and they might only be there in the latest update.
I don't know how the tool you are using to check functions, but it could be that it is seeing these additional vulnerabilities and reporting that your system is still vulnerable even though the mitigation is in place, and the worst vulnerabilities are protected.
Yeah, this all sounds great. But again, I have to be sure.
I don't want security to be a crystal ball.
Then you need to go to the source of the tool you are using to validate that the fix is working, and directly ask them if it can yield false negatives after the fix is applied. If it can't, you are still vulnerable. If it can, you don't know if the fix is applied or not.
An extreme measure you could take might be to buy a system with a CPU that is not vulnerable. The article mentions that they do exist, even some from Intel.
That's not very sensible when a fix already exists and is not working. Why should I pay extra for things that are suppose to be fixed in the code that actually advertises it fixes them ?
If you are using a commercially provided machine, you should be able to search for that specific machine to see if there are other people in your boat of looking for a fix, and if they have found one. And, you should be able to go to the website of the manufacturer of the machine and ask them as well. They have a monetary interest in having a fix available for their machines (it will be hard for them to sell machines that don't have a fix available).
On Tue, 30 Jun 2020 11:57:16 -0700 stan upaitag@zoho.com wrote:
On Tue, 30 Jun 2020 21:25:01 +0530 Sreyan Chakravarty sreyan32@gmail.com wrote:
So is it confirmed this is a bug in the microcode ?
I don't think the original problem is a bug in the microcode, it is a flaw in the design of the CPU architecture. The microcode is supposed to fix that by mandating certain actions. Jonathon gave you some useful advice to see if the CPU you are using is included in the fix. I think I read that Intel is targeting later CPUs before earlier CPUs, so it might not have been released for your CPU model yet, but *you* should search and confirm if that is true. And Roger's suggestion that updating the firmware before applying the fix worked also deserves consideration, because it might be looking for specific markers before it will apply, and they might only be there in the latest update.
In Intel's defense, they have to be very cautious with updating the microcode. I imagine that getting it wrong could have consequences up to and including bricking the machine. Or it could introduce another subtle vulnerability. This isn't something that's coded and thrown in over night.
On Wed, Jul 1, 2020 at 12:36 AM stan via users < users@lists.fedoraproject.org> wrote:
In Intel's defense, they have to be very cautious with updating the microcode. I imagine that getting it wrong could have consequences up to and including bricking the machine. Or it could introduce another subtle vulnerability. This isn't something that's coded and thrown in over night.
Ok just providing some closure.
It seems the microcode has been reverted back to its last stable version. Not sure if "last stable version" means protection against SRDBS or not.
It was done due to stability concerns identified by Intel.
Here are the updates from the Github issue:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/3...
No idea if this will be fixed at all.
On 2020-07-01 06:12, Sreyan Chakravarty wrote:
On 7/1/20 12:27 AM, stan via users wrote:
but*you* should search and confirm if that is true.
Opened an issue on github. Lets see what happens.
I'm guessing and thinking that since the microcode comes directly from Intel not much will happen.
On 7/1/20 4:03 AM, Ed Greshko wrote:
I'm guessing and thinking that since the microcode comes directly from Intel not much will happen.
Well I have opened an issue on Bugzilla and Github:
https://bugzilla.redhat.com/show_bug.cgi?id=1860693
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/3...
Nothing will probably happen, but hey we can dream can't we.
Sreyen:
I ran the scripts as you suggested and also got the
* CPU microcode is the latest known available version: NO
and went to my vendor's website (Dell, in my case) and found there was a new BIOS update, installed it, re-ran the tests and passed.
Is it possible that it is your firmware that needs an update?
On Sun, Jun 28, 2020 at 7:34 PM Sreyan Chakravarty sreyan32@gmail.com wrote:
Hi,
Well guys, its time to panic once again.
I just found out my system is vulnerable to the new Crosstalk vulnerability by running the popular Meltdown OVH script.
More about the vulnerability over here:
https://www.vusec.net/projects/crosstalk/
These exploits get worse each time, this one affects all cores.
This is how I tested for the vulnerability.
Downloaded spectre-meltdown-checker.sh via :
wget https://meltdown.ovh -O spectre-meltdown-checker.sh
and then just executed with sudo.
This is the output I got:
- SRBDS mitigation control is enabled and active: NO
STATUS: VULNERABLE (Your CPU microcode may need to be updated to mitigate the vulnerability)
CVE-2020-0543:KO
Full output here:https://pastebin.com/raw/hyfFBbaF
As you can see the tool specifies that my microcode is not the latest.
That being said, where do I find the latest microcode from ?
My OS is fully updated, and the firmware and microcode is also latest according to DNF:
$ sudo dnf update linux-firmware Dependencies resolved. Nothing to do. Complete!
$ sudo dnf update microcode_ctl Dependencies resolved. Nothing to do. Complete!
So where is the microcode update in Fedora for this ??
Canonical has already published microcode updates for this, as shown here:https://youtu.be/UR-5vAZ1cGg?t=1160
<rant> It kind of seems frustrating that a bleeding edge distro like Fedora still hasn't provided updates yet. While Ubuntu a distro that doesn't always use the latest software already has a fix. </rant>
What can I do now ? What is progress for Fedora ?
Will the microcode from Canonical work for Fedora ? Dumb question I know but I am desperate.
Let me know if any further info is required.
Some more info about my CPU:https://pastebin.com/raw/TNJS930F
What is everyone else in the community doing about this ?
Thanks.
-- Regards, Sreyan
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
The CPU firmware can be delivered either by the bios (install at post) or the firmware package (install at linux boot, only temporary for this boot and the specific kernels that have that firmware).
As noted before the firmware is put at the start of the initramfs and is loaded early in kernel startup, so if firmware is updated you would need to rebuild all initramfs'es to make sure all get the new firmware.
And at the end of the day the new firmware comes from Intel itself, and Intel has not been updating the older affected cpus, and some of the older affected cpus that are getting updates come much later than the newest cpus. And on top of that some of the firmware updates that have been released for a few days or weeks have caused fatal crashes from rare defects in the firmware, before the firmware update is pulled and fixed.
On Tue, Jun 30, 2020 at 9:15 AM Ted Roche tedroche@gmail.com wrote:
Sreyen:
I ran the scripts as you suggested and also got the
- CPU microcode is the latest known available version: NO
and went to my vendor's website (Dell, in my case) and found there was a new BIOS update, installed it, re-ran the tests and passed.
Is it possible that it is your firmware that needs an update?
On Sun, Jun 28, 2020 at 7:34 PM Sreyan Chakravarty sreyan32@gmail.com wrote:
Hi,
Well guys, its time to panic once again.
I just found out my system is vulnerable to the new Crosstalk vulnerability by running the popular Meltdown OVH script.
More about the vulnerability over here:
https://www.vusec.net/projects/crosstalk/
These exploits get worse each time, this one affects all cores.
This is how I tested for the vulnerability.
Downloaded spectre-meltdown-checker.sh via :
wget https://meltdown.ovh -O spectre-meltdown-checker.sh
and then just executed with sudo.
This is the output I got:
- SRBDS mitigation control is enabled and active: NO
STATUS: VULNERABLE (Your CPU microcode may need to be updated to mitigate the vulnerability)
CVE-2020-0543:KO
Full output here: https://pastebin.com/raw/hyfFBbaF
As you can see the tool specifies that my microcode is not the latest.
That being said, where do I find the latest microcode from ?
My OS is fully updated, and the firmware and microcode is also latest according to DNF:
$ sudo dnf update linux-firmware Dependencies resolved. Nothing to do. Complete!
$ sudo dnf update microcode_ctl Dependencies resolved. Nothing to do. Complete!
So where is the microcode update in Fedora for this ??
Canonical has already published microcode updates for this, as shown here: https://youtu.be/UR-5vAZ1cGg?t=1160
<rant> It kind of seems frustrating that a bleeding edge distro like Fedora still hasn't provided updates yet. While Ubuntu a distro that doesn't always use the latest software already has a fix. </rant>
What can I do now ? What is progress for Fedora ?
Will the microcode from Canonical work for Fedora ? Dumb question I know but I am desperate.
Let me know if any further info is required.
Some more info about my CPU: https://pastebin.com/raw/TNJS930F
What is everyone else in the community doing about this ?
Thanks.
-- Regards, Sreyan
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
-
Ed Greshko -
Fred Erickson -
George N. White III -
Jonathan Billings -
Roger Heflin -
Samuel Sieb -
Sreyan Chakravarty -
stan -
Ted Roche