Print

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

[burakkucat]

If the output that you have shown is from your VPS then I would share your concern.    I see it is RHEL7 or one of the clones . . .

I've just checked a few remote systems that my "paws will reach".

One RHEL7 --

Kernel             -- 3.10.0-1160.71.1.el7.x86_64

itlb_multihit      -- Not affected
l1tf               -- Not affected
mds                -- Not affected
meltdown           -- Not affected
spec_store_bypass  -- Vulnerable
spectre_v1         -- Mitigation: Load fences, usercopy/swapgs barriers and __user pointer sanitization
spectre_v2         -- Mitigation: Full retpoline, IBPB
srbds              -- Not affected
tsx_async_abort    -- Not affected

One RHEL8 --

Kernel             -- 4.18.0-372.16.1.el8_6.x86_64

itlb_multihit      -- Not affected
l1tf               -- Not affected
mds                -- Not affected
meltdown           -- Not affected
spec_store_bypass  -- Vulnerable
spectre_v1         -- Mitigation: usercopy/swapgs barriers and __user pointer sanitization
spectre_v2         -- Mitigation: Retpolines, IBPB: conditional, STIBP: disabled, RSB filling
srbds              -- Not affected
tsx_async_abort    -- Not affected

And one RHEL9 --

Kernel             -- 5.14.0-70.17.1.el9_0.x86_64

itlb_multihit      -- Not affected
l1tf               -- Not affected
mds                -- Not affected
meltdown           -- Not affected
spec_store_bypass  -- Vulnerable
spectre_v1         -- Mitigation: usercopy/swapgs barriers and __user pointer sanitization
spectre_v2         -- Mitigation: Retpolines, IBPB: conditional, STIBP: disabled, RSB filling
srbds              -- Not affected
tsx_async_abort    -- Not affected

There's no mention of "retblead" as RH have not yet released kernels with the necessary code backported. 

[Alex Atkin UK]

My main VPS is stuck on CentOS 7 as its on a legacy contract so ordering a new VPS would cost twice as much.

This is the problem with hosting your own e-mail and not wanting downtime I guess.

[Chrysalis]

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.

OPNSense have parted ways with them now, I dont know when that takes affect but it has actually been announced, bear in mind HBSD is much more than kernel memory exploit mitigations, FreeBSD do seem a bit lax in their approach to security so I can understand why it exists.   I too disable the mitigations on my firewall as its a local access only box, the risk is going to be from running untrusted code which wont be the case on a firewall.

You can still disable the mitigations on OPNSense but has to be done the normal way via boot loader tunables.

[Weaver]

Forgive my ignorance, but how are the mitigation fixes implemented on existing kit, without redesigning the silicon?

[Chrysalis]

Forgive my ignorance, but how are the mitigation fixes implemented on existing kit, without redesigning the silicon?

They mitigated by sacrificing performance, a lot of the vulnerabilities are linked in some way to branch prediction performance enhancing features, so I think they disable those features (partially) to mitigate.  Spectre I think never got fully mitigated as the performance hit would just be way too much, instead the patches just restrict it on kernel code which is deemed the most risky.

[burakkucat]

Ideally one hopes to see "Not affected" for each vulnerability. Failing that, "Mitigation: <blah>. If one sees more than one "Vulnerable", one should regard the CPU as junk. 

[Weaver]

Sorry, no I meant to ask how is the mitigation injected into the CPU ? That would perhaps be a clearer term to use.

[Chrysalis]

Sorry, no I meant to ask how is the mitigation injected into the CPU ? That would perhaps be a clearer term to use.

Microcode updates which can be done either via bios updates or via the OS loading the microcode on boot.  Not all mitigations are put directly into the CPU though some are just done via OS patches, or even just browser patches.

[Alex Atkin UK]

They mitigated by sacrificing performance, a lot of the vulnerabilities are linked in some way to branch prediction performance enhancing features, so I think they disable those features (partially) to mitigate.  Spectre I think never got fully mitigated as the performance hit would just be way too much, instead the patches just restrict it on kernel code which is deemed the most risky.

retbleed sounds quite bad if that SMT disabled is what it sounds like.  Halving the number of threads your CPU can execute can leave I think 25% of performance on the table.

[Weaver]

What is the two hardware threads per core thing called - hyperthreading? In my experience it’s worth about 10 - 30% but it depends on how much contention there is for shared resources - microcode ops that need say mul (made up old example ). Also it depends on the amount of time certain things arise where one thread is stuck waiting on something such as a read from RAM.

[Alex Atkin UK]

Yeah SMT == HT, AMD (the industry in general) calls it the former with Intel branding it the latter.

When the difference between some CPUs is SMT support or not, it would be really frustrating to have it disabled.

[johnson]

As if by magic:
https://lore.kernel.org/lkml/CAHk-=wgrz5BBk=rCz7W28Fj_o02s0Xi0OEQ3H1uQgOdFvHgx0w@mail.gmail.com/T/#u

On a personal note, the most interesting part here is that I did the
release (and am writing this) on an arm64 laptop. It's something I've
been waiting for for a _loong_ time, and it's finally reality, thanks
to the Asahi team. We've had arm64 hardware around running Linux for a
long time, but none of it has really been usable as a development
platform until now.

So you are in good company Alex.

[Alex Atkin UK]

Sweet.