> Which cloud is in use and what the instance type is?
This was seen on OVH. I don't think it's a public instance type. I
have attached the cpuid of the affected guest
(https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1973839/+attachment/5590542/+files/cpuid)
but unfortunately I don't detail
** Summary changed:
- 5.15.0-30-generic : unchecked MSR access error: WRMSR to 0x48 (tried to
write 0x0004)
+ 5.15.0-30-generic : SSBD mitigation results in "unchecked MSR access error:
WRMSR to 0x48 (tried to write 0x0004)" and flood of kernel traces
in some cloud pro
So after reading and experimenting a bit more, what the upstream change
is doing is setting the defaults to
spec_store_bypass_disable=prctl
spectre_v2_user=prctl
instead of "seccomp". This basically means that instead of all
seccomp() users setting these flags, it is up to userspace to set
manu
I have bisected this, and the commit that *fixes* this between the focal
kernel (5.15.0-30-generic) and the current 5.17 release is
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2f46993d83ff4abb310ef7b4beced56ba96f0d9d
x86: change default to spec_store_bypass_disa
I've made this confirmed, because the log collection (apport-collect
1973839) is hundreds of megabytes, as dmesg is full of the tracebacks
discussed
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Kernel
Packa
Public bug reported:
When booting this in one of our clouds, we see an error early in the
kernel output
kernel: unchecked MSR access error: WRMSR to 0x48 (tried to write
0x0004) at rIP: 0xabc90af4
(native_write_msr+0x4/0x20)
and then an un-ending stream of "bare" tracebacks
6 matches
Mail list logo
