ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

https://www.cyberus-technology.de/posts/2019-05-14-zombieload.html

by Titanous • 7 years ago

854 307 7 years ago

spockz• 7 years ago

According to their blog post[1], there is little you can do against this. Running different applications on different cpus help against them reading each other’s data but an rogue process can still read data from the “super ordinated kernel” or hypervisor.

rurban3• 7 years ago

Of course you can fix it. I fixed it in Dec 2018 for most such attacks in my safelibc memset_s implementation, but nobody wanted to use it, because securely purging the buffers with secrets via mfence was deemed to slow. So everybody can read your secrets via sidechannel attacks. These tiny MDS buffers need to be purged with verw or l1d_flush followed by an lfence. This needs to be added to memset and memset_s variants. This is much faster. But it will not happen, libc maintainers notoriously don't care, even crypto maintainers not. Only Linux does.

https://software.intel.com/security-software-guidance/softwa...

tux1968• 7 years ago

This is much faster.

Hi. Am trying to understand what you meant here. That both "verw" or "l1d_flush followed by an lfence" are faster than "mfence" which you implemented in safelibc?

If so, why didn't you use these faster options yourself? My understanding was that these faster options needed to be handled at the hypervisor/kernel level, rather than in libc. If so, how is the attitude of glibc maintainers relevant?

gpderetta7• 7 years ago

What prevents the data being read before the memset is executed?

daeken3• 7 years ago

Pandora's box was opened with the public disclosure of Spectre and Meltdown. Security researchers will continue to find new and better ways of attacking the security boundaries in processors, and there's unlikely to be an end to this any time soon. Exciting time to be in security, not such an exciting time to be a potential victim.

penagwin• 7 years ago

Not arguing just asking, but how has Pandora's box been opened with the discloser of Spectre and Meltdown? We've had security researchers discovering and reporting vulnerabilities since there were computers as far as I know?

I do agree that this won't end soon though. It appears to me that many of the methods CPU's use for better performance are fundamentally flawed in their security, and it's not like we can expect the millions of affected machines to be upgraded to mitigate this.

daeken3• 7 years ago

Before Spectre and Meltdown were disclosed publicly, very very few security researchers were looking at the CPU level, beyond things like attacks against hardware virtualization functionality, TrustZone and friends, ME, etc. Those bugs had existed for ages and could've been found through thorough examination of the processor manuals, but nobody had really looked too hard there. These new bugs were found independently by many different researchers/groups, simply because their attention was drawn to looking at this stuff for the first time.

xondono3• 7 years ago

Security by obscurity is no security

andrewstuart2• 7 years ago

This saying rubs me the wrong way, because confidentiality is 1/3 of security. Obscurity is critical or this wouldn't be a vulnerability.

raven105x• 7 years ago

That's cryptography at scale in a nutshell, thus far it seems to be a fair enough countermeasure. Cryptography on an individual item with an unknown cipher/salt/hash can be treated as security via entropy - but with a big enough data set and some idea of the target content, things quickly devolve into security via obscurity since the target content is discoverable with enough time and computational resources. Security via "untamperability" (quantum bits/state) is better, alas we're not quite there yet.

My biggest worry is that all currently known classical "secure" data sets, including encrypted but recorded internet communication, will become an open book a few decades from now. What insights will the powers that be choose draw from it then, and how will that impact our future society? Food for thought.

shitloadofbooks• 7 years ago

_Please_ stop parroting this line incorrectly.

Security _ONLY_ through obscurity is not security. Obscurity is a perfectly valid layer to add to a system to help improve your overall security.

api2• 7 years ago

It reminds me of when the first buffer overflows were disclosed and they were followed by a massive rash of buffer overflow vulnerabilities that continued for over a decade.

shereadsthenews• 7 years ago

I really hate these descriptions of SMT as some kind of violation of the natural relationship between CPU frontend and backend. The idea that there is a “physical core” and a “logical core” does not map to reality.

xyzzyz• 7 years ago

The idea that there is a “physical core” and a “logical core” does not map to reality.

This is the terminology that Intel itself uses in its documentation to describe its products, though. To be fair, they say "physical processor" and "logical processor", not "core".

jamiek88• 7 years ago

9% hit potentially on performance in data center. Add in all the Spectre and meltdown mitigations and we have potentially lost nearly two generations of Intel performance increases.

Just shows the hoops and tricks needed to keep making, on paper, faster processors year on year but without node shrinks to give headroom.

14nm++++ is played out.

faissaloo• 7 years ago

I wonder at what point the hardware fix for these issues stop becoming worthwhile and if we'll see a resurgence of processors without speculative execution or any of these other speed ups.

shrimp_emoji• 7 years ago

Or open source RISC-Vs

gmueckl5• 7 years ago

My guess is that the performance loss from removing these features would make such CPUs less economical than strictly enforced separation between security domains on a hardware assignment and scheduling level. That is, just forget about having the same server run stuff from different contexts at the same time.

TomVDB3• 7 years ago

If ARM and AMD CPUs are not affected, then speculative execution in general is not the issue.

egwor• 7 years ago

Do these really matter if you're running a compute farm? If you're already locked down couldn't you use that as a way to mitigate risks?

pcwalton2• 7 years ago

You can kiss any semblance of reasonable performance goodbye if you eliminate "speculative execution". Pipelining is the most basic tool in the toolbox. Even microcontrollers do it.

rini17• 7 years ago

The industry will probably get dragged, kicking and screaming, into using tagged pointers. CPU could then use the information to put safe lid on speculative execution.

And it will be tough as no compiler supports it, moreover C/C++ are architected from the beginnign to not bother with runtime information about object types/sizes.

saltcured• 7 years ago

Ironically, a high performance, general purpose architecture without speculative execution might require a deep reinvestment in SMT. Instead of trying to speculatively make one thread fast to mask IO stalls, run a large pool of threads that can stall frequently but still keep the execution units and memory channels busy.

To avoid reintroducing these spectre like bugs, you'd have to conservatively design the per-thread execution to avoid those covert channels. Not only synchronously enforcing all logical ISA guarantees for paging and other exception states, but also using more heavy-handed tagging methods to partition TLB, cache, etc. for separate protection domains.

mda4• 7 years ago

Looks like AMD Cpus are safe again.

harryh• 7 years ago

Note that Spectre definitely affected AMD chips and in general these sorts of side channel attacks based on speculative execution are extremely likely to be effective against any chip (including AMD manufactured ones) that employ speculative execution though the precise implementation might have to be jiggered a bit.

makomk6• 7 years ago

Not necessarily. This is more like Meltdown in that it involves one context just outright accessing data in a completely different context, and AMD chips seem to be totally immune from that attack. Any chip with a microarchitecture that actually enforces the architecturally-guaranteed checks, rather than ignoring them and fixing the results up later, can avoid such attacks.

Spectre, on the other hand, is harder both to fix in hardware and to attack because the victim context is itself tricked into speculatively executing code using attacker-supplied data that leaks information - it uses inherent properties of speculative execution rather than any kind of hardware bug, but it's only exploitable if there's some victim code that does exactly the right kind of processing on attacker-supplied data.

mda4• 7 years ago

Sure, but please don't downplay this, so far Intel CPU's are affected by way more vulnerabilities that could be exploited much easily. It is a no brainer to pick if I have to choose between AMD and Intel today.

nine_k7• 7 years ago

In short:

* Core and Xeon CPUs affected, others apparently not.

