
Speculative Dereferencing of Registers: Reviving Foreshadow [pdf] - beefhash
https://arxiv.org/pdf/2008.02307.pdf
======
spockz
Linux has flags that allow disabling mitigations to get performance back.
MacOS and Windows probably have the same. Pretty much the only thing that is
running unauthenticated workloads on my dev machine are my browser and mail
client. Is there a way to disable the mitigation’s globally but enable them
per process? I don’t mind much getting a 10-30% performance hit on browsing,
but I do mind when compiling/testing things.

~~~
rwmj
I'm going to say no, or at least, not easily. Some of the mitigations like
reptolines involve changing how the host kernel is compiled, and you can
obviously only do that once per machine. Separate kernel/user page tables is
one where there's a big overhead and it seems as if it could be possible to do
this per-process (ie. have some processes which do the "old way" and share the
kernel page table, while your hardened browser would use the slower separate
page tables). But the devil will be in the details and I'm no Andrea
Archangeli.

In my experience the biggest problem is something that cannot be solved by the
kernel anyway, which is the microcode updates. AFAIK it's impossible to get
that performance back by any means, even the mitigations=off flag cannot do
that.

Maybe look at QubesOS (it runs many desktop processes in separate virtual
machines) which will give you defence in depth, and mitigates many other
browser attacks as well as architectural ones. You could run your trusted
stuff outside Qubes (in the dom0) where it I guess ought to run at full speed.

BTW I solve this problem by having a separate development machine for
compiling and testing my own code which never runs anything untrusted. And
that other machine is an AMD Zen 2 so it's not quite so vulnerable and also
much faster for the price!

~~~
severino
> In my experience the biggest problem is something that cannot be solved by
> the kernel anyway, which is the microcode updates. AFAIK it's impossible to
> get that performance back by any means, even the mitigations=off flag cannot
> do that.

It is my understanding that these microcode updates get applied either by the
operating system at boot time (applying the update every time you boot), or by
the motherboard, if the BIOS was updated. As only this last method is
"permanent" (or at least it requires you to downgrade your BIOS, something not
always feasible) if you never upgraded your BIOS, I guess it should be
possible to prevent the OS from applying the updates.

~~~
user5994461
From my understanding, the microcode is the firmware of the CPU.

It's usually upgraded by a BIOS update or by Windows update. Windows update
send driver/firmware updates, security patches or general updates if the
vendor wants to support that way of distribution.

I think it's quite device specific and method specific whether the microcode
can be upgraded and downgraded the same way.

~~~
shawnz
The other poster is correct... microcode can be upgraded by BIOS update or
Windows update, but the update doesn't persist on the CPU itself after a
reboot (it has to be reapplied every boot, by either BIOS or Windows)

------
diskmuncher
A thought just came to my mind. Let's say 30 years ago, I said to a colleague
with whom I shared accesses to some Unix systems, "You know, I can use 'ps' to
see what processes you are running. If I know the details about certain flaws
of those binaries, I may be able to run a custom binary simultaneously on the
system and figure out some of your data!" Would he/she be surprised or
alarmed?

~~~
morelisp
30 years ago timing attacks were unknown (at least publicly). The core idea of
exfiltrating some secret based purely on specific input data to a program that
was memory-safe and perfectly validating its inputs would have been a surprise
on its own. Doing so entirely outside the process's direct view doubly so.

~~~
formerly_proven
The paper "A Retrospective on the VAX VMM Security Kernel" (1991) presents a
summary of analysing timing sidechannels in things like hard drive arm
movements as prior art from 1977 in section VI.E, while explicitly addressing
more usual timing side channels with various references to 1991 papers. One of
their solutions to address timing side channels was fuzzy time (seem
familiar?).

~~~
morelisp
Interesting! I have always seen timing attacks cited as originating in Kocher
(1994), but I suppose this is some bias towards the current Unix / PC / crypto
world away from mainframe development. The 1991 paper is quite clear, though
the 1977 paper it cites just kind of punts on the issue (end of section 3.6):

> Hence, it will not be possible to transmit information over a covert
> communication channel at a high enough bandwidth to make such attempts
> worthwhile.

Skimming the citations though, I'm not 100% sure it's the same thing as Kocher
(1994) which has a more direct line to Meltdown/Spectre. The idea that
intervals of high-precision clocks could carry information is the same, but
especially the KVM/370 paper seems concerned with it being used for
unmonitored communication between two malicious actors, or as a tool to learn
something generally about what other users of the system are doing, not
exfiltration of the the stored data itself across a security boundary with an
oblivious user. The 1991 paper seems to sit somewhere in the middle.

