
ZombieLoad: Cross Privilege-Boundary Data Leakage on Intel CPUs - Titanous
https://www.cyberus-technology.de/posts/2019-05-14-zombieload.html
======
fakwandi_priv
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...](https://www.nrc.nl/nieuws/2019/05/14/hackers-mikken-op-
het-intel-hart-a3960208)

~~~
close04
> 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?

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

~~~
cyphar
History would appear to prove you wrong[1]. Yes, Intel's stock price rebounded
that doesn't change that their stock price changed when the vulnerability
became public.

[1]: [https://qz.com/1171391/the-intel-intc-meltdown-bug-is-
hittin...](https://qz.com/1171391/the-intel-intc-meltdown-bug-is-hitting-the-
companys-stock-big-time-while-rival-amd-is-soaring/)

------
Fej
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.

~~~
cfallin
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.

~~~
Fej
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?

~~~
bitL
They have different cache architectures; Intel uses inclusive (i.e. all levels
contain keys from previous levels), AMD uses exclusive cache (each level
contains unrelated entries to any other level). This might have different
effects on classes of vulnerabilities they are prone to.

~~~
TomVDB
I know that some AMD CPUs a long time ago had exclusive caches, but for Ryzen,
I'm pretty sure that both L1 and L2 are inclusive, and L3 a victim cache.

------
nine_k
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...](https://www.cyberus-
technology.de/posts/2019-05-14-zombieload.html)

