Intel's continued security meltdown, MDS edition:

[Chris Laprise]

From Kim Zetter at the New York Times:

https://twitter.com/KimZetter/status/1194374230109868032

> When Intel released patch for CPU vulns last May, it said the patch fixed all the vulns. But researchers at @vu5ec
> say this isn't true and Intel knew it. Intel asked them not to disclose this and to alter conf. paper about the vulns.

> “We think it’s time to simply tell the world that even now Intel hasn’t fixed the problem,” Herbert Bos (@herbertbos
> ) says. “There are tons of vulnerabilities still left, we are sure. And they don’t intend to do proper security engineering until their reputation is at stake.”

https://www.nytimes.com/2019/11/12/technology/intel-chip-fix.html

https://mdsattacks.com/

-

Its worth noting that the lion's share of these vulns are
vendor-specific to Intel. I have long held the position that
Spectre+Meltdown showed AMD x86 to be "substantially" better engineered
with respect to security; I now believe that assessment to be an
understatement.

Competition between Intel and AMD is very asymmetrical, as the former
amounts to a monopoly and the latter is the only one that feels acute
competitive pressure (and hence, AMD has felt a greater need to engineer
responsibly). OTOH, Intel has maintained their position with lazy
engineering shortcuts, rigged benchmarks, and anti-competitive threats
lodged against PC makers. For their threats, the company even announced
it will refuse to pay a hefty EU judgment against them. That is the
"merit" in how they maintain dominance.

Even though I greatly favor the development and promotion of open source
hardware (including CPUs), there are no open alternatives for Qubes
users in the short-mid term. So recognizing that open source is not a
singular guiding principle – that competition is vitally important for
the availability of desirable and safe products – I think it would be
best if the Qubes project and community recognized the situation and
made a modest effort to certify AMD hardware as a safer alternative to
Intel.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Claudia]

Chris Laprise:

Thanks for the info. As you may remember, I recently switched to AMD
just for cost reasons.

The problem is, it's hard enough to find an Intel machine that runs
Qubes well, let alone an AMD machine. I know conventional wisdom says
AMD is about equal to Intel in terms of compatibility, but lately I'm
starting to question that.

Aside from the fact that Intel is more widely used and tested, here are
a couple of specific examples I've come across.



https://www.mail-archive.com/qubes...@googlegroups.com/msg29776.html

This user has a mid-range business class Ryzen laptop which experienced
a lot of the same problems as my low-end consumer Ryzen laptop with the
same processor. The kernel complains of ACPI problems and firmware bugs.
Sys-usb doesn't work, possibly due to the way USB controllers are
grouped on AMD's IOMMU implementation. And suspend/resume doesn't work
right, although that's not uncommon for any machine.



https://www.mail-archive.com/qubes...@googlegroups.com/msg31199.html

This is an issue I ran into with the amdgpu driver, where I found that
Xen has an Intel-specific option for disabling the IOMMU for the
integrated graphics device, but no AMD-equivalent option. (I don't know
if that's the actual problem, I'm just saying it's an Intel-specific
option, of which there are several.)



https://www.mail-archive.com/qubes...@googlegroups.com/msg31512.html

Here I discovered a problem with IOMMU grouping which seems to be common
on Ryzen processors and perhaps AMD systems in general. The USB
controllers are in the same group as the GPU, SATA controller, and audio
devices. So when I try to assign USB controllers to sys-usb, everything
stops working.


https://www.mail-archive.com/qubes...@googlegroups.com/msg31515.html

Here a user points out that many AMD processors slightly change their
feature set (cpuinfo) after a suspend/resume cycle, which causes Xen to
panic due to Spectre/Meltdown mitigation. Not sure where Intel stands on
this.


While there may be security benefits to AMD, I think there are also some
compatibility gotchas to watch out for. You're already taking your life
in your own hands when you install Linux, especially a
hardware-sensitive distro like Qubes. The last thing you probably want
to throw into the mix is a second-place CPU vendor. I just don't know if
Qubes on AMD is quite ready for primetime.

-------------------------------------------------
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!