Public bug reported:
I've noticed that
`/sys/devices/system/cpu/vulnerabilities/gather_data_sampling` had the
`Vulnerable` value despite keeping the system up-to-date. The mitigation
microcode is available but not used. It seems that the issue might be
the way the operations are ordered during start-up: verdict on the
mitigation is potentially made before the microcode is loaded (as far as
I understand).
In any case, I don't know why my system doesn't have the mitigation
enabled. I would expect this to be taken care of by default during
security updates or setup.
```bash
grep -o 'microcode[^ ]* [^ ]*' /proc/cpuinfo | sort -u
```
reports: `microcode : 0xbe`
```bash
dmesg | grep -i microcode
```
reports (notice the timestamps):
```
[ 0.466934] microcode: Current revision: 0x000000be
[ 0.466942] microcode: Updated early from: 0x00000086
```
while
```bash
dmesg | grep -i -E 'gds|mitigat'
```
reports (notice the timestamps):
```
[ 0.083727] mitigations: Enabled attack vectors: user_kernel, user_user,
guest_host, guest_guest, SMT mitigations: auto
[ 0.083733] Speculative Store Bypass: Mitigation: Speculative Store Bypass
disabled via prctl
[ 0.083735] Spectre V2 : Mitigation: Enhanced / Automatic IBRS
[ 0.083737] ITS: Mitigation: Aligned branch/return thunks
[ 0.083739] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user
pointer sanitization
[ 0.083747] Spectre V2 : mitigation: Enabling conditional Indirect Branch
Prediction Barrier
[ 0.083750] GDS: Vulnerable
[ 0.083756] Spectre V2 : Spectre BHI mitigation: SW BHB clearing on syscall
and VM exit
```
```bash
rdmsr -0 0x10a
```
outputs `000000000a005c6b`
```bash
rdmsr -0 0x123
```
outputs `0000000000000010`
Let me know if you need more diagnostic listings, I'm happy to provide
whatever's needed.
A LLM has provided the following temporary fix - using a systemd service:
```
# /etc/systemd/system/gds-reenable.service
[Unit]
Description=Re-enable Intel GDS mitigation
After=multi-user.target
[Service]
Type=oneshot
ExecStart=/usr/sbin/modprobe msr
ExecStart=/usr/sbin/wrmsr -a 0x123 0
[Install]
WantedBy=multi-user.target
```
I've also checked the effect of setting the value of the MSR 0x123
register to 0 using a C program (source provided by the LLM) that makes
many calls to `_mm256_i32gather_epi32`. There is indeed a noticeable
difference in time: ~29ns/call with the value `0` vs ~15ns with the
value `0x10`, which I'm assuming is proof that the mitigation is enabled
whenever the MSR 0x123 register is set to 0 (instead of 0x10).
** Affects: ubuntu
Importance: Undecided
Status: New
** Tags: gds microcode
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2172675
Title:
Boot ordering: GDS mitigation status set earlier than microcode is
updated
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/2172675/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