* HT on or off, any kind of virtualization, and even SGX are penetrable.

* Not OS-specific, apparently.

* Sample code provided.

https://www.cyberus-technology.de/posts/2019-05-14-zombieloa...

waddlesplash2• 7 years ago

And here's the mitigation in NetBSD: https://github.com/NetBSD/src/commit/afab82aeafd0c51afc036a8...

Essentially: Intel released a microcode update which makes the `verw` instruction now magically flush MDS-affected buffers. On vulerable CPUs, this instruction now needs to be run on kernel exit; the microcode update won’t do it automatically on `sysexit`, unfortunately.

nine_k7• 7 years ago

Hopefully with this patches for other OSes should appear soon.

jolopy• 7 years ago

many Pentiums, Celerons and Atoms are also affected.

ksec• 7 years ago

Sorry for being naive. Are these kind of CPU Securities vulnerabilities new? Why it is in the past 20 years we have had close to zero in the news ( At least I wasn't aware of any ) and ever since Spectre and Meltdown we have something new like every few months.

And as far as I am aware they are mostly Intel CPU only. Why? And Why not AMD? Something in the Intel design process went wrong? And yet all the Cloud Vendor are still buying Intel and giving very little business to AMD.

wmf• 7 years ago

I think it is definitely worth introspecting about the history. It has been known for over 20 years that sharing pretty much anything creates side channels but nobody knew how to reliably exploit them and it was assumed that side channels might never be exploitable. In recent years there has been massive progress in practical data extraction using side channels.

philsnow• 7 years ago

Theo (of OpenBSD) famously ranted about Intel's implementation of SMT/hyperthreading ~12 years ago https://marc.info/?l=openbsd-misc&m=118296441702631&w=2

altfredd• 7 years ago

It have always been known how to exploit them. But doing so used to be slower and there have been fewer opportunities for attacks. OS kernels used to have Big Locks (AFAIK, OpenBSD still does), that significantly deterred programs from messing with kernel code and CPU caches.

Things have changed a lot since then: OS kernels became faster by eliminating a lot of unnecessary (?) cross-process overhead; browser makers made a number of potentially problematic decisions ("let's allow Javascript to create CPU threads — what could possibly go wrong?"); Linux kernel developers made few potentially problematic decisions ("let's allow unprivileged processes to invoke arbitrary BPF bytecode — that worked for Java, so what could possibly go wrong?")

A lot of small security lapses added up until it became viable to use CPU flaws to actually target ordinary users. To add insult to injury, certain corporations started spreading myth, that well-known insecure practices — such as knowingly running local software from questionable authors — are "safe enough" for general population. Topic web page even talks about running untrusted Android software, as if Android had some kind of impenetrable security boundary around untrusted apps.

simonsays2• 7 years ago

I think it's because they have designed automatic vulnerability detection devices that are efficient at finding even very obscure issues.

nine_k7• 7 years ago

Running many instances of various untrusted code on the same server is "new": it came with the cloud infrastructure.

Running many instances of various untrusted code on the same client machine is "new": it came with web apps, and with mobile apps.

Before several years ago, it was sort of a non-issue, because to exploit such a vulnerability one would need to write a virus or a trojan, and with this approach, there are many easier ways of privilege escalation.

Something like "cloud" existed likely on IBM mainframes under OS/VM [1] but System/370-compatible CPUs likely lacked all these exploitable speculative execution features.

[1] https://en.wikipedia.org/wiki/VM_(operating_system)

dfrage18• 7 years ago

https://en.wikipedia.org/wiki/Time-sharing

Time sharing was very big in the 1970s, and non-OS/VM methods of sharing mainframes for batch processing were also big at times I'm less sure of.

Inviting complete randoms to routinely run untrusted code in your own security domain, as we do with browsers, that's "new". And thus the popularity of NoScript and uMatrix.

robotresearcher2• 7 years ago

Since there is relatively little AMD running, you would expect relatively little investment in attacking it.

kevin_thibedeau• 7 years ago

We were unable to reproduce this behavior on non-Intel CPUs and consider it likely that this is an implementation issue affecting only Intel CPUs.

The attacks are being attempted. AMD just didn't screw up as badly.

lawnchair_larry2• 7 years ago

This is a common pattern for new bug classes. Nobody thought to look at this, and when they did, the rabbit hole went deep. We likely haven’t seen the bottom.

AMD are not better. They’re probably worse. They’ll be looked at when the Intel tree stops bearing fruit. But finding an Intel bug is higher impact, so that’s what researchers want to look at.

outworlder• 7 years ago

AMD are not better. They’re probably worse.

This argument makes zero sense and fails real world inspection. You see, researchers did publish the fact that it affected AMD on Spectre.

For this vulnerability, they were unable to reproduce the bug on AMD (their words). Which means that they tried.

mda4• 7 years ago

Bullshit, So far most vulnerabilities only affected Intel. Because of their choices in their design. AMD is way better, so far.

clucas• 7 years ago

A lot of reasons - one, we only recently (in academic research time) started using single servers to host services from multiple customers, so the value of these sorts attacks only recently became apparent.

Second, as I understand it, Spectre and Meltdown really started this whole parade because prior to those vulnerabilities, speculative execution attacks were something only academics ever talked about - everyone assumed it would be too difficult to pull off in the real world. When that received wisdom was proved wrong, it probably opened the floodgates for researchers - both in terms of intellectual interest and money.

Also, re: why Intel and not AMD... I think Intel is probably a higher-dollar target due to their dominance in the server market, but also probably because they have been neglecting QC for years... see, e.g., http://danluu.com/cpu-bugs/

dfrage18• 7 years ago

Dan Luu didn't note that Meltdown goes all the way back to their first out-of-order speculative execution design, the Pentium Pro in 1995. I note that ARM, and both of IBM's architectures, POWER and mainframe, also had Meltdown issues, and everyone including AMD "enjoys" Spectre bugs, so named because they'll be haunting us for a very long time.

cesarb3• 7 years ago

Why it is in the past 20 years we have had close to zero in the news ( At least I wasn't aware of any ) and ever since Spectre and Meltdown we have something new like every few months.

It's a new vulnerability class. Prior to Spectre, nobody thought that code which didn't execute (and couldn't execute) could affect architectural state in an observable way. It's hard to overstate how bizarre the vulnerabilities from the Spectre family are from a software point of view: it's leaking data from code that not only didn't execute yet, but also can never execute, and in some cases doesn't even exist! It's like receiving a packet your future self sent to the past, except that your future self had been dead for two years when he sent the packet, and for some reason he's actually a parrot.

Once a new vulnerability class is discovered, researchers will start looking for new bugs in and around that class. Which is why we have seen lately so many issues disclosed around speculative execution and data leaked through shared microarchitectural state.

gmueckl5• 7 years ago

These CPU flaws make it seem as if virtualization in the data center is becoming really, really dangerous. If these exploits continue to appear, the only way forward would be dedicated machines for each application of each customer. Essentially, this might be killing the cloud by 1000 papercuts because it loses efficiency and cost effectiveness and locally hosted hardware does not necessarily have to have all mitigations applied (no potential of a unknown 3rd party code deployed to the same server).

ljlolel• 7 years ago

it increases cloud revenues because of slow downs in CPU, and people can't move off cloud because they're locked in and can't hire datacenter engineers anyway

gnode4• 7 years ago

Ultimately cloud providers don't want revenue, they want profit. Except in some perverse cases (like cost-plus-percentage contracts), it's not generally in a business's interests for their costs to go up.

Even if there's no opportunity to switch away, eventually you bleed your customers dry and put them out of business. You will typically always aim to price your offering at the equilibrium point where loss of custom increases faster than the increase in profit, and vice versa.

One situation in which an increase in your costs can be good, is if the same increase applies more to your competition. But, in this case multi-tenant cloud is hit harder than the competing alternative of private infrastructure.

chatmasta• 7 years ago

This is an important point that I noticed around the time of Spectre/Meltdown as well. The mitigation for those bugs caused an average of 30% CPU slowdown, meaning it took 30% more CPU cycles to perform the same work as it did prior to the mitigation. If a cloud provider rolls that out to every server, then every customer's bill for CPU usage should increase by roughly 30%.

Am I totally misunderstanding this? Someone please correct me if I'm wrong.

gnode4• 7 years ago

dedicated machines for each application of each customer.

I don't think you don't need to go this far. You can probably get away with circuit switching small blocks of hardware, and fully resetting them between handovers. Although you'd have to ensure sufficient randomisation / granularity to destroy side channels in the switching logic.

Tharkun• 7 years ago

Many years ago, OpenBSD's Theo De Raadt made a sneer at virtualization, saying something the lines of "they can't even build a secure system, let alone a secure virtualized system". I can't remember who he was referring to specifically, but we've certainly been seeing a lot of similar vulnerabilities.

gmueckl5• 7 years ago

Would be cool to see a source for that one. Theo de Raadt is a hardliner whom I don't always agree with, but I'd like to know how visionary he actually was in this case (quite a bit by the looks of it).

dexen2• 7 years ago

Here's the full Theo de Raadt quote from 2007 [1]:

"""> Virtualization seems to have a lot of security benefits.

You've been smoking something really mind altering, and I think you should share it.

x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit.

You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

You've seen something on the shelf, and it has all sorts of pretty colours, and you've bought it.

That's all x86 virtualization is. """

[1] https://marc.info/?l=openbsd-misc&m=119318909016582

smhenderson• 7 years ago

I believe "they" were all the people poking the project asking when were they going to support virtual X and virtual Y. He basically stated it would never happen on OpenBSD[1] but here we are with [2] (vmm/vmd/vmctl).

[1] http://www.tylerkrpata.com/2007/10/theo-de-raadt-on-x86-virt...

[2] https://www.openbsd.org/faq/faq16.html

[1] probably isn't the best source out there, I was in a bit of a rush to find it but that is indeed the quote! Gotta either love or hate Theo I guess!

dooglius• 7 years ago

Well, dedicated machines for each security domain for each customer, a lot of the time it's fine for many applications to be in the same security domain.

gnode4• 7 years ago

Even this isn't enough. Sometimes mutually untrusted parties must exchange data (say you're running a trading platform, or a social network). You have to ensure every point of interaction between such parties is immune to timing attacks.

dchest• 7 years ago

Except most companies don't care about security of the cloud apart from the magical "compliance" and that they are on the same cloud as everyone else.

Thaxll• 7 years ago

You should use large instance that don't share the same CPU socket, on AWS for example it would be c5.9xlarge and above.

peterwwillis• 7 years ago

The point of virtualization isn't to add security. It gives you functionality you just cannot have otherwise, and the cloud enables you to scale in a way that is impossible otherwise. If there are security holes, they get patched and the market moves on. It's not just going to abandon either the cloud or virtualization.

ct5208• 7 years ago

I don't agree with that statement. As a stand-alone physical machine is expected to be secure in its own enclave an I think it's within reason a virtual one would have the same expectations.

NathanKP• 7 years ago

Interesting to note that AWS has been working on their own custom silicon, such as the announced Arm based AWS Graviton powered machines.

We will most likely see a continued divergence between "consumer silicon" which is designed for speed in a single tenant environment on your local desktop or laptop, and "cloud silicon" which is optimized to protect virtualization, be power efficient, etc. I'd predict that this will actually lead to increased efficiency and lower prices of cloud resources rather than the "death by a 1000 cuts" that you are proposing.

dboreham• 7 years ago

There are bare metal "cloud" providers such as Packet.net where you get the click n deploy convenience of the cloud but a physical machine. They have quite small machines in the inventory that are close to price competitive with VMs. Even Amazon has this bare metal capability FWIW, but afaik only for big expensive machines.

mr_overalls• 7 years ago

At what point do we simply revert to using typewriters for authoring sensitive documents, and pneumatic tubes (couriers for WAN) for networking?

https://www.theguardian.com/world/2014/jul/15/germany-typewr...

gambler• 7 years ago

We don't need to revert to typewriters. We just need computers designed with a real security model in mind, instead of piles of ah-hoc mitigations. However, I bet no one will invest in it until one of these exploits bring down AWS, take over Google's crawlers or something else of that sort.

nickpsecurity2• 7 years ago

There's smaller companies that keeps designing them. Nobody buys them for the most part. One example that can handle lots of security policies is CoreGuard. It's based on work at crash-safe.org.

https://www.dovermicrosystems.com/

Academics keep coming up with stuff for timing channels like partitioning, masking, and randomizing components. Personally, if not physical separation, I'd just do SMP with secret parts on different CPU that untrusted parts. Both memory safe on a separation kernel to isolate them. One design used different DIMM's, too.

icelancer• 7 years ago

> We just need computers designed with a real security model in mind

These are already options, as another commenter pointed out. If you need this kind of protection, it is available, at significant cost.

criley2• 7 years ago

Long ago? https://www.theguardian.com/world/2013/jul/11/russia-reverts... (also https://www.cia.gov/library/readingroom/document/cia-rdp78-0...)

But assuming a typewriter has no attack vectors is just as foolish as insecure networks IMO.

https://arstechnica.com/information-technology/2015/10/how-s...

Also: detecting text through keystrokes previously discussed here https://news.ycombinator.com/item?id=7448976 (https://people.eecs.berkeley.edu/~tygar/papers/Keyboard_Acou...)

Heck while I can't find a quick source, I remember a story about how the CIA designs rooms/walls and buildings to prevent sound from predictably bouncing through rooms in ways that could be captured from afar.

Spooks are usually 10 steps ahead of the public common sense this sense.

nickpsecurity2• 7 years ago

https://en.m.wikipedia.org/wiki/Sensitive_Compartmented_Info...

S_A_P• 7 years ago

This sentence killed me: "Daniel Gruss, one of the researchers who discovered the latest round of chip flaws, said it works “just like” it PCs and can read data off the processor. That’s potentially a major problem in cloud environments where different customers’ virtual machines run on the same server hardware."

What are they saying here?

jcoffland• 7 years ago

It should read:

...said it works “just like” in PCs

The number of mistakes in the Techcrunch article is atrocious.

ficklepickle• 7 years ago

I found two and emailed the author. It's my sad little hobby. He replied promptly and they all should be fixed now. In fact, he found a third that I missed.

Keep in mind, this article was posted at 3am pacific, 6am eastern. Assuming the author is in North America, he was probably under a deadline and rather tired.

I have found similar typos from prominent writers. Sometimes they email me back, which I appreciate.

I found one in an article by Cory Doctorow on boingboing. I checked on builtwith.com, and they use WordPress/Jetpack. Jetpack has a feature that will warn you if you try and publish something with spelling mistakes, it is just not enabled by default.

I let Mr Doctorow know all this, in a very polite manner, and he responded with "many thanks". I'm not big on celebrity worship, but it still made my day.

mfatica• 7 years ago

Well, it's techcrunch

dang4• 7 years ago

This is from the Techcrunch article on the story: https://techcrunch.com/2019/05/14/zombieload-flaw-intel-proc...

We merged that HN thread (https://news.ycombinator.com/item?id=19911465) into this one, via this other one (https://news.ycombinator.com/item?id=19911715).

tosh• 7 years ago

This looks like it is from the same TU Graz people who also worked on Meltdown & Spectre

https://meltdownattack.com/

dschuetz• 7 years ago

It takes one rouge/unpatched VM to run and scan threads randomly, undetected over a longer period of time, if not patched. With HT disabled potential hits become less likely, but still possible given time. Is virtualization on Intel dead now? Perhaps not. But, it's increasingly dangerous to use Intel for cloud services.

nnx• 7 years ago

Interestingly AWS released a bulletin about MDS vulnerability but nothing about ZombieLoad yet. https://aws.amazon.com/security/security-bulletins/AWS-2019-...

scandinavian2• 7 years ago

CVE-2018-12130 is in the list of CVE's in your link. That is the ZombieLoad CVE. I hate these stupid names, they only confuse as shown by your comment.

dang4• 7 years ago

Url changed from https://zombieloadattack.com, which points to this.

There is a home page about today's vulnerability disclosures at https://news.ycombinator.com/item?id=19911715. We're disentangling these threads so discussion can focus on what's specific about the two major discoveries. At least I think there are two.

makomk6• 7 years ago

I think there's two seperate branded annoucemenst of three or four different vulnerabilities depending on how you count. (There are four CVEs and Intel lists four, but the researchers announced three.) Haven't seen much discussion of the specific differences between them, probably because they're subtle and not terribly relevant to most folks - they all involve one process speculatively reading memory it shouldn't be able to access via the memory access buffers within Intel CPUs, they just vary in which parts of the memory access machinery they use and how exactly they're exploited.

polskibus• 7 years ago

Can this attack allow the attacker to escape public cloud isolation methods and break into the control plane or other VMs?

readams• 7 years ago

It would have, but it's likely the cloud vendors have already deployed defenses.

mattashii• 7 years ago

Today's AWS[1] and Google Cloud[2] security bulletin notes that all their host infrastucture (read: cpu firmware/microcode) has been updated to mitigate the issues disclosed today by Intel[3]. I could not find anything for Azure yet.

I also note that the provided OSes are being updated with mitigations as well, so for complete mitigation of the issue you'll probably need to update your OS.

[1] https://aws.amazon.com/security/security-bulletins/AWS-2019-...

[2] https://cloud.google.com/compute/docs/security-bulletins#201...

[3] https://www.intel.com/content/www/us/en/security-center/advi...

robmccoll• 7 years ago

That depends on what you mean by "break into". If you mean sample data (read) from the control plane or other VMs, then yes; however, the attacker may have difficulty targeting which data is read. The attacker would not be able to write to that memory or gain any sort of execution privilege using this method alone.

Fej2• 7 years ago

What is the recommended course of action? Stop buying Intel products, and devices which contain them?

What about devices with older processors? I'm still running a Sandy Bridge rig and it works fine, except for the side channel vulnerablities. It's probably not going to be patched. I also have a cheaper computer with a Skylake processor, which is newer yet still vulnerable!

It's only a matter of time until something really nasty comes along, making all these PCs dangerous to use. What then? Lawsuits?

My questions are only partially rhetorical.

cfallin6• 7 years ago

The stream of critical CPU vulnerabilities starting with Spectre/Meltdown last year are related to speculative execution, not just Intel. (AMD and ARM CPUs are also vulnerable to Spectre, for example.) Intel CPUs are sometimes vulnerable to additional attacks because they speculate in more scenarios than other designs. But fundamentally, as long as multiple different trust domains are sharing one CPU that speculates at all, or has any microarchitectural state (e.g., caches), there are likely to be some side-channel attacks that are possible.

The important thing to realize is that speculation and caching and such were invented for performance reasons, and without them, modern computers would be 10x-100x slower. There's a fundamental tradeoff where the CPU could wait for all TLB/permissions checks (increased load latency!), deterministically return data with the same latency for all loads (no caching!), never execute past a branch (no branch prediction!), etc., but it historically has done all these things because the realistic possibility of side-channel attacks never occurred to most microarchitects. Everyone considered designs correct because the architectural result obeyed the restrictions (the final architectural state contained no trace of the bad speculation). Spectre/Meltdown, which leak the speculative information via the cache side-channel, completely blindsided the architecture community; it wasn't just one incompetent company.

The safest bet now for the best security is probably to stick to in-order CPUs (e.g., older ARM SoCs) -- then there's still a side-channel via cache interference, but this is less bad than all the intra-core side channels.

Fej2• 7 years ago

Yes, the vulnerabilities are not just Intel, but they're mostly limited to Intel CPUs. Why is AMD less prone to these mistakes? Perhaps there are simply fewer researchers looking into AMD processors?

Symmetry2• 7 years ago

I think there's quite a big difference between leaking information between security contexts (Meltdown) and leaking within a security context (Spectre). The later is a problem but it's not a the same magnitude of failure as the former is.

Also, no need for older SoCs. High end ARM chips have both in-order and out-of-order cores but the cheaper ones have in-order ones only. A Snapdragon 450 is pretty modern and doesn't speculate deeply enough to be vulnerable to Spectre.

dpwm• 7 years ago

Spectre/Meltdown, which leak the speculative information via the cache side-channel, completely blindsided the architecture community; it wasn't just one incompetent company.

In the x86 space, Meltdown absolutely was down to one company apparently deciding to over-optimize for performance.

I can't find it now, but I remember reading a thread from (I think) the OpenBSD devs about how the Intel MMU documentation described fairly sane behaviours and how far the reality deviated from the documentation.

makomk6• 7 years ago

That's not exactly true. Broadly speaking, there have been two very different kinds of speculative execution vulnerabilities with different security implications and workarounds. Spectre and its relatives are an attack on trusted code that process untrusted data using certain code patterns guarded by conditionals that can be speculatively executed; they're inherent to speculative execution past branches, but they require specific code patterns that can be avoided to work around the issue.

These vulnerabilites and Meltdown allow untrusted code to speculatively access data that it shouldn't be allowed to access at all, and use that speculative access to leak data itself. Unlike Spectre this can be (and to some extent has to be) fixed at the hardware level, because the hardware itself is failing to protect sensitive data. This class of vulnerability seems to have been mostly Intel-exclusive so far (with the main exception being one unreleased ARM chip that was vulnerable to Meltdown). There's nothing inherent about modern high-performance CPUs that requires them to be designed this way.

Edit: This slipped my mind, but Foreshadow / Level 1 Terminal Fault was yet another similar Intel-only processor vulnerability that allowed speculative access to data the current process should not be able to access. It's definitely a pattern.

gok• 7 years ago

In-order does not mean no speculative execution

hinkley• 7 years ago

We were talking about alternative CPU designs and a guy commented on how much of the volume of a CPU is memory these days.

I wondered aloud if it wouldn’t be better for use to embrace NUMA, make the bigger caches directly addressable as working memory instead of using them as cache.

tomxor2• 7 years ago

The safest bet now for the best security is probably to stick to in-order CPUs

out-of-order execution != speculative execution.

It is possible to have OoO without speculative execution. On the other hand they do tend to come as a pair since they both utilise multiple execution units, for instance the Intel Pentium in 1993 was the first x86 to have OoO or branch prediction (486 and those before were scalar CPUs).

iamgopal• 7 years ago

Can we say that, without speculation and caching, and just throwing more and more cpu to work, we would have slower single app performance but better parallel execution ?

Uristqwerty• 7 years ago

Reading about speculative execution exploits makes me wonder whether it would be useful to have a speculation register, and an instruction prefix that claims one bit of that register, much as a mutex, while the prefixed instruction is being speculated about. Assuming a compiler intelligent enough to key a bounds check and later array access to the same speculation bit, or a language exposing low-level functionality to the programmer, Spectre could be defeated with minimal performance impact. Perhaps it could also be used to work around many other sorts of speculative execution flaws that might turn up in the future.

nine_k7• 7 years ago

Really, different trust domain cannot seriously benefit from a common cache: their datasets are by definition disjoint.

So it would be safest to execute them on separate CPUs not sharing a common cache, e.g. pinning them to different CPU sockets on a multi-socket machine, or to different physical machines altogether.

This may be still faster than running on old ARMs.

I wonder if dedicated cloud boxes, where all VMs you spin on a particular physical machine belong only to your account, will become available from major cloud providers any time soon. In such a setup, you don't need all the ZombieLoad / Meltdown / Spectre mitigations if you trust (have written) all the code you're running, so you can run faster.

bin0• 7 years ago

From what I have heard, these flaws mostly affect Intel because they are the largest CPU manufacturer. They also dominate the datacenter and cloud-compute industries for now, which are by far the highest value targets.

But as an Intel consumer, I am not happy. My understanding is that more stuff can be fixed in microcode, but I suppose a bug could show up which was not practically fixable. If that happened, I would certainly sue or join a class-action lawsuit. Probably the class-action route, because even if I didn't get any thing, I would be just mad enough at Intel to want them to suffer.

Of course, we do have consumer protection agencies; it is possible that they would step if Intel had sold what would effectively be a defective product.

strmpnk3• 7 years ago

these flaws mostly affect Intel because they are the largest CPU manufacturer

It doesn't have anything do to with how large Intel is. They have clearly made a more aggressive hardware design which has more corner cases to break. The designs are broken and microcode can patch some variants of these side channels but the overhead is becoming a problem.

In this case it's not certain if microcode can address the problem but if it can't, disabling of SMT (hyperthreading) can be a significant cost for some workloads (well above 10% for things that haven't been specifically tuned to avoid cache misses, which is most software in my experience).

omarforgotpwd• 7 years ago

Vulnerabilities are everywhere, in everything. They just haven't been discovered yet.

echopom• 7 years ago

What is the recommended course of action? Stop buying Intel products, and devices which contain them?

There is absolutely nothing to be done on our level about this.

I'm fairly convinced this is systemic issue that can only be solved by redesigning almost entirely modern cpus and computers architecture.

I can draw a parallel to approximately all Intel cpus which are know to have a dedicated "mini cpu" called "Minix" which is an absolute "black box" and have been found to be vulnerable for to a wide variety of attack for nearly decades...

Not only we need to redesign computers and cpu architecture but we desperately need to make that entire process and knowledge open source , available to all and more transparent.

Today this entire knowledge is the hand of few gigantic corps whom are keeping it to ensure their monopolistic position.

guido_vongraum3• 7 years ago

Me being a caveman who believes that technology is a hammer that still can be used to drive nails into building materials instead of our own heads, I'm longing for an Intermesh of simple networked 8-bit machines running on vanilla (no ARM core bonuses) FPGAs, with CPUs simple enough to be predictable and understood not by a select few superhumans in the world, but by a critical mass of people, and communication protocols built from scratch with privacy and security in mind, so that such device could represent a social node: here's some info that I chose to make public, and there's my protected data. A single pedestrian FPGA could host a swarm of such tiny CPUs, each dedicated to a single task or security domain: a CPU to talk to shared filesystem, a CPU to talk to the private one, one more to process input, one to Tx/Rx bytes over the wire etc..

Or, if that is too complex, there could just be a bunch of breadboarded ICs capable of networking. There actually are real-world examples of such machines exposed via telnet, e.g. http://www.homebrewcpu.com

And all the performance beasts, while surely indispensable, could just enjoy their air-gapped solitude. Are there any massively parallel supercomputing tasks whose results couldn't be summarized and reduced to mere text, which is not too hard to move over the airgap manually?

paulddraper2• 7 years ago

HN has a broad audience.

What exactly is "our level"?

mgalgs• 7 years ago

Not only we need to redesign computers and cpu architecture but we desperately need to make that entire process and knowledge open source , available to all and more transparent.

Here's hoping OpenRISC takes off!

rodgerd• 7 years ago

Stop buying Intel products, and devices which contain them?

None of that helps with your public cloud workloads.

SEJeff• 7 years ago

If only you could target the processor type for your cloud instances...

https://aws.amazon.com/ec2/amd/

https://azure.microsoft.com/en-us/blog/announcing-the-lv2-se...

spamizbad• 7 years ago

Step one: switch to in-order cores. Step two: cheekily author a Medium article titled Tomasulo's Algorithm Considered Harmful

dfrage18• 7 years ago

Maybe be more alliterative and title it Tomasulo's Algorithm Considered Tempting? Because as far as I have found without reading original documents, its development and use in the IBM System 360/Models 91 and 95 was only but fully out-of-order on the floating point engine, they didn't have the gates, implemented with discrete transistors, to go further to speculative, or include any scalar hardware.

Hitting diminishing returns on caches with an ever increasing gate budget is I believe prompted this second generation starting in the 1990s which adds speculative execution, which the algorithm with all those extra hidden registers really invites you to do.

Narishma• 7 years ago

Are in-order cores even fast enough to render a Medium article?

userbinator2• 7 years ago

The easiest prevention is to stop running untrusted code, or don't start doing so if you're not already.

The "elephant in the room" with all these attacks starting from Spectre/Meltdown is that an attacker has to run code on your machine to be able to exploit them at all.

To the average user, the biggest risk of all these side-channels is JS running in the browser, and that is quite effectively prevented by careful whitelisting.

As you can probably tell, I'm really not all that concerned about these sidechannels on my own machines, because I already don't download and run random executables (the consequences of doing that are already worse than this sidechannel would allow...), nor let every site I visit run JS (not even HN, in case you're wondering --- it doesn't need JS to be usable.)

api2• 7 years ago

I think that's a cop out. A system should be secure enough to isolate untrusted code.

blablabla123• 7 years ago

I think it depends very much how you use your computer and also how much comfort you need. Therefore the answer is very individual. If you want to go totally hardcore secure, you might consider OpenBSD on some obscure architecture like RISC-V or Power - the Talos II workstations are really powerful. (Power was AFAIK originally vulnerable to Spectre or Meltdown, but there are mitigations and it's 100% open source) Probably it's smart to use 2FA on separate hardware (Smartphone, Yubikey or Smartcard for instance) and make it a habit to delete data and apps that you don't need. Oh and also installing only software from trusted sources - whatever that means for you - and an adblocker might also help to prevent malicious JS code. Also for many people iPads serve all needs they have and by default all the native apps have been reviewed.

Probably it's smart to not see a computer not like a walled garden but more like a sieve.

IgorPartola3• 7 years ago

So at what point do we start producing CPUs specifically aimed at running a kernel/userland? Why don't we have a CPU architecture where a master core is dedicated to running the kernel and a bunch of other cores run userland programs? I am genuinely curious. I understand that x86 is now the dominant platform in cloud computing. But it's not like virtualization needs to be infinitely nested, right? Why not have the host platform run a single CPU to manage virtual machines, which each get their own core or 20? Would the virtual machines care that they don't have access to all the hardware, just most of it?

founderling• 7 years ago

You cannot give each VM their own core. The business model of the cloud is that multiple VMs with virtual cores run on a single real core.

derefr• 7 years ago

At the low end, sure. At the medium-to-high end, each VM is bound to one or more physical cores of the host, or sometimes an entire host ("dedicated instances.")

I don't know enough about the IaaS market to know what the relative revenues of low-end compute vs. medium-to-high-end compute are for your average vendor, though. Is most of the profit in the low end?

I'm also curious on what the impact on margins would be if IaaS vendors decided to switch away from serving the low-end compute demand with "a few expensive high-power Intel cores per board, each multitasking many vCPUs", to serving the demand with "tons of cheap low-power ARM cores per board (per die?) with each core bound to one vCPU."

lallysingh• 7 years ago

The hit is in IPC between the kernel and userland processes. If you really want to pay it, then just go microkernel. You can do that today.

dragontamer2• 7 years ago

Why don't we have a CPU architecture where a master core is dedicated to running the kernel and a bunch of other cores run userland programs?

How will your "userland core" switch to other userland programs safely? A pointer-dereference can be a MMap'd file, so its actually I/O. This will cause the userland program to enter kernel-mode to interact with the hardware (yes, on code as simple as blah = (this->next)... the -> is a pointer dereference potentially in a mmap'd space to a file).

So right there, you need to switch to kernel mode to complete the file-read (across pointer-dereference). So what, you have a semaphore and linearize it to the kernel?

So now you only have one-core doing all system level functions? That's grossly inefficient. Etc. etc. I don't think your design could work.

IgorPartola3• 7 years ago

Sounds like we would need a new paradigm for how to handle that. But it seems to me that x86 is in now way the panacea of COU design. Wouldn’t you gain some good trade offs by changing up how things are done?

anticensor• 7 years ago

How will your "userland core" switch to other userland programs safely? A pointer-dereference can be a MMap'd file, so its actually I/O.

User PU would stall on the "outermost" return and wait for another dispatch by kernel PU; it would also stall during context switches.

mochomocha• 7 years ago

You'd also need to duplicate the whole memory hierarchy of CPU caches to prevent cache attacks against your "kernel CPU".

IgorPartola3• 7 years ago

Would the kernel even need RAM access for its internal operations? It seems like today’s CPU caches are so large that a kernel could safely operating without ever leaving the chip, aside from anything that the userland asks it to work on. So in that case you wouldn’t need to ever run userland code against kernel CPU’s caches.

mr_toad• 7 years ago

Why don't we have a CPU architecture where a master core is dedicated to running the kernel and a bunch of other cores run userland programs?

Sounds a lot like IMB’s Cell architecture.

justryry• 7 years ago

Do cloud providers commonly float cores between VMs? I could see instances like the AWS T family (burstable) sharing, but I had always assumed that most instance types don't over-provision CPU.

If that's the case, my CPUs are likely pinned to my VM. I could still have evil userland apps spying on my own VM, but I would not expect this to allow other VMs to spy on mine.

jupp0r3• 7 years ago

Sharing CPUs is not the point, as long as you are sharing physical memory with other tenants, you are vulnerable (although exploits are much harder when attackers have to cross privilege boundaries).

srfilipek• 7 years ago

Sharing CPUs is not the point, as long as you are sharing physical memory with other tenants, you are vulnerable

Not to these vulnerabilities. These are attacking memory that is "in flight" within a processor.

bayindirh2• 7 years ago

I don't think many cloud providers explicitly pin the VMs to the cores even if they don't over provision the servers.

INTPenis2• 7 years ago

So I'd love to post an Ask HN: Which AMD Laptops would you recommend for work, alternatives to Thinkpads?

I've noticed some Thinkpads with AMD CPUs but I feel like I'm on virgin ground when it comes to AMD and their integrated GPU offerings.

strmpnk3• 7 years ago

I've been eyeing more release details on the ThinkPad X395 which was recently announced. "Coming Soon" is probably means early June for some select configurations. I think these will fit in the premium/professional laptop space better than some of the bargain laptops that carried AMD chips in the past.

I believe others OEMs are developing similar offerings as well but I can't find any quick links for newer SKUs like the Ryzen 7 3700U which offers the improved Zen+ revisions which will specifically improve battery life and heat issues.

chx• 7 years ago

Yes the T495 and the X395 ought to be the best ones.

Shelnutt2• 7 years ago

If you don't need a dedicated GPU, the APU offers from AMD are great. They have native linux drivers for everything (on the AMD side, double check the nic/touchscreen/touchpad). I'm using an HP envy x360 15z with a AMD Ryzen 2700u running gentoo and love it. The HP envy has a weird keyboard, but it was a good tradeoff for the AMD setup when I bought it last year.

There is a much larger market in 2019 for AMD laptops, so you should be able to find something to suite your needs.

akvadrako2• 7 years ago

It's not that large yet. There are sadly still no options with HiDPI screens (200+ dpi) or discrete AMD GPUs.

Next year with the 7nm mobile chips will probably be much better.

bitL3• 7 years ago

You can't really find a good AMD workhorse laptop; all of them end up with some outdated 1080p displays at best :( There is like only one notebook with a decent HiDPI screen with Ryzen (some HP, but not a workhorse). There was also terrible problem with Mobile Ryzen drivers resolved only like a month ago.

TheOperator2• 7 years ago

1080p strikes me as the pinnacle of a workstation display for laptops right now since I highly doubt any productivity improvement from higher dpi is gonna beat out battery life in the vast majority of cases. Even in the one use case where it matters, 4k video production, theres a reasonable argument for using screens similar to what your consumers will use at least some of the time. Especially if it saves you money and you get to use discounted top performing cpus to boot.

Realistically the AMD laptops lack of color accuracy compared to shit like the trutone Intel macs, and lack of display connectivity especially compared to a thunderbolt outfitted x1 extreme that can connect to four 4k displays is a bigger problem. Especially since external displays actually need the resolution.

vondur• 7 years ago

I've just received in some Thinkpad E485's which have the Ryzen 2500U CPU. They seem pretty nice, with a 1080p screen that's non-glare. The documentation says they support Redhat Enterprise Linux and Ubuntu. So far they seem nice. I was thinking of trying PopOS on it and see how it runs.

akvadrako2• 7 years ago

Honor Magicbook looks interesting:

https://www.huaweicentral.com/honor-magicbook-ryzen-7-versio...

The new 3700U model will probably be available on Aliexpress next month or so. I would consider it except Linux support is unknown and only 8GB of RAM.

yalok2• 7 years ago

macOS performance: Testing conducted by Apple in May 2019 showed as much as a 40% reduction in performance with tests that include multithreaded workloads and public benchmarks. Performance tests are conducted using specific Mac computers. Actual results will vary based on model, configuration, usage, and other factors.

from here: https://support.apple.com/en-us/HT210107

ynnn• 7 years ago

Yeah, if you choose to turn off hyperthreading. Pretty expected tbh - hyperthreading helps quite a bit for some things.

yalok2• 7 years ago

but I don't see Intel mentioning this 40% anywhere... by Intel words, the worst degradation is 9%, and it creates an impression that it's with HT off.

If you choose not to disable HT, you stay vulnerable even with updated microcode, right?

In any case, Apple's stats are much more gruesome...

fakwandi_priv• 7 years ago

Apparently Intel attempted to play down the issue by trying to award the researchers with the 40,000 dollar tier reward and a separate 80,000 dollar reward as a "gift" (which the researchers kindly denied) instead of the maximum 100,000 reward for finding a critical vulnerability.

Intel was also planning to wait for at least another 6 months before bringing this to light if it wasn't for the researchers threatening to release the details in May.

Source in the dutch interview: https://www.nrc.nl/nieuws/2019/05/14/hackers-mikken-op-het-i...

easytiger• 7 years ago

You have to admire the complex complicity. Someone smart enough to understand the depths of the problem had to guide that conversation

btown• 7 years ago

Or just someone paranoid enough that this would be their standard response if they poll the researchers and one of them says "this could be New York Times big"

close042• 7 years ago

Intel was also planning to wait for at least another 6 months before bringing this to light

Of course, until the legally agreed date when they can dump shares so there’s no obvious proof that it’s insider trading. Isn’t that what (then) Intel CEO Brian Krzanich did after Meltdown/Spectre?

nullwasamistake2• 7 years ago

Not sure why down voted, this sounds like the most logical reason

lawnchair_larry2• 7 years ago

No. CPU vulns don’t affect Intel’s stock price.

mwcmitchell• 7 years ago

That speaks volumes to the integrity of the researchers. Similarly, it speaks to a lack of the same @ Intel. Bribing for silence is not the way to deal with vulnerabilities. I’m glad the researchers are getting some recognition.

bijant• 7 years ago

Intel has abused the responsible disclosure process for economic gain. Their Leadership was not interested in a repeat of the spectre and meltdown impact on their stock price and made the (most likely accurate) assessment, that recurring news of intel vulnerabilities would harm their stock more than delay and cumulated release. As a result Academic Researchers were denied some of the credit they would otherwise have rightfully earned, because their individual contributions are buried in a sea of similar publications. Research efforts were thus needlessly duplicated. Research which could have formed the basis for subsequent research was unavailable and (publicly funded) researchers wasted time duplicating results. If two researchers discover the same vulnerabilities independently, there should be no embargo on disclosures because it has to be assumed with a high likelihood that third-parties might already be actively exploiting it. The public has to be warned, even if no effective mitigation is available. If for a subset of the vulnerabilities, AMD and ARM are not affected then security conscious users could have been reducing their exposure by utilizing competitors chips.

In this case the practice of responsible disclosure has been turned on its head. There should no longer be any responsible disclosure with Intel as long as they do not commit to changing their behavior.

rarecoil• 7 years ago

The public has to be warned, even if no effective mitigation is available. If for a subset of the vulnerabilities, AMD and ARM are not affected then security conscious users could have been reducing their exposure by utilizing competitors chips.

The way Intel has been handling these security issues, I am going to avoid buying Intel whenever possible moving forward, regardless of if they have slight performance or power gains over competitors. The way to speak negatively toward corporate governance in this case is to vote with my wallet.

nullwasamistake2• 7 years ago

It's worse than that. Some of these flaws have been known for over a year already. Many vendors with implementation details of the fixes have said "full mitigation may require disabling hyperthreading".

Wtf does that mean exactly? Do the patches and microcode work or do they not? I expect the truth to come out as OSS maintainers come out of embargo and others analyze the patches. But it sure looks like VM's on your favorite cloud provider will still be vulnerable in some ways because they're not turning off HT.

Wired has many details of your Dutch link in English. https://www.wired.com/story/intel-mds-attack-speculative-exe...

Intel pressuring vendors to not recommend disabling hyper threading? Apple has added the option to MacOs, so presumably the mitigations are not completely effective: https://www.theregister.co.uk/2019/05/14/intel_hyper_threadi...

jniedrauer• 7 years ago

What impact does this have in a multi-tenant cloud environment? I'm legitimately considering moving my security critical EC2 instances over to AMD-backed instance types right now.

scandinavian2• 7 years ago

I doubt that you both manage critical infrastructure on AWS and haven't read the AWS security bulletin.

https://aws.amazon.com/security/security-bulletins/AWS-2019-...

mettamage2• 7 years ago

I just want to plug their course hardware security (at the VU University Amsterdam). It's an amazing course and it costs 1200 euro's for students who need to pay full price. I've learned a lot about Spectre, Meltdown and novel forms of cache attacks and Rowhammer when I took it.

1Y3• 7 years ago

Offtopic: Are you familiar with the AI departments/ courses (master) at VU? I have the opportunity to go but haven't decided yet. (Interested in human-centred and modern ML with neural networks)

mettamage2• 7 years ago

Hey, yea I do have some familiarity. Send me an email to have a conversation, it's in my profile.

bigmattystyles• 7 years ago

Why doesn't this type of news cause INTC to tank - they're up today. I know the market is up today, but (and it's probably my innate overreaction) I would think this sort of news would cause its stock to suffer.

mda4• 7 years ago

I think there is an expectation that Intel's new generation CPUs wont have these vulnerabilities and they will sell these a lot more to replace the piece of crap they have sold for ridiculous prices. Intel is actually probably happy about these, because no one cares.

groovylick• 7 years ago

Intel have not been able to produce 10nm chips for 2 years now and they don't expect them until 2020. If the Ryzen 3000 leaks of a 15% IPC gain are proven to be true in a couple weeks then Intel is in real trouble. Add on additional performance losses with this mitigation and Intel is very likely to lose the top end of the CPU market for at least 2 years. INTC might look very different come the end of the month.

ct5208• 7 years ago

It should take a couple of days, also Intel is coming off continuous losses.

nodesocket2• 7 years ago

I follow the market and tech stocks pretty closely and it is extraditionary rate for breaches, vulnerabilities, or exploits to affect the stock price of companies despite the outrage from the tech community.

neop1x2• 7 years ago

Because it depends on customer behavior. Intel has a strong name and people know their CPUs are fast. We see various IT security problems almost daily and most people don't care... It would probably require some massive exploits, data leaks, identity thefts in cloud providers and following lawsuits againts Intel to see some significant stock price change. :)

cesarb3• 7 years ago

Some information for Linux, from LWN.net (https://lwn.net/Articles/788381/): "See this page from the kernel documentation (https://www.kernel.org/doc/html/latest/x86/mds.html#mds) for a fairly detailed description of the problem, and this page (https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/m...) for mitigation information."

morpheuskafka• 7 years ago

Is there any clear source of info for sysadmins responding to the many CPU-level vulns in the past year? It's very difficult to keep track of whether fixes are needed at ucode, OS, and/or application level, and what version numbers fix each bug.

p1necone• 7 years ago

I'm sure I remember a post on here (or possibly /r/programming) a couple of years ago from an Intel employee mentioning that Intel was cutting a lot of QA staff, and that we should expect more bugs in the future. I could be imagining things though.

ahartmetz• 7 years ago

I remember a leak about a call to become "more agile" like some ARM designers, implying less time spent on verification.

redrabbyte3• 7 years ago

verification wouldn't catch any of this, the processors operate correctly on an architectural level

most of this seems to be behaving as intended, they just didn't foresee the side channels this opens up

guido_vongraum3• 7 years ago

People should realize that ancient Chinese were оnto something when they told that all phenomena shall evolve only so much before they tip over the peak of maximum development and inevitably rumble downhill into overdevelopment.

P.S. the Holy Church of Progress keeps flagging the herecy of I-Ching out of existence, may it prevail in its glorious ways. Curious fact: expressing your disagreement in written form takes more neurons than flagging reflex does. Try and ye shall succeed!

dang4• 7 years ago

I like the I Ching too but could you please stop posting these and then deleting them? It's an abuse of the site.

guido_vongraum3• 7 years ago

I'll stop as soon as dysgraphic flaggers stop. The true abuse is muting a comment that doesn't offend anyone, just calling to contemplate a philosophy so different from the current mainline it hurts. Or does it? Are they triggered by 'people should'? Yeah, they should, but don't have to. Is the very notion of impossibility to improve things forever without changing their essence offensive? Any other reason, could you explain it, please?

flattone2• 7 years ago

crucial (for me anyway) summary of relevant events of the day

https://twitter.com/IanColdwater/status/1128395135702585347?...

userbinator2• 7 years ago

An unprivileged attacker with the ability to execute code

That sounds like a contradiction --- if you can already execute code, I'd say you're quite privileged. It's unfortunate that their demo doesn't itself run in the browser using JS (I don't know if it's possible), because that's closer to what people might think of as "unprivileged".

The attacker has no control over the address from which data is leaked, therefore it is necessary to know when the victim application handles the interesting data.

This is a very important point that all the Spectre/Meltdown-originated side-channels have in common, so I think it deserves more attention: there's a huge difference between being able to read some random data (theoretically, a leak) and it being actionable (practically, to exploit it); of course as mentioned in the article there are certain data which has patterns, but things like encryption keys tend to be pretty much random --- and then there's the question of what exactly that key is protecting. Let's say you did manage to correctly read a whole TLS session key --- what are you going to do with it? How are you going to get access to the network traffic it's protecting? You have just as much chance that this same exploit will leak the bytes of that before it's encrypted, so the ability to do something "attackful" is still rather limited.

Even the data which has patterns, like the mentioned credit card numbers, still needs some other associated data (cardholder name, PIN, etc.) in order to actually be usable.

The unpredictability of what you get, and the speed at which you can read (the demo shows 31 seconds to read 12 bytes), IMHO leads to a situation where getting all the pieces to line up just right for one specific victim is a huge effort, and because it's timing-based, any small change in the environment could easily "shift the sand" and result in reading something entirely different from what you had planned with all the careful setup you did.

Using ZombieLoad as a covert channel, two VMs could communicate with each other even in scenarios where they are configured in a way that forbids direct interaction between them.

IMHO that example is stretching things a bit, because it's already possible to "signal" between VMs by using indicators as crude as CPU or disk usage --- all one VM has to do to "write" is "pulse" the CPU or disk usage in whatever pattern it wants, modulating it with the data it wants to send, and the other one can "read" just by timing how long operations take. Anyone who has ever experienced things like "this machine is more responsive now, I guess the build I was doing in the background is finished" has seen this simple side-channel in action.

shittyadmin• 7 years ago

That sounds like a contradiction --- if you can already execute code, I'd say you're quite privileged.

If you're in a VM, you have no privileges over the host CPU, you can't switch to another VM or to the host itself. That's what's meant by unprivileged here.

kbenson• 7 years ago

if you can already execute code, I'd say you're quite privileged.

I always interpreted "privileged" to mean "superuser". I.e. unrestricted. Or possibly the case of one user and another user. Having a program that can determine the URL you are visiting in the browser from memory when running as the same user is a different class than something that can do the same when run as any non-root user on the system. There's a reason it's common to "drop privileges" in a daemon after any initial setup that requires those privileges (such as binding to a low port).

nodesocket2• 7 years ago

If using a cloud provider with Intel processors:

The safest workaround to prevent this extremely powerful attack is running trusted and untrusted applications on different physical machines.

Nope!

If this is not feasible in given contexts, disabling Hyperthreading completely represents the safest mitigation.

Nope!

Shrugs?

zelon88• 7 years ago

So far there seem to be far more of these vulnerabilities in Intel CPUs.

Is that a reflection of engineering differences or a statistical byproduct of the market share of Intel CPUs?

I run AMD not because of the security implications but because I feel every dollar that goes to Intel competition will push Intel and thus the entire industry forward.

dfrage18• 7 years ago

Market share is a good answer, in x86 space alone per https://www.extremetech.com/computing/291032-amd-gains-marke... which I found without putting much effort into it, AMD's share in servers is negligible and even dropped in the last quarter. On the other hand mobile and especially desktop are rising smartly, but still somewhat modest. IoT is excluded, and AMD could be doing well there to the extent anyone's using x86 for that, and there's also (quasi) embedded like network gear.

So the cloud vendors are 97% minimum Intel, they're exquisitely vulnerable both technically and reputationally to these bugs, the stakes are existential for them and they have a lot of money they can throw at the problem, whereas the users of notebooks and desktops are a much more diffuse interest.

As I've mentioned many times in these discussions today, everyone had Spectre issues, and everyone but AMD has Meltdown ones. The more recent vulnerabilities are Intel only because they're using what was learned from those first two to attack Intel specific features like the SGX enclave.

repolfx• 7 years ago

Probably both - AMD chips have lower market share because they have lower performance, and they have lower performance (maybe) because they speculate less aggressively. Intel did these optimisations for a reason after all; the market rewards them.

rhabarba• 7 years ago

Another non-issue on non-Intel CPUs, like SPARC. Lovely.

clarry2• 7 years ago

The best defense against all these CPU vulns is to stop running malicious code. And that means getting off of shared VMs (and similar) where someone could run malicious code in your stead. Stop running any script your browser gets handed. Isolation was always a great idea, poor man's isolation (VMs, processes, ...) is only useful for isolation against non-malicios accidental interference. You want physical isolation between applications and services.

fdfdde3• 7 years ago

OpenBSD was right and disabled HT for Intel CPUs in June 2018 ago due to concerns of more such CPU bugs coming up. There we go ... https://news.ycombinator.com/item?id=17350278

fluffything• 7 years ago

This. I remember people laughing at this decision back then, and flaming on OpenBSD policies to handling security vulnerabilities, to the point where they aren't informed anymore. Yet OpenBSD is the only major OS taking these issues seriously instead of believing whatever Intel marketing department yells every other day.

nathan_long• 7 years ago

These style of exploits remind me of "The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software" (2005) - http://www.gotw.ca/publications/concurrency-ddj.htm

Chip designers are under so much pressure to deliver ever-faster CPUs that they’ll risk changing the meaning of your program, and possibly break it, in order to make it run faster.
...
applications will increasingly need to be concurrent if they want to fully exploit CPU throughput gains that have now started becoming available and will continue to materialize over the next several years. For example, Intel is talking about someday producing 100-core chips; a single-threaded application can exploit at most 1/100 of such a chip’s potential throughput.

It seems the trend in programming languages is towards better concurrency support. But why don't we yet see 100-core chips? If chip makers had to forego all speculative execution and similar tricks, would that push us toward the many-core future?

ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs

Related Stories