
Intel hit with 32 lawsuits over security flaws - mozumder
https://www.reuters.com/article/us-cyber-intel-lawsuit/intel-hit-with-32-lawsuits-over-security-flaws-idUSKCN1G01KX
======
digitalni
Am I the only one who thinks that now would be a good time to buy intel
shares, or even wait a bit more until these suits are won (intel will likely
lose), so the stock price will go down even further. There is no way intel
will lose its market position, so stock prices are likely to go back up after
all this drama settles down...

~~~
gnarbarian
>There is no way intel will lose its market position

Famous last words if I ever heard them. Ryzen and threadripper are a
significant threat especially knowing that AMD is not vulnerable to meltdown
(only Spectre).

~~~
SteveNuts
I was due for an upgrade, this time I got an AMD Ryzen 1800x.

First time I've EVER bought an AMD product, and I'm definitely impressed.

~~~
danieldk
But the large margins are in Xeons for enterprise and HPC computing. We use
high-end Xeon machines for research and would think twice before purchasing
AMD. Besides a generally good reputation and good performance, Intel has a
great ecosystem with Intel MKL, ICC, etc.

Besides that, Spectre also affects AMD and many ARM CPUs.

~~~
tomxor
> We use high-end Xeon machines for research and would think twice before
> purchasing AMD

Ryzen supposedly have a price-performance benefit over Xeons for multi-
threaded workloads.

What would you say the main reasons for staying with Xeons are for your type
of research? Is single threaded performance intrinsic to the type of
computation your research requires? or do those optimised math libraries you
mentioned bring so much practical benefit as to outweight any current raw
price-performance differences?

Soz, lots of questions, was just interested in how it applies to HPC based
research in reality.

~~~
marmaduke
At least my case, our compute servers are 4 dual Xeon servers in a 2U format,
sold by Dell. I haven’t yet found any vendor with the same core density based
on AMD.

~~~
theevilsharpie
Supermicro blows AMD out of the water when it comes to density.

Here's equivalent 4 node in 2U AMD systems (they differ based on disk
configuration -- SAS, NVME, or a mix of both). They also support Supermicro
SIOM, so you can choose what integrated networking you want:

