You are not logged in.
Are there actually even any exploits that can take advantage of this vulnerability?
I mean, I get that we have to patch, and that we'll incur a hit on performance, but I'm just curious.
Also, anyone else run BL virtualized? I've noticed that post-patch, my user experience is very significantly degraded, regardless if I use my macbook or windows machine as the virtual host.
Offline
That's bad, right?
what does it mean?
Check the PDF, it is colour-coded with a key.
Both 0x4 and 0x29 are marked as "Pre-Mitigation Production MCU" which is described thusly:
For products that have not yet released a Production MCU with mitigations for Variant 2 (Spectre), Intel recommends using this version of MCU. This does not impact mitigations for Variant 1 (Spectre) and Variant 3 (Meltdown).
The "Production Status" is "Planning" so a fix is pending (I think).
anyone else run BL virtualized?
I'm running my test system with QEMU/KVM and it seems as fast as ever tbh, I keep forgetting that it's virtualised
Offline
I am running Bunsenlabs on a Surface Pro IV through Virtualbox 5.2.6. CPU usage seems to be higher and tends to spike more quickly. Typing through the Surface Pro IV seems to be very expensive, shooting CPU usage up to 60% or so. I am not sure why typing would have that effect but it does. Also, I have to rebuild the VirtualBox guest additions kernel modules on every boot. I am not sure what I am missing that is causing that.
Offline
I have to rebuild the VirtualBox guest additions kernel modules on every boot. I am not sure what I am missing that is causing that.
virtualbox-dkms — try the stretch-backports version (with the backported virtualbox package), security issues prevented it from making the release, IIRC.
Also, have you seen https://qemu.weilnetz.de/w64/? (If you have a Windows host)
Last edited by Head_on_a_Stick (2018-02-09 22:21:34)
Offline
Backporting the VirtualBox kernel modules seems to have helped considerably. I am now able to type with the CPU sitting at around 15% or so with no spiking.
Offline
Arch now has the IBPB fix but Alpine still has just the retpoline protection.
We now seem to have some Spectre V1 mitigation in place as well:
alpine:~$ grep -r . /sys/devices/system/cpu/vulnerabilities/
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable: Minimal generic ASM retpoline
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
alpine:~$
What does an updated BunsenLabs system have to say for itself?
Offline
^
john@helium-dev:~$ grep -r . /sys/devices/system/cpu/vulnerabilities/
grep: /sys/devices/system/cpu/vulnerabilities/: No such file or directory
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
^ Thanks!
I think stevep mentioned that only the newer kernels have a vulnerabilities folder in /sys so I think that is expected.
Have you tried the vulnerability checker script?
https://github.com/speed47/spectre-meltdown-checker
Is anybody running the backported kernel? I think that should expose it's vulnerabilities in sysfs (so to speak).
At any rate, firefox-esr can't be used as an attack vector so it's only the Chrome users at risk... ]:D
Offline
Debian have uploaded the vulnerability check script to the testing/unstable repositories, with a version in stretch-backports
The .deb should be installable in Hydrogen/Deuterium:
http://cdn-aws.deb.debian.org/debian/po … +1_all.deb
Run it with:
sudo spectre-meltdown-checker
Offline