Intel vulnerabilities discovered

[Head_on_a_Stick]

Yet more evidence that Intel are a bunch of clueless clowns: https://www.intel.com/content/www/us/en ... 00314.html

And Phoronix have noted a 58% performance hit for the Haswell generation when the patches are applied:

https://www.phoronix.com/scan.php?page= ... l-gen7-hit

FFS...

Security tracker: https://security-tracker.debian.org/tra ... 2019-14615

[neuraleskimo]

Yet more evidence that Intel are a bunch of clueless clowns: https://www.intel.com/content/www/us/en ... 00314.html

And Phoronix have noted a 58% performance hit for the Haswell generation when the patches are applied:

https://www.phoronix.com/scan.php?page= ... l-gen7-hit

Security tracker: https://security-tracker.debian.org/tra ... 2019-14615

I saw that. Disappointing is probably the best I can say. So far AMD has fared better, but what is your opinion of whether AMD is really doing better security or simply has other yet to be discovered bugs?

[Head_on_a_Stick]

what is your opinion of whether AMD is really doing better security or simply has other yet to be discovered bugs?

Well I'm no expert on the subject but the kernel developers seem to think AMD is a better option. From my (2nd generation) Ryzen laptop:

Code: Select all

empty@E485:~ $ grep -R . /sys/devices/system/cpu/vulnerabilities
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline, IBPB: conditional, STIBP: disabled, RSB filling
/sys/devices/system/cpu/vulnerabilities/itlb_multihit:Not affected
/sys/devices/system/cpu/vulnerabilities/mds:Not affected
/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
empty@E485:~ $

An Intel system wouldn't have as many "not affected" results.

Probably still worth disabling SMT for security-critical systems though, even for AMD. That's what OpenBSD does.

[neuraleskimo]

Well I'm no expert on the subject...

Maybe, but I still put some stock on your opinions.

Probably still worth disabling SMT for security-critical systems though, even for AMD. That's what OpenBSD does.

Agreed and good point. Plus for math-heavy code, disabling SMT can (and usually will) increase throughput (which is why I disable SMT).

[CwF]

Code: Select all

~#  grep -R . /sys/devices/system/cpu/vulnerabilities
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, STIBP: disabled, RSB filling
/sys/devices/system/cpu/vulnerabilities/mds:Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs barriers and __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI

OMG! No worries. I'm more concerned with execution across numa zones, socket to socket latency and the like. I think I can rely on Intel's quote "elevated privilege local user".

[Head_on_a_Stick]

https://cacheoutattack.com/

If I made a new thread for each new vulnerability the forums would be full of them so I'll just start appending them here...

[CwF]

https://software.intel.com/security-sof ... n-sampling

[Head_on_a_Stick]

A vulnerability has been found in the ROM of the Intel Converged Security and Management Engine (CSME):

http://blog.ptsecurity.com/2020/03/inte ... trust.html

The problem is not only that it is impossible to fix firmware errors that are hard-coded in the Mask ROM of microprocessors and chipsets. The larger worry is that, because this vulnerability allows a compromise at the hardware level, it destroys the chain of trust for the platform as a whole.

CVE-2019-0090

^ That name of the CVE shows that Intel have known about this since last year...

Debian bug tracker: https://security-tracker.debian.org/tra ... -2019-0090

No mitigations yet.

[Hallvor]

Not good, but doesn't it require physical access?

[Head_on_a_Stick]

doesn't it require physical access?

That's right, yes.

[Head_on_a_Stick]

Load Value Injection

More side-channel madness from everybody's favourite crappy CPU manufacturer, yay!

https://software.intel.com/security-sof ... -injection

https://cve.mitre.org/cgi-bin/cvename.c ... -2020-0551

Intel users should brace themselves for a substantial and significant performance hit once the new mitigations (not fixes) are rolled out.