[Cryptography] RISC-V branch predicting

[Nemo]

Tony Arcieri <bascule at gmail.com> writes:

> On Mon, Feb 5, 2018 at 10:20 AM, Arnold Reinhold <agr at me.com> wrote:
>
> The core problem underlying both Meltdown and Spectre is the CPU is
> speculating outside the current protection domain, because access
> control protections on memory are not enforced synchronously 100% of
> the time.

This is the third time I have seen this misconception repeated on this
list. The first was from John Gilmore himself.

Once again: This characterization is accurate for Meltdown, but not at
all for Spectre. If you want to comment on this topic, please learn the
details of BOTH attacks first.

> Speculation units should proceed until they hit a memory access
> violation, at which point they should stop the current line of
> speculation, avoiding the problem of speculating outside the current
> protection domain strategically.

All CPUs other than Intel's already do this correctly, which is why none
of them were vulnerable to Meltdown in the first place.

Spectre is a completely different beast. It has nothing to do with using
speculative accesses bypassing memory protections.

Spectre works by poisoning the branch prediction tables, allowing an
attacker to trick "privileged" code into speculatively executing a path
that would never occur, speculatively or otherwise, during normal
execution. This allows the attacker to pump a firehose of information
through the already-existing (and still-existing) covert channel of
cache timing.

One of the original proof-of-concept attacks for Spectre was a
Javascript applet that could read arbitrary memory in the browser. Both
the applet and the Javascript runtime execute in a single process; there
are no memory access controls between the two in the first place.

Right now, countermeasures against Spectre fall into two categories:
Compiler options to eliminate indirect branches entirely (search for
"retpoline"), and instructions to flush the branch prediction tables
(used on entry to privileged code). Oh, and also disabling
high-precision timers in Javascript LOL

But these countermeasures are just squashing the particular attacks that
have been demonstrated. None of them address the underlying covert
channel(s), which appears to be a genuinely hard problem to tackle
efficiently.

 - Nemo
   https://self-evident.org/