~~~
waddlesplash
And here's the mitigation in NetBSD:
[https://github.com/NetBSD/src/commit/afab82aeafd0c51afc036a8...](https://github.com/NetBSD/src/commit/afab82aeafd0c51afc036a8b35dd0ed428b2885b)

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_k
Hopefully with this patches for other OSes should appear soon.

------
daeken
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.

~~~
xondono
Security by obscurity is no security

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

~~~
bayindirh
Confidentiality is a valid layer of security, however security _solely by_
obscurity is wrong.

You can have unintentional exploits/vulnerabilities in free/open source
software or hardware too.

------
yalok
> 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](https://support.apple.com/en-us/HT210107)

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

~~~
yalok
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...

~~~
FluffyKitty
It really is going to depend on what test you are running. HT has the greatest
effect when the running process has a lot of "downtime" for things like memory
retrieval or any I/O as it allows for other processes to make use of this
downtime. So if your tests are just doing calculations with very little
file/network I/O it could very well be in the 9% range.

~~~
ct520
The best of the worst case. Gotta love that Intel spin machine working in
overdrive

------
IgorPartola
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?

~~~
dragontamer
> 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.

~~~
IgorPartola
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?

~~~
dragontamer
MMap'd files, and... in-demand paging... are pretty much on every CPU
architecture worth making an application for. ARM, POWER9, X86, SPARC, MIPS,
and more.

In-demand paging is another situation where a simple pointer-dereference can
suddenly turn into a filesystem (and therefore: kernel-level / hardware-level)
call.

------
jamiek88
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
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.

~~~
saltcured
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.

~~~
jdmichal
AKA a barrel processor:

[https://en.wikipedia.org/wiki/Barrel_processor](https://en.wikipedia.org/wiki/Barrel_processor)

------
cesarb
Some information for Linux, from LWN.net
([https://lwn.net/Articles/788381/](https://lwn.net/Articles/788381/)): "See
this page from the kernel documentation
([https://www.kernel.org/doc/html/latest/x86/mds.html#mds](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...](https://www.kernel.org/doc/html/latest/admin-guide/hw-
vuln/mds.html)) for mitigation information."

------
dschuetz
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
Interestingly AWS released a bulletin about MDS vulnerability but nothing
about ZombieLoad yet. [https://aws.amazon.com/security/security-
bulletins/AWS-2019-...](https://aws.amazon.com/security/security-
bulletins/AWS-2019-004/)

~~~
scandinavian
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.

------
jniedrauer
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.

~~~
scandinavian
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-...](https://aws.amazon.com/security/security-
bulletins/AWS-2019-004/)

------
INTPenis
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.

~~~
strmpnk
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
Yes the T495 and the X395 ought to be the best ones.

------
mda
Looks like AMD Cpus are safe again.

~~~
harryh
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.

~~~
makomk
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.

~~~
kentonv
> 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.

No, AMD has been largely immune to bugs involving speculating past a _page
fault_. Both Meltdown and L1TF involved speculating past page faults, and the
ZombieLoad paper also mentions exploiting bad behavior during page faults
(but, disclaimer, I haven't read in enough detail yet).

AMD was not immune to, for example, spectre variant 2, which very much did
allow reading from other address spaces (even other VMs):
[https://www.amd.com/en/corporate/security-
updates](https://www.amd.com/en/corporate/security-updates)

In general it doesn't make sense to expect that any brand of processors might
be vulnerable or invulnerable to all illegal memory access. There are many
different components involved in handling memory access and many different
ways they could go wrong.

~~~
makomk
Spectre variant 2 was a little more interesting in that it can trick the
processor into speculative execution of something that's not a valid execution
path for the victim context (by confusing it about the target of an indirect
branch), but it still relies on the speculative execution happening in a
context that is meant to have access to the targetted data. It's sort of
halfway between this and the other Spectre variants; it can be fixed in
hardware or software.

All three of these latest vulnerabilities are like Meltdown and L1TF in that
they just allow speculative execution to completely ignore hardware-level
access protections and read data from a completely different process, and
there's nothing that can be done about it at the software level. (Originally,
the comment you're replying to was posted on a discussion about all three, if
I remember rightly.) All of these affect Intel but not AMD. It's not like
modern AMD chips are exactly poor performers either.

~~~
kentonv
> All three of these latest vulnerabilities are like Meltdown and L1TF in that
> they just allow speculative execution to completely ignore hardware-level
> access protections and read data from a completely different process

Not really. These attacks are completely different from Meltdown and L1TF in
that they don't involve reading from memory at all. They involve hidden
processor state that contains values that were recently used in another
context. The attacker never explicitly specifies an address they are
interested in -- they just get whatever's floating around.

A comparable (but much more obvious) bug would be if the OS failed to clear
registers when switching contexts. Although the values in those registers may
have at one point been read from memory, the attacker recovering those values
isn't directly accessing the victim's memory.

Your comments seem to be arguing that AMD isn't affected by these bugs for the
same reason they weren't affected by Meltdown. But these bugs operate in a
totally different way and exploit totally different components. There doesn't
appear to be any reason to believe they are related.

I think the reason AMD isn't affected likely has to do with the fact that
these attacks are targeting specific implementation details of Intel
processors, which AMD processors probably just happen to implement
differently. (Indeed, Fallout appears to be attacking outright unintentional
behavior -- it would be surprising if multiple CPUs had the same bug.) It
seems likely to me that AMD has different bugs which haven't been found yet,
perhaps mostly because researchers haven't focused on them.

(Disclosure: I own some AMD stock. I don't own Intel stock. I have no other
affiliation with either company.)

~~~
makomk
The "hidden processor state" is the memory contents belonging to other
processes, stored as part of the CPU's memory access machinery. Every single
one of these vulnerabilities involves Intel speculatively filling memory read
requests from one process with data from another process without doing access
checks first, and it turns out they do this all over the place: they do it
from L1 cache, they do it if there's an L1 cache miss, they do it when the
actual desired memory is uncacheable, they do it with store-to-load
forwarding... almost every conceivable method of fulfilling a memory read on
modern Intel CPUs is happy to speculatively leak secret data from other
processes that shouldn't be accessable. More interestingly, AMD don't seem to
do this anywhere that anyone's been able to find. (Well, technically that's
not quite true... there's a speculative bypass of x86 segment limits on AMD
which no-one cares about because no-one uses those anyway.)

------
fdfdde3
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](https://news.ycombinator.com/item?id=17350278)

~~~
fluffything
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.

------
bigmattystyles
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.

~~~
mda
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
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.

------
justryry
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.

~~~
jupp0r
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
> 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.

------
shereadsthenews
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
_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".

------
p1necone
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
I remember a leak about a call to become "more agile" like some ARM designers,
implying less time spent on verification.

~~~
redrabbyte
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

------
S_A_P
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
It should read:

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

The number of mistakes in the Techcrunch article is atrocious.

~~~
ficklepickle
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.

~~~
toomuchtodo
Thank you for your service!

~~~
xondono
I know this comment adds nothing of value but I have to quote it anyway

“Service guarantees citizenship, want to know more?”

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

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

~~~
mattashii
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-...](https://aws.amazon.com/security/security-
bulletins/AWS-2019-004/)

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

[3] [https://www.intel.com/content/www/us/en/security-
center/advi...](https://www.intel.com/content/www/us/en/security-
center/advisory/intel-sa-00233.html)

------
nathan_long
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](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?

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

[https://twitter.com/IanColdwater/status/1128395135702585347?...](https://twitter.com/IanColdwater/status/1128395135702585347?s=20)

------
mettamage
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
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)

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

------
morpheuskafka
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.

------
spockz
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.

~~~
rurban
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...](https://software.intel.com/security-software-
guidance/software-guidance/microarchitectural-data-sampling)

~~~
tux1968
> 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?

~~~
rurban
verw and l1d_fence have no costs. lfence is a bit costly, mfence is basically
an lfence + sfence. it flushes both caches, load and store.

safe libs need to do the right thing, not the fast thing. esp. crypto.

The attitude of libc and crypto maintainers is that you cannot trust them with
security. all the memzero's are insecure. besides being overly complicated and
slow. Linux is a bit better, but there are still estimated 20.000 security
relevant bugs.

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

------
zelon88
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.

~~~
dfrage
Market share is a good answer, in x86 space alone per
[https://www.extremetech.com/computing/291032-amd-gains-
marke...](https://www.extremetech.com/computing/291032-amd-gains-market-share-
in-desktop-and-laptop-slips-in-servers) 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.

------
nodesocket
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?

------
clarry
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.

------
userbinator
_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.

~~~
kbenson
> 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).

