[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Cryptography] Does RISC V solve Spectre ?
- From: Henry Baker <hbaker1 AT pipeline.com>
- Subject: Re: [Cryptography] Does RISC V solve Spectre ?
- Date: Sat, 24 Mar 2018 09:52:09 -0700
- Arc-authentication-results: i=1; mx.google.com; dkim=neutral (body hash did not verify) email@example.com header.s=dk12062016 header.b=MoLZ0K+x; spf=pass (google.com: best guess record for domain of cryptography-bounces+ben=bentasker.co.uk AT metzdowd.com designates 2001:470:30:84:e276:63ff:fe62:3500 as permitted sender) smtp.mailfrom=cryptography-bounces+ben=bentasker.co.uk AT metzdowd.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=pipeline.com
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:content-transfer-encoding:cc:list-subscribe :list-help:list-post:list-archive:list-unsubscribe:list-id :precedence:subject:message-id:mime-version:from:to:date :domainkey-signature:dkim-signature:delivered-to :arc-authentication-results; bh=69TqavDuDBZaij/bPgg1Ym6Ro6pT2dLjAUHXoKSvGVQ=; b=k002KN0d+vFMcmCDFhNVfF9kEalrugSByJ+sWWAyp+xEgvJ7P8SaWZUecPaGG80vkQ +8dnk4+EPa510hVwKhL97mcZMEKbu3/n2SEhSJi3mae3n/caLqrri/cAkCrLKgEeSKE4 jvXgF7fQ5SMvyBd7P8Pp8VZ9H+Jm9818MynSGWH2HJp36i70GT9mH/n0FJ/bXWtCfmqs Owtg3B7R6na7vbD73Rv/o+6xSLZpnYDDUV61p1+1UXnY+6W5oBCLHN8gvOqE3G+WZgIM UUVqKjt5C720VnL8Gln1m/GdI0luzqzG0yCyBryXgiDGwjr4qx2kri63QRatUZWDmZ/f qQEg==
- Arc-seal: i=1; a=rsa-sha256; t=1521925760; cv=none; d=google.com; s=arc-20160816; b=oxOyopCLc/2O3gu+tBDrxCWI8qzoeqzax1rHF/qenWrrk9s78XAYL+IBRlLaHUZ2sB K2HJVj65GYFQ0zh1YoeRmy1lnFT4bw4UahWPgVuyp03xHwpHNrLmKjiD68AOYQmqMupE o3un2DbWDLv0m5AJera+G2MjL3nlguqcipOur0Jiudsl3IdRYKy2X3PSgmu517wurW+S +D5+2qwQh4UkKhl1+AK0o4vbsl7kTxybSWwaEcArLP7iP/iymYZ2eWBnvS7Gzmb3ChZd 3uDCWVfNsAFYOfEkn4K5fMXZR2sc+nejVdDZ2YuMKshSy8VG8epSVIWYekvsQsWBVfxr tQbA==
- Cc: cryptography AT metzdowd.com
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=pipeline.com; b=NSVKtYxzuMZA2YAc69Q/VmgKIkxFk6XE1Y54ootHGmwmENp5hIG1I84d19wTyJElAR/S9K5kX/OIrmD5SrbiV1072zS92lYuovbvY5acPk+YHQZuMe9E5SaM+Z3gnllqsrseteuxA0ZP2z1ogUUknukSuRSZKJM8JoFfgcDN3HIZgmLfCqtIALMHV6EgUXsMdUTV/UPW5XjHe8p80W0z7fJWlgYuQWQHTfen76lX5nAxIlDVZWgrzEQZMjbVdDiaECHkxTYUM5wnb+MNCv/PV8tUGtKdDvA3YeSZ5DoWv1OFQ7xDZHYFCgZA1AnRBvuGD/0kXdqfwDaPMmIifHOJlg==; h=Received:X-Mailer:Date:To:From:Subject:Cc:Mime-Version:Content-Type:Message-ID:X-ELNK-Trace:X-Originating-IP;
- List-archive: <http://www.metzdowd.com/pipermail/cryptography/>
- Sender: "cryptography" <cryptography-bounces+ben=bentasker.co.uk AT metzdowd.com>
- To: Ray Dillinger <bear AT sonic.net>
At 07:40 PM 3/23/2018, Ray Dillinger wrote:
>From: Ray Dillinger <bear AT sonic.net>
>On 03/23/2018 06:05 PM, Henry Baker wrote:
>> Great idea.
>> Let's see how well it works in practise.
>> # stuff finally shows up at yyyyy in the cache at this point in time
>> # I just received this $$$ box from Amazon that I ordered 5 months ago.
>> # I can't remember what I was doing at the time, or why I ordered it.
>> # Well, gotta go now, so throw it in the trash or give it away.
>You're being facetious of course. Compilers don't need to "remember"
>what they were doing and why they asked for data to be precached; like
>every other instruction, pre-caching instructions are generated in the
>first place from the actions and reasons.
>But obviously you know that. So you must be making a joke but I don't
>know what you're making a joke about.
>Determining when to undertake these actions is not too hard for the
>logic overhead expressed in silicon which presently runs during the code
>execution. Moving that overhead to the compiler doesn't make it more
>complex than it already is.
Yes, I was being facetious, but there are human analogies to what's
going on in a compiler for a deeply pipelined machine.
Let's talk about the compiler for a moment.
You are correct that it is relatively easy for a compiler to compile
for a pipeline (I've written such a compiler) -- so long as there
aren't any branches or loops. However, in the presence of branches
or loops, we can no longer predict in advance at what point in
the branch nest or loop body when (or if) a value will be needed.
This is the compiler equivalent of being unable to schedule my
day(s) waiting for the cable guy or the Fedex gal to show up.
(Yes, the Fedex gal sometimes requires a signature.)
But for the compiler to schedule a value which will show up 200
(or more) instructions in the future is the equivalent of me trying
to schedule a visit 200 days in advance for someone arriving from
Mars. Or perhaps think of scheduling visits in the 15th Century,
when every trip took days, weeks months or years.
(A modern Army general has commented on the plight of his ancient
Roman counterpart: "When one of your generals goes over the
horizon with his army, you're not going to hear from him for a
number of months. You have to delegate authority, and you have
to be prepared to send *another general and another army* to
rescue him and/or defeat him if anything goes wrong.)
There's a physics T-shirt that reads "Time is nature's way
to keep everything from happening at once" -- Wheeler.
Perhaps computer architects need their own T-shirt; here
are some suggestions:
"A foolish consistency is the hobgoblin of inorder processors
... With consistency, a great processor simply has nothing to
"We choose mania over boredom every time." -- James Gleick
"Never underestimate the determination of a CPU who is time-rich
and cache-poor" -- Cory Doctorow
"Boredom, that traitorous devil that possesses us to do things
sometimes useless, and often stupid." Apol Lejano-Massebleau
"Boredom is what you dread most in the world, and yet, I
assure you, there are worse things." -- Agatha Christie
"When action grows unprofitable, gather information;
when information grows unprofitable; sleep" -- Ursula Le Guin
"Whoever sleeps long, does not sin." -- Martin Luther
The cryptography mailing list
cryptography AT metzdowd.com