[http://www.supermicro.com/Aplus/system/2U/2123/AS-2123BT-
HNC...](http://www.supermicro.com/Aplus/system/2U/2123/AS-2123BT-HNC0R.cfm)

[http://www.supermicro.com/Aplus/system/2U/2123/AS-2123BT-
HNR...](http://www.supermicro.com/Aplus/system/2U/2123/AS-2123BT-HNR.cfm)

[http://www.supermicro.com/Aplus/system/2U/2123/AS-2123BT-
HTR...](http://www.supermicro.com/Aplus/system/2U/2123/AS-2123BT-HTR.cfm)

If you wanted even more density, there's the MicroCloud and MicroBlade series
(although they use Intel processors):

[https://www.supermicro.com/products/MicroBlade/](https://www.supermicro.com/products/MicroBlade/)

[https://www.supermicro.com/products/nfo/MicroCloud.cfm](https://www.supermicro.com/products/nfo/MicroCloud.cfm)

That being said, these don't make a lot of sense unless you're very space-
constrained, or your racks have a ton of power available. Given a 30A 208V
circuit, I could only safely run three of the above AMD systems at full power.
I'd rather just get dedicated 1U or 2U servers, and not have to make
compromises about expandability or serviceability.

~~~
marmaduke
thanks for the links. I hadn’t found any vendors on those 4 node systems.

------
chx
The problem, I feel, is with the Coffee Lake and Kaby Lake R release _after_
learning of Spectre and Meltdown.

~~~
bonzini
Spectre can be avoided (at small performance cost on new CPUs) with microcode
updates and OS fixes. Meltdown can be fixed just at the OS level.

At this point, whether you're releasing a chip with or without the
vulnerability is not an issue. Fixing them will make you look _better_ in
benchmarks if anything, because you don't need anymore the slow PTI
mitigation.

------
classics2
If the behaviors (bus timing logic and such) that are being used to spill
information across process and privilege boundaries actually were fully
documented, wouldn’t the liability fall on the people who used these chips to
write multi-user environments without knowing or understanding the
implications of the technical details?

~~~
sannee
It's very well documented that writing outside array boundaries in C can cause
undefined behavior (leading to arbitrary code execution no less!), yet Adobe
isn't exactly sued for every buffer overflow in Flash.

------
seanlinmt
Does anyone know how one could take part in these class action suits? And are
they limited to US citizens only?

------
yorby
This comment on Slashdot is interesting:
[https://yro.slashdot.org/comments.pl?sid=11756132&cid=561358...](https://yro.slashdot.org/comments.pl?sid=11756132&cid=56135852)

~~~
speps
That's about ME, not the recent Spectre and Meltdown that the article talks
about: "Security researchers at the start of January publicized two flaws,
dubbed Spectre and Meltdown"

~~~
oneweekwonder
> That's about ME, not the recent Spectre and Meltdown

I'm a layman, but spectre and meltdown seems like it can be a vehicle to
exploit the intel management engine.

Once your on ME with a "designed"/obfuscated or hacked path. It is basically
over, because ME a unix system; with lan access; can run java-applets while
the host machine is powered down.

I hope it is only time before intel gives us the keys to our own ME jail.
Hopefully ME will feature in some of these lawsuits.

~~~
yaantc
> I'm a layman, but spectre and meltdown seems like it can be a vehicle to
> exploit the intel management engine.

No, or extremely unlikely at the very least.

Spectre and Meltdown allow a low privilege program to read (not write, only
read) normally protected system memory accessed by higher privileged software
through a shared cache. In the initial attack the privileged and attacking
software run on the same CPU, but there are now "Prime" versions where
attacker and privileged software can run on separate CPUs as long as they're
on the same coherence domain (very simplified: they share some level of cache,
at least the last level).

The ME on the other hand is a completely separate CPU. Although it can access
system memory, likely in a coherent way, as I understand it has its own
dedicated internal memories (sometimes called TCM for "tightly coupled memory"
or CCM for "closely coupled meory", it's all the same: internal SRAM directly
attached to a CPU core and dedicated to it). All the security context would be
in these ME TCMs, so physically unaccessible from software running on the main
CPU cores. It's a simple and efficient way to enforce security: true physical
isolation with no sharing.

So Spectre and Meltdonw may enable a low privilege application to spy on
communications between privileged software on the main CPUs and the ME, but it
shouldn't help attack the ME itself. Unless the Intel ME devs did something
horribly wrong, like storing sensitive ME data in the main system memory.
Which would be very surprising really: if you put an isolated CPU for a ME,
it's really to isolate the security state.

------
tomxor
> dubbed Spectre and Meltdown, that affected nearly every modern computing
> device containing chips from Intel, Advanced Micro Devices Inc and ARM
> Holdings.

WTF, spreading FUD on Intels behalf again?

~~~
strictnein
Apple's CPUs were affected. They're ARM based: [https://support.apple.com/en-
us/HT208394](https://support.apple.com/en-us/HT208394)

AMD's press release on their susceptibility to Spectre:
[https://www.amd.com/en/corporate/speculative-
execution](https://www.amd.com/en/corporate/speculative-execution)

~~~
tomxor
My comment is regarding Meltdown which affects Intel CPUs almost exclusively.
The wording used takes the same strategy as Intels own PR statement by
blurring the line between Meltdown and Spectre in an attempt to play down how
Intel specific the Meltdown vulnerability is.

~~~
theresistor
Meltdown affected Apple's ARM CPUs as well. If you read the linked support
doc, you can see that they released _Meltdown_ mitigations for iOS as well.

~~~
tomxor
Yes... like I said almost exclusively affects Intel CPUs. Just because 0.001%
of non-Intel CPUs are affected while 100% of intel CPUs are, doesn't make
Intel's strategy forgivable. I'm tired of seeing it echoed everywhere.

~~~
tarlinian
Do you know how many CPUs Apple makes? It's certainly an order of magnitude
larger than all the unaffected vendors combined...

~~~
tomxor
Do you know what proportion of the number of ARM based CPUs that Apple has
made or distributed in it's devices over last decade that are affected?

Do you know what proportion of the number of x86 CPUs that Intel has made over
the last decade that are affected?

~~~
tarlinian
Are you really implying that the fact Apple doesn't even disclose which
processors were vulnerable to this a positive?

~~~
tomxor
No. You really don't need that information to infer roughly what proportion
are affected.

There is very little information out there about specifically which ARM chips
are vulnerable, but it's always "High performance ARM designs". This is one of
the few references:

> Intel is the company most significantly affected by these problems. Spectre
> hits everyone, but Meltdown only hits Intel and ARM. Moreover, it only hits
> the highest performance ARM designs. For Intel, virtually every chip made
> for the last five, ten, and possibly even 20 years is vulnerable to
> Meltdown.

[https://arstechnica.com/gadgets/2018/01/meltdown-and-
spectre...](https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-
heres-what-intel-apple-microsoft-others-are-doing-about-it/)

Do you really think Apple has been using such a processor going all the way
back to the first iPhone and iPad? Not to mention there are far more android
phones and tablets than there are Apple ones (revenue !== number of devices)
"High performance ARM designs" weren't really a thing until more recently, and
they aren't going to be anywhere near a majority used in these devices...
Remember what you are comparing this to.

The statement I'm complaining about is already factually wrong by assigning
the Meltdown vulnerability to AMD, and then additionally it's extremely
missleading by implying equality in it's application to ARM and Intel which is
anything but. I'm honestly surprised how many of you replied to my comment in
disagreement, I suppose it just shows how well PR FUD works and spreads if
it's not dispelled loudly enough. Still I expected more on HN.

------
tehlike
Am i the only one that thinks bugs are called bugs for a reason, and this was
most likely not negligence.

~~~
bonzini
Yes. Bugs are called bugs because you could actually find bugs among triodes
and they could cause the computer to malfunction. Then the wording was
extended to software bugs.

~~~
mirimir
Yes, the first known documented was a moth. By Grace Hopper. It prevented a
relay from closing, I gather.

[https://thenextweb.com/shareables/2013/09/18/the-very-
first-...](https://thenextweb.com/shareables/2013/09/18/the-very-first-
computer-bug/)

~~~
chx
This, even after so many years? Please!

[http://www.jamesshuggins.com/h/tek1/first_computer_bug.htm](http://www.jamesshuggins.com/h/tek1/first_computer_bug.htm)

Obligatory working scihub link: [https://sci-
hub.la/10.2307/455415](https://sci-hub.la/10.2307/455415)

~~~
mirimir
Ah, thanks.

tl;dr - Error-prone semi-automatic telegraph keyers were called bugs.

------
kcmastrpc
meanwhile, equifax stumbles in and yells, "nothing to see here, MOVE
ALONG...."

~~~
kjar
riffing on 'the beatings will continue until morale improves': 'the insanity
will continue until awareness improves.'

------
snissn
I'm really relieved the number is a power of 2.

------
arjo129
There needs to be a law that protects engineering corporations against
security flaws that were previously unknown.

~~~
tomc1985
No. Security is already a non-concern amongst non-technical people, who
unfortunately control most leadership positions. Protection from liability
only means we get to see more, and worse, BS like this in the future.

We need to hold companies even more accountable than what they already are. 32
lawsuits is not enough, more like 320!

~~~
sannee
Assume you build a product using TLS as the underlying encryption layer.
Unfortunately, few months later, some bored mathematician figures out how to
completely break AES and ECDH.

Should you be held accountable for choosing "weak" ciphers?

~~~
jnbiche
> Should you be held accountable for choosing "weak" ciphers?

That would be up to the jury. For something like your scenario, as long as
you're keeping up and using industry best practices, you almost certainly
would have nothing to worry about. In fact, a case like that would likely be
dismissed immediately by the judge before it ever went to trial.

~~~
sannee
Okay then, let's assume you are doing something more cutting edge. Like
speculative execution involving memory prefetching.

What are "industry best practices" for that? There are like 3 companies which
do this competitively at scale and each of them guard their methods like it's
the Coca-Cola recipe.

