Computer Software > Linux

"retblead". The Latest CPU Vulnerability.

(1/6) > >>

burakkucat:
<Sigh>  :(

Just like Linus Torvalds, I had exclusively used systems with Intel CPUs for many years but around 18 months ago we both switched to using systems with AMD CPUs. (If only there were laptop computers using ARM CPUs.)

So this latest vulnerability had me modify my "check-vuln" utility, a simple script, which I share below --


--- Code: ---#!/bin/bash

VULNDIR=/sys/devices/system/cpu/vulnerabilities
GOTOCOL="^[[19G"

echo -en "Kernel${GOTOCOL} -- "
uname -r
echo ""

if [ -d $VULNDIR ]; then
pushd $VULNDIR > /dev/null

for ENTRY in *; do
echo -en "${ENTRY}${GOTOCOL} -- "
cat $ENTRY
done

popd > /dev/null
fi

echo ""

exit 0

--- End code ---

Here is the output from a system running the previous Linux kernel (-5.18.13) --

Kernel             -- 5.18.13

itlb_multihit      -- Not affected
l1tf               -- Not affected
mds                -- Not affected
meltdown           -- Not affected
mmio_stale_data    -- Not affected
spec_store_bypass  -- Mitigation: Speculative Store Bypass disabled via prctl
spectre_v1         -- Mitigation: usercopy/swapgs barriers and __user pointer sanitization
spectre_v2         -- Mitigation: Retpolines, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling
srbds              -- Not affected
tsx_async_abort    -- Not affected

and here is the output from the same system running the current Linux kernel (-5.18.14) --

Kernel             -- 5.18.14

itlb_multihit      -- Not affected
l1tf               -- Not affected
mds                -- Not affected
meltdown           -- Not affected
mmio_stale_data    -- Not affected
retbleed           -- Mitigation: untrained return thunk; SMT disabled
spec_store_bypass  -- Mitigation: Speculative Store Bypass disabled via prctl
spectre_v1         -- Mitigation: usercopy/swapgs barriers and __user pointer sanitization
spectre_v2         -- Mitigation: Retpolines, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling
srbds              -- Not affected
tsx_async_abort    -- Not affected

A simple "diff" shows --

1c1
< Kernel           -- 5.18.13
---
> Kernel           -- 5.18.14
7a8
> retbleed         -- Mitigation: untrained return thunk; SMT disabled

<Sigh>  :(

Jaggies:

--- Quote from: burakkucat on July 25, 2022, 06:37:58 PM ---<Sigh>  :(

<snip>

(If only there were laptop computers using ARM CPUs.)

<snip>

<Sigh>  :(

--- End quote ---

Like these, you mean?

https://www.riscoscomputers.co.uk/Pinebok.shtml

meritez:
Or the Pinebook Pro:
https://pine64.com/product-category/laptops/

Or an ARM Chromebook, which is just a heavily modified Gentoo chroot.

Or Purism Librem

johnson:
Or these:
https://www.apple.com/uk/macbook-pro/
 :D

Alex Atkin UK:
To be fair, its my understanding speculative execution attacks are only useful if the user can run software on the box.  So its a HUGE problem for data centres but not really an issue for home use unless you're running dodgy software.

Retbleed fix is supposed to be in kernel 5.19 but only for 64bit builds.

--- Quote ---The mitigations for RETBleed are currently ineffective on x86_32 since entry_32.S does not use the required macros. However, for an x86_32 target, the kconfig symbols for them are still enabled by default and /sys/devices/system/cpu/vulnerabilities/retbleed will wrongly report that mitigations are in place.
--- End quote ---


--- Quote from: johnson on July 26, 2022, 10:36:34 AM ---Or these:
https://www.apple.com/uk/macbook-pro/
 :D

--- End quote ---

I'm using Asahi Linux exclusively on my Mac Mini now over tigervnc.  Its absolutely insane how responsive it is.

Even on Macbook Pro its fast despite the lack of GPU acceleration.  Main drawback is the speakers aren't working yet as they need to figure out the right values for the amp to avoid blowing them as in MacOS it cuts back the bass past around 50%, plus the touchpad doesn't work very well.  I guess a lot of the magic of how well their touchpads work must be in the drivers.

In MacOS itself I just had my Macbook Pro mostly in sleep mode on battery for over two weeks with 30% battery left.  I guess that makes sense given it based off a smartphone SoC but still, it kinda blows my mind.  Although I have no idea what x86 Macbooks were like, I get the feeling they were fairly good in sleep mode too.

Navigation

[0] Message Index

[#] Next page