------
gmueckl
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).

~~~
Tharkun
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.

~~~
gmueckl
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).

~~~
jancsika
I'm not a security person but I wanna practice trying to sum up his points:

1\. There's no way in hell that a bunch of VMs running on one physical server
is more secure than a bunch of different physical servers each running an OS.
If there were architectural hooks for those VMs to provide additional security
beyond what the host OS provides, then an OS like OpenBSD would already be
making use of it.

2\. Running a bunch of VMs on a single physical machine is certainly
_cheaper_.

3\. People who are in favor of the cost-cutting are claiming that there's a
security benefit to sell more stuff.

Am I right?

If so, how does that stance jibe with the research that Qubes is based on?

~~~
fwip
I think the argument VM-sellers make is that it's more secure than running a
bunch of colocated code on the same machine without VMs, not that it's more
secure than distinct physical systems.

~~~
bluGill
That is their claim. Theo is pointing out that the security is an illusion.
Either the OS is secure and so you may as well just run everything in the OS
without the VM in the way (ignoring issues of different operating system), or
the OS is not secure and now you have to hope the VM is secure because
otherwise you just exploit your VM to get out of it and then exploit the OS.
The second level attack is more difficult, but that is all.

------
ksec
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
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
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](https://marc.info/?l=openbsd-
misc&m=118296441702631&w=2)

~~~
jawnv6
you sure about that link? he's talking about a core that didn't have SMT and
is ranting, in general, about errata existing and wildly misrepresenting their
impact

never mind that most errata are conditional until the ucode patch load, but
that particular rant has nothing to do with HT

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

[https://meltdownattack.com/](https://meltdownattack.com/)

------
dang
Url changed from [https://zombieloadattack.com](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](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.

~~~
makomk
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.

------
mr_overalls
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...](https://www.theguardian.com/world/2014/jul/15/germany-typewriters-
espionage-nsa-spying-surveillance)

~~~
gambler
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.

~~~
nickpsecurity
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/](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.

------
guido_vongraum
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!

~~~
dang
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_vongraum
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?

