Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"Nature is very un-American. Nature never hurries." -- William George Jordan


devel / comp.arch / Re: Retpoline cost

SubjectAuthor
o Re: Retpoline costEricP

1
Re: Retpoline cost

<3FalI.84511$Ms7.70457@fx34.iad>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=16508&group=comp.arch#16508

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news-out.netnews.com!newsin.alt.net!fdcspool1.netnews.com!fdc2.netnews.com!news-out.netnews.com!news.alt.net!fdc3.netnews.com!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx34.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: Retpoline cost
References: <2021Mar20.232623@mips.complang.tuwien.ac.at> <s360mv$re6$1@dont-email.me> <2021Mar22.084247@mips.complang.tuwien.ac.at> <7461dddb-72a3-4a4d-b0c4-cdea83d966fbn@googlegroups.com> <98d722e5-7b1e-49a9-a516-866effc500d8n@googlegroups.com> <2021Mar25.114153@mips.complang.tuwien.ac.at> <Or07I.11663$NR7.2489@fx03.iad> <2021Mar25.162302@mips.complang.tuwien.ac.at> <_n37I.6644$S46.6414@fx29.iad> <2021Mar25.193051@mips.complang.tuwien.ac.at>
In-Reply-To: <2021Mar25.193051@mips.complang.tuwien.ac.at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 53
Message-ID: <3FalI.84511$Ms7.70457@fx34.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Fri, 07 May 2021 12:46:55 UTC
Date: Fri, 07 May 2021 08:46:37 -0400
X-Received-Bytes: 3370
 by: EricP - Fri, 7 May 2021 12:46 UTC

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> Anton Ertl wrote:
>>> Yes, that's a typical case for an in-order CPU. And that normally
>>> means that the load-load (or more typically load-ops-load), with all
>>> instructions speculative, that Spectre v1 and v2 perform cannot
>>> happen.
>> It might allow loads and stores to speculatively prefetch to D$L1.
>
> Sure, but Spectre needs that for the second load.
>
>> It is possible to allow in-order loads to execute speculatively
>> and allow eager operand forwarding to dependent uOps,
>> but not update the load dest register until writeback.
>> That could allow dependent uOps to move beyond register read
>> and begin executing early rather than waiting for the load
>> to reach writeback.
>
> Yes, this forwarding is a standard technique. But getting a second
> load far enough to update the D-cache?
>
> Well, I can now imagine an in-order design that's vulnerable to
> Spectre:
>
> 1) Branches only resolve very late (to avoid stalls when the thing it
> depends on resolves late, and because branch predictors are good).
>
> 2) A deep execution pipeline with forwarding (so we can have
> load-ops-load in speculative execution) where everything that enters
> runs to conclusion even if the result is canceled.
>
> 3) A load changes the cache even when canceled; either an LRU update
> (but Cortex-A8 has random replacement) or even on a canceled cache
> miss.

There is some stale info on ARM's in-order speculation attacks from 2020.
While they acknowledge 1 or 2 load instructions can speculatively
execute after a branch mispredict but before the pipeline gets flushed,
however they don't describe the exact mechanism.

ARM has a page on speculative vulnerabilities:
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads

One of which ARM call "straight-line speculation" from June-2020:
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation

A variant found by third parties:

Speculative Leakage in ARM Cortex-A53, July-2020
https://arxiv.org/abs/2007.06865

1
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor