Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[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: [Select]

#!/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

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]

<Sigh> 

<snip>

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

<snip>

<Sigh> 

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/
 

[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.

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.

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

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.

[dee.jay]

So its a HUGE problem for data centres

Can confirm - Heartbleed and Spectre were a pain - but luckily after all the microcode updates it didn't slow our systems down too much. Luckily it's not too much of a ballache to update things like Cisco UCS.

However, we have shutdown 5 of our colo's that we had.... down to the last one now

[burakkucat]

b*cat smiles at the responses to his musing --

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

-- and appreciates that he did not word that as precisely as he intended. 

So here is try number two --

If only there were laptop computer hardware available, with ARM CPUs, without any OS installed there upon.

I am very particular as to the OS that I use. 

With my activities elsewhere, I do have access to  link one and link two. 

[meritez]

@burakkucat

would Debian be an issue?

https://shop.mntmn.com/products/mnt-reform

[burakkucat]

would Debian be an issue?

https://shop.mntmn.com/products/mnt-reform

Hmm . . . Thank you for the link. Something to consider if I was not already using new hardware with an AMD processor.

[Chrysalis]

Thank you for the script.

[burakkucat]

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

I have two systems currently running linux-5.19-rc8 with the retblead mitigation code operational. That code has already been backported to the linux-5.18.Y branch, as my opening post shows. The system I am currently using is running linux-5.18.14

Thank you for the script.

You're welcome.

[johnson]

-- and appreciates that he did not word that as precisely as he intended. 

Heh, I was at least being facetious. I do wonder about situations where the risk would be minimal to have `mitigations=off` though, anything running a web browser is out I guess, but a home server? Where do you draw the line with trust of executing code? Have there been good examples in the wild of spectre/meltdown and co?

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.

I did not know the efforts to run linux on apple silicon had come so far!

[Alex Atkin UK]

Heh, I was at least being facetious. I do wonder about situations where the risk would be minimal to have `mitigations=off` though, anything running a web browser is out I guess, but a home server? Where do you draw the line with trust of executing code? Have there been good examples in the wild of spectre/meltdown and co?

A web server should never be running code submitted from the clients, all input should be sanitised to avoid that.
If you aren't, you're already at risk of privilege escalation attacks so the mitigations become kinda moot at that point.

I mean sure, technically in that case it would be easier, but its rather like putting a bolt on your bedroom door to prevent people entering your home - but leaving the perimeter doors wide open.  You don't need that bolt if you keep the perimeter secure and its not going to do much if they already ransacked the rest of your house.

[burakkucat]

I do wonder about situations where the risk would be minimal to have `mitigations=off` though, anything running a web browser is out I guess, but a home server?

My feeling is that "mitigations=off" would only be sensible for a system that is not networked. I.e. it runs in total isolation from the rest of the world (and your LAN). But that's my view. Others will have different opinions. 

[Alex Atkin UK]

My feeling is that "mitigations=off" would only be sensible for a system that is not networked. I.e. it runs in total isolation from the rest of the world (and your LAN). But that's my view. Others will have different opinions. 

I have mitigations off on pfSense as Netgate staff themselves as I recall concurred that its a completely unnecessary performance hit.

My guess is they include the toggle as it would be necessary when running in a VM and some people are just plain paranoid, even though if someone was able to run code in the first place you're already screwed.

Its one reason I don't understand OPNsense being based on hardened BSD.  The cynic in me suspects its just so they can claim something over pfSense.

I do have the mitigations on AFAIK on all my Linux boxes as I have all high-end hardware so not concerned about the performance impact.  I'm more concerned with my VPS.

Code: [Select]

Kernel -- 3.10.0-957.27.2.el7.x86_64

l1tf -- Mitigation: PTE Inversion
mds -- Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
meltdown -- Mitigation: PTI
spec_store_bypass -- Vulnerable
spectre_v1 -- Mitigation: Load fences, __user pointer sanitization
spectre_v2 -- Vulnerable: Retpoline without IBPB