<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 13/01/18 12:21 PM, D. Hugh
Redelmeier via talk wrote
</div>
<blockquote type="cite"
cite="mid:alpine.LFD.2.21.1801131114260.12598@redeye.mimosa.com">
<pre wrap="">Now we get to Branch Target Injection, the second form of Spectre.
The indirect branch case is much trickier. An indirect branch is
one where the target is not manifest in the instruction. Instead, it
is somehow computed. Think:
- call through a function pointer variable
- method call in an object oriented language (a call through a
function pointer, at least in the general case)
- a return from a function
- a case statement
Fast processors nowadays predict where such a branch will lead. The
heuristics used can be outsmarted by carefully crafted code and led
to speculate ANYWHERE in the address space. This is awesomely scary.
You cannot add protective code on the target because there is no
single target. This has similarities to the attack exploitation
method called "Return Oriented Programming": the attacker just has to
find a useful code fragment somewhere in your codebase and aim the
branch target prediction towards it.
Google researchers have devised a trick to prevent indirect branch
misprediction from doing a bad guy's bidding. They constructed a
"retpoline" that essentially ties up misprediction in a harmless bit
of code. See the "Construction (x86)" section of
<a class="moz-txt-link-rfc2396E" href="https://support.google.com/faqs/answer/7625886"><https://support.google.com/faqs/answer/7625886></a>
The cost is an ugly piece of code and no useful speculation.
---
Talk Mailing List
<a class="moz-txt-link-abbreviated" href="mailto:talk@gtalug.org">talk@gtalug.org</a>
<a class="moz-txt-link-freetext" href="https://gtalug.org/mailman/listinfo/talk">https://gtalug.org/mailman/listinfo/talk</a>
</pre>
</blockquote>
<p><font size="-1">Thanks, Hugh!</font></p>
<p><font size="-1">Oracle and Fujitsu (who actually make the chips)
still hasn't said which machine types will suffer from
speculation attacks, but did implement a hardware cache change
recently in the M7 and M8 series (the conventional,
glow-in-the-dark 5 GHz chipsets that speculate wildly) which
they market as "Silicon Secured Memory". <br>
</font></p>
<p><font size="-1">It reads as if they've been having trouble with
"invalid [memory references], stale memory reference and buffer
overflows", and have added microcode to cause SEGVs before the
data arrives if you try to fetch a cache line that isn't the
same "version" as your process. Version sounds like a short
value used like a pid, but don't quote me on that: the papers
are written by marketers, not engineers (;-)) <br>
</font></p>
<p><font size="-1">See
<a class="moz-txt-link-freetext" href="https://blogs.oracle.com/partnertech/sas-and-oracle-sparc-m7-silicon-secured-memory">https://blogs.oracle.com/partnertech/sas-and-oracle-sparc-m7-silicon-secured-memory</a></font></p>
<p><font size="-1">--dave<br>
</font></p>
<pre class="moz-signature" cols="72">--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
<a class="moz-txt-link-abbreviated" href="mailto:davecb@spamcop.net">davecb@spamcop.net</a> | -- Mark Twain
</pre>
</body>
</html>