You are not logged in.
Hello, I'm a new linux user and have recently decided to download arch and experiment as much as I can since i'm going through the site (https://linuxjourney.com/lesson/arch-linux) and the first module section 9 stated "f you want a lightweight operating system and really want to understand Linux use Arch! There’s a bit of a learning curve, but for the hardcore Linux users, this is a great choice."
So here I am. I've installed arch and i'm still on the tty shell cause I'm now going through (https://wiki.archlinux.org/title/Genera … mendations) 1.1 is done and i've managed to setup another administrator account in the wheel group and setup sudo. And so far going through the wiki i've learned some stuff, about GRUB ect.
I'm now in the 1.2 section (Security - https://wiki.archlinux.org/title/Security). And under the 3.2 section I have stumbled across a problem with my CPU. There seems to be two vulnerabilites on my CPU that i'm not really worried about but more exicted about cause I see this as a learning opportunity. I've followed the wiki "Some CPUs contain hardware vulnerabilities. See the kernel documentation on hardware vulnerabilities for a list of these vulnerabilities, as well as mitigation selection guides to help customize the kernel to mitigate these vulnerabilities for specific usage scenarios.
To check if you are affected by a known vulnerability, run the following:
$ grep -r . /sys/devices/system/cpu/vulnerabilities/"
And this is what has come up. See Picture(2).
I've installed microcode, and i've set it up with section 1.2.2.2 "GRUB
grub-mkconfig will automatically detect the microcode update and configure GRUB appropriately. After installing the microcode package, regenerate the GRUB configuration to activate loading the microcode update by running:
# grub-mkconfig -o /boot/grub/grub.cfg"
After restart, I seem to have the same issue. After further investigation my CPU is discontinued and I believe there is no support for this CPU anymore, I can not find any drivers on intels website anymore.
Source: (https://www.intel.com/content/www/us/en … tions.html)
I'm not really worried, but should I skip this section for now, or should I be worried? Also the wiki tells me that "According to the researchers Retbleed mitigations require extensive changes to the system which results in up to 14% and 39% performance loss on Linux for affected AMD and Intel CPU respectively"
Source: (https://en.wikipedia.org/wiki/Retbleed)
Also, if I ever plan on hosting on apache or whatever cause my goal is to be able to use, and program in linux and be efficient and know as much I can about linux then setup my own website in the future. Would this vuln be a big problem for me?
Thanks for the help in advance.
Picture (1) - Information about CPU
https://i.imgur.com/wxfPWjz.png
Picture(2) - CPU VULN
https://i.imgur.com/pO8VrhC.png
Last edited by nabie (2024-02-01 00:09:21)
Offline
Discontinued on intels page only means you won't be buying new hardware that still contains this CPU, software wise these CPUs are definitely still supported and will get software fixes as the need arises.
Check whether the microcode is applied in the first place, what's your output for
cat /proc/cmdline
sudo dmesg | grep -i microcodeand post these here in code tags as text rather than images of text.
That said most of these vulnerabilities are really not that huge of a concern for a private system you're using for your own usecases. They are primarily a huge problem for Cloud providers and the like as these vulns could lead to secrets getting leaked accross VM boundaries.
Offline
Discontinued on intels page only means you won't be buying new hardware that still contains this CPU, software wise these CPUs are definitely still supported and will get software fixes as the need arises.
Check whether the microcode is applied in the first place, what's your output for
cat /proc/cmdline sudo dmesg | grep -i microcodeand post these here in code tags as text rather than images of text.
That said most of these vulnerabilities are really not that huge of a concern for a private system you're using for your own usecases. They are primarily a huge problem for Cloud providers and the like as these vulns could lead to secrets getting leaked accross VM boundaries.
Tried both commands, got output for the first command. Second command did not give me anything. Just a blank output.
[bearpoo@Bear ~]$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-linux
root=UUID=5c1ec64b-4484-428f-85fb-75a30ce83bfc rw loglevel=3 quiet[bearpoo@Bear ~]$ sudo dmesg | grep -i microcode
[bearpoo@Bear ~]$Offline
What is the output of pacman -Qi intel-ucode ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
What is the output of pacman -Qi intel-ucode ?
This is what it outputs.
[bearpoo@Bear ~]$ sudo pacman -Qi intel-ucode
Name : intel-ucode
Version : 20231114-1
Description : Microcode update files for Intel CPUs
Architecture : any
URL : https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files
Licenses : custom
Groups : None
Provides : None
Depends On : None
Optional Deps : None
Required By : None
Optional For : None
Conflicts With : None
Replaces : microcode_ctl
Installed Size : 7.03 MiB
Packager : T.J. Townsend <blakkheim@archlinux.org>
Build Date : Tue Nov 14 17:33:02 2023
Install Date : Mon Jan 29 18:08:37 2024
Install Reason : Explicitly installed
Install Script : No
Validated By : SignatureOffline
And, as a sanity check, the output of journalctl -b | grep microcode ???
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
Offline
"SMT Host state unknown" The kernel is running in a VM and can the hosts SMT state is unknown. Only the host can update microcode.
Offline
And, as a sanity check, the output of journalctl -b | grep microcode ???
This gives me a blank output.
Offline
I have done this, and it gives me this output
[bearpoo@Bear ~]$ modprobe cpuid
[bearpoo@Bear ~]$ bsdtar -Oxf /boot/intel-ucode.img | iucode_tool -tb -lS -
iucode_tool: system has processor(s) with signature 0x000906ea
microcode bundle 1: (stdin)
selected microcodes:
001/199: sig 0x000906e9, pf_mask 0x2a, 2023-02-23, rev 0x00f4, size 108544
001/200: sig 0x000906ea, pf_mask 0x22, 2023-02-23, rev 0x00f4, size 104448
001/201: sig 0x000906eb, pf_mask 0x02, 2023-02-23, rev 0x00f4, size 106496
001/202: sig 0x000906ec, pf_mask 0x22, 2023-02-23, rev 0x00f4, size 105472
001/203: sig 0x000906ed, pf_mask 0x22, 2023-02-27, rev 0x00fa, size 106496
[bearpoo@Bear ~]$ ^C
[bearpoo@Bear ~]$ Also, section 1 and followed the paragraph "To acquire updated microcode, depending on the processor, install one of the following packages:
* intel-ucode for intel processors."
Also section 1.2.2.2
With the command
grub-mkconfig -o /boot/grub/gurb.cfgOffline
"SMT Host state unknown" The kernel is running in a VM and can the hosts SMT state is unknown. Only the host can update microcode.
This is a VM, I'm sorry if I did notemphasize this. A picture was included in the first post. I'm guessing from your answer I should just move on in my machine and continue setup my arch setup and continue reading the arch wiki?
Offline
This is a VM, I'm sorry if I did notemphasize this. A picture was included in the first post. I'm guessing from your answer I should just move on in my machine and continue setup my arch setup and continue reading the arch wiki?
You can remove the intel-ucode package as it can not be used in a VM. You may also be able to remove linux-firmware unless the host is passing devices through to the guest. With respect to applying microcode apart from the host it can also be done by the firmware. With respect to the vulnerabilities my view is this being a VM reinforces V1del's point that they are probably not relevant to your use case.
Offline
nabie wrote:This is a VM, I'm sorry if I did notemphasize this. A picture was included in the first post. I'm guessing from your answer I should just move on in my machine and continue setup my arch setup and continue reading the arch wiki?
You can remove the intel-ucode package as it can not be used in a VM. You may also be able to remove linux-firmware unless the host is passing devices through to the guest. With respect to applying microcode apart from the host it can also be done by the firmware. With respect to the vulnerabilities my view is this being a VM reinforces V1del's point that they are probably not relevant to your use case.
I see, this might be something i'll look into if I ever decide to go bare metal. For now I can continue learn more about linux and setup my machine and go through the wiki further and test out new things. So i'll just let the packages be on the machine for the time being.
Thanks everyone for reaching out and helping me with my problem.
Offline