------
aspenmayer
Can we change the link to the actual paper?

Speculative Dereferencing of Registers:Reviving Foreshadow

Martin Schwarzl, Thomas Schuster, Michael Schwarz, Daniel Gruss

[https://arxiv.org/abs/2008.02307](https://arxiv.org/abs/2008.02307)

------
kristopolous
Is there a better article than this? Maybe I'm just tired but this doesn't
seem to be very coherently structured.

------
verroq
Direct link to research:
[https://arxiv.org/pdf/2008.02307.pdf](https://arxiv.org/pdf/2008.02307.pdf)

------
andy_ppp
Has anyone used these techniques in the wild to steal certificates from
another customer on AWS or use Javascript to start probing memory on my
machine from the browser? Are these attacks really severe or is it all
theoretical?

------
cel1ne
Side-channel attacks are an inherent property of computing hardware. You can
never fully "disguise" a computation as a different one or as no computation.

You can just lower the signal to noise ratio by various means, so you gain
some time until better statistical methods or clever tricks filter out the
signal again.

~~~
teruakohatu
There are side channels and there are side channels. A computer fan outputting
noise is a side channel that indicates both that a computer is running and may
indicate something about the workload, but if you are close enough to hear it,
you are close enough to do a lot more than listen to the fan noise so there is
no real more in suppressing it.

Isolated processes being able to determine the memory or computation of
another process is something else altogether and surley could be mitigated,
even if the mitigation comes at a cost.

~~~
xxs
You can have the fan on fixed rpms, hence the only side channel is that the
machine has power.

~~~
mschuster91
There's more. Vibration and electromagnetic emissions (TEMPEST) are also
viable side channels. Or ultrasound in speakers to cross airgaps.

------
dependenttypes
DJB wrote a paper about how "Speculative execution is much less important for
performance than commonly believed."
[https://arxiv.org/abs/2007.15919](https://arxiv.org/abs/2007.15919)

~~~
formerly_proven
The premise of the paper is not that branch prediction isn't important for
performance, but that it is possible to design an entirely different ISA where
it matters much less.

The idea here is to essentially create a branch delay slot instruction, which
then can be used to set the latency of a branch such that it doesn't require
prediction to not stall the pipeline. Like so:

    
    
        dec r1
        basicblock 5  # next five instructions WILL execute, branches after that, if any
        jz exit_loop
        this
        will
        always
        run
        -- branch takes effect here
    

Then the compiler may commonly reorganize the code such that the variable
branch delay instructions perform useful work.

~~~
gruez
The problem with techniques like this is that they're microarchitecture
dependent. The optimal amount of delay slots to have will depend how how long
the pipeline of the CPU is, for instance. This means that you'll always be
leaving performance on the table, because you have to cater to the lowest
common denominator, or change the isa and recompile everything

~~~
remexre
Maybe desktop applications will see something like what Android does, wrt
shipping applications as bytecode and doing the last stages of compilation on
the device, to get uarch-specific optimizations. CPU upgrades potentially
being traumatic would be a downside, of course...

~~~
gruez
We already have that, at least on windows with .net. Only problem is that
there's still native applications around for whatever reason. Even android
apks can contain native libraries.

~~~
remexre
Does that do AoT-compiling-on-install, or is it still just JIT? I thought the
JVM ecosystem was ahead on purely static binaries with Graal, but I might be
mistaken.

~~~
gruez
[https://docs.microsoft.com/en-
us/dotnet/framework/tools/ngen...](https://docs.microsoft.com/en-
us/dotnet/framework/tools/ngen-exe-native-image-generator)

------
scscsc
Some might enjoy a teaser video of related work by some of the same authors:
[https://www.youtube.com/watch?v=baKHSXeIIaI](https://www.youtube.com/watch?v=baKHSXeIIaI).
For context, the teaser was produced due to the conference going virtual
because of the pandemic.

------
wahern
The article's presentation of the research is completely wrong. There aren't
any new side channels here. All the paper purports to show (albeit in a
somewhat self-aggrandizing manner) is that the mechanisms for Meltdown and
Foreshadow were incompletely understood when _originally_ _presented_. But
there's nothing knew in the notion that speculative execution optimizations
are responsible for most side channels, nor that they played a role in
Meltdown and Foreshadow. "Spectre" is a play on words--it alludes to
speculative execution.

There aren't any major new exploits detailed in this paper. They introduce a
slightly new gadget for exposing data, but it can be and is mitigated by
existing techniques (e.g. retpolines). The only noteworthy aspect is that, as
it regards SGX, the mitigations haven't yet been generally applied. But new
ways to break SGX are a dime a dozen these days.

Interesting and rigorous work, but there don't seem to be any real
implications here. It's more like a more concise restatement of researchers'
present understanding, using the benefit of hindsight and some additional
footwork to fill in some small gaps.

~~~
verroq
> Beyond our thorough analysis of these previous works, we also demonstrate
> new attacks enabled by understanding the root cause, namely an address-
> translation attack in more restricted contexts, direct leakage of register
> values in certain scenarios, and the first end-to-end Foreshadow (L1TF)
> exploit targeting non-L1 data. The latter is effective even with the
> recommended Foreshadow mitigations enabled and thus revives the Foreshadow
> attack.

> We demonstrate that these dereferencing effects exist even on the most
> recent Intel CPUs with the latest hardware mitigations, and on CPUs
> previously believed to be unaffected, i.e., ARM, IBM, and AMD CPUs

~~~
wahern
> The latter is effective even with the recommended Foreshadow mitigations

That's different than saying it's effective even with mitigations required for
other Spectre-related exploits. When larger problems arise and more general
mitigations applied that _also_ happen to be better mitigations for previous,
narrower exploits, people don't usually make much effort to review and revise
old papers.

AFAIU, discovery of Meltdown slightly predates Spectre, or at least the point
at which the implications began to blow up. The Meltdown and Spectre papers
were published the same month Foreshadow was discovered and privately
reported. It seems two researchers were involved with both Foreshadow and the
earlier Spectre work, but that doesn't mean they would have or should have
fully grasped the deeper relationships. And all of this happened over 2 1/2
years ago. Since then researchers' understanding of the underlying issues has
improved greatly.

The tone of the paper is, I think, problematic. Just read footnote #1, which
self-defensively says: "Various authors of papers exploiting the prefetching
effect confirmed that the explanation put forward in this paper indeed
explains the observed phenomena more accurately than their original
explanations. We believe it is in the nature of empirical science that
theories explaining empirical observations improve over time and root-cause
attributions become more accurate."

So their presentation is "more accurate". And the writers of the 2+ year-old
papers readily admit it. All of which is another way of saying these were
already accepted, if not yet concretely expressed, beliefs in the research
community. There's much value in putting pen to paper and running confirmatory
experiments. But that doesn't make it groundbreaking.

EDIT: Regarding "We demonstrate that these dereferencing effects exist even on
the most recent Intel CPUs with the latest hardware mitigations, and on CPUs
previously believed to be unaffected, i.e., ARM, IBM, and AMD CPUs". If you
read closely it's clear that the context is Foreshadow, mechanism and
mitigations. They're saying that when Foreshadow was published those
architectures were believed immune. But applying the principles of their "more
accurate" understanding you can in fact achieve Foreshadow (or Foreshadow-
like) side channels on those architectures even with Foreshadow-specific
mitigations. But, again, only subsequent to the initial discovery of both
Foreshadow and Spectre did it became known that those architectures were more
susceptible to speculative execution attacks than originally understood. Thus
elsewhere in the paper it's admitted that more general and modern Spectre
mitigations also prevent these "new" Foreshadow exploits.

~~~
formerly_proven
> AFAIU, discovery of Meltdown slightly predates Spectre, or at least the
> point at which the implications began to blow up. The Meltdown and Spectre
> papers were published the same month Foreshadow was discovered and privately
> reported. It seems two researchers were involved with both Foreshadow and
> the earlier Spectre work, but that doesn't mean they would have or should
> have fully grasped the deeper relationships. And all of this happened over 2
> 1/2 years ago. Since then researchers' understanding of the underlying
> issues has improved greatly.

I'm under the impression that the side channels created by caches and
speculative execution have been known publicly (but with limited reach/impact)
as far back as the 90s. E.g. the 1991 paper "A Retrospective on the VAX VMM
Security Kernel" mentions data security problems and the creation of side
channels when processor caches are used.

------
Brosper
This website sucks, it attacked me with two newsletters popups. Definitely
shouldn't be on Hacker News.

