[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: Sun, 25 Mar 2018 09:30:20 -0700
- Arc-authentication-results: i=1; mx.google.com; dkim=neutral (body hash did not verify) email@example.com header.s=dk12062016 header.b=UOqeKvZQ; 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:references:in-reply-to :from:to:date:domainkey-signature:dkim-signature:delivered-to :arc-authentication-results; bh=50KHuYgtC3+m9SSFfUjm/7AO+2M0pbQOjgEHb6pjioE=; b=ScIUZIzlzEqjK/cDmVcr2+L15TKCH22gy4xzyak+e3pjZQ/onTemSN1fNyxxypuwir 58M7XOUYT6NWqIG6go4+gJL4Vf2sb3AUYLW4rrCq1qLDbO6vVqeZWuuZB4oyavwGVaCO TUrsWVu78BktwS2pb5M5N6Pms+GcNQmYqE8uUKlPXv1TFmMYTMyculxth8Llm7JMnUP7 9Tdx5cdptXA8RjNn49FmVh5pkDTL9WYgqCNpx/Y9yQbD6rAgaJeSZAELzUWixy44GI3C NlJjX17jhWhH+dA0tH2UCpT3+L/NjyzLJgLjulKqt/hX3XFSihUMQKR2hchhKGQnBGRd j4wQ==
- Arc-seal: i=1; a=rsa-sha256; t=1521998131; cv=none; d=google.com; s=arc-20160816; b=TqjPfZR6zVtCOrx1O23gcqpo6/2+rjHC4nRmrG/2hYykxLns8OgISUiGwSi28pcAJJ 4Z+jt5GXQWJzvIdnUuhYo05AbmLNpMjlga4WI2QAYYjNXqwbbQiutmPhfc1Hb/ltZWmp EMY8NdHxONki9H69Dm44TWcY+2704sfWhZ/EvJmtiPOHUrrTZ6CmCPVBQga62Ea9B9Zp P03+y6mlp2gqDL/BJgPhf/G8zHZidpy2wm69+Fu/C4Mpm/3GNp/DbzX2X5tFqdPUFvTN JQDkAtb+tY4568b7/owUfmnVmhHPKZ5K5SPn/gbsBE+qJ0wXDmp9vCzvsohOtKWtG0bb c5jA==
- Cc: Ray Dillinger <bear AT sonic.net>, Crypto <cryptography AT metzdowd.com>
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=pipeline.com; b=iN7DxVNJSmF4tOvbGUJsBedK8fLSKNXZ9hSNWbuPf1+Sz78CDlb7FrHLL4LWzic69LrjgJOuF3EiPTxLLM0Qn9/6QvOGCrVDeKcxNo1khiLmpCi47tGK1IZPwvCeWmNvF9xPcTdxbtq5D77bNoKOCn4I1Kj5gIES8tEa6EOcNDwQHQ5/4dYnTPDpJNuhj6lgTVthrEIorDTgK1KrQpq8od5XWYXgBarY0SPubp28RKPo+5SDMYnJixP/9H8FJnEc2RYDxJyF9ULFiNLl8+HZFUaRRdE/z7Z+qBx30JIWjR1M5CvTE0koGCl6ogAdgvNlRBmEo5vm+ZkBC+Je/UKIpQ==; h=Received:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References: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: Jerry Leichter <leichter AT lrw.com>
At 06:49 AM 3/24/2018, Jerry Leichter wrote:
>Of course, with the rise of JIT compilation, perhaps this is no longer an issue.
>It would make for an interesting experiment.
>The JIT compilers I'm aware of do little to accommodate hardware variations - though perhaps they feel they don't need to, because those details don't much matter in the machines and for most code we actually use today.
OpSec? We need to worry about OpcodeSec!
nVidia's "Dynamic Code Optimization"/"DCO", aka Humpty Dumpty theory of ISA: "When I use an instruction, it means just what I choose it to mean--neither more or less." Alice: "The question is, whether you can make instructions mean so many different things."
"DCO": Yet more lovely places for malware to hide. The executing code is "translated" into a microcode buffer, but who gets to be in charge of said translation?
"Those who write the code decide nothing. Those who execute the code decide everything." -- apologies to Josef Stalin
I believe that these DCO processors have already been picked up for widespread use in automobiles, including self-driving cars.
What, me worry?
Above is a message I sent over a year ago about nVidia's new "DCO" mechanism, where the standard computer op codes are merely a gentle hint/suggestion about what the CPU should actually do. Behind the scenes, "DCO" can re-interpret your *hardware op code* to do anything it damn well pleases. This is the opcode equivalent of *memory maps*, which merely provide gentle hints/suggestions about where to fetch instructions.
See the Youtube video link above for more details.
Stanford EE Computer Systems Colloquium
4:15PM, Wednesday, March 4, 2015
NEC Auditorium, Gates Computer Science Building Room B3
Dynamic Code Optimization and the NVIDIA Denver Processor
Nathan Tuck NVIDIA
About the talk:
NVIDIA's first 64-bit ARM processor, code-named Denver, leverages a host of new technologies to enable high-performance mobile computing. Implemented in a 28-nm process, the Denver CPU can attain clock speeds of up to 2.5 GHz. This talk will outline the Denver architecture and describe some of its technological innovations. In particular this talk will discuss some of the motivations and advantages of dynamic code optimization.
There not downloadable slides for this presentation available at this time.
View Video on YouTube.
About the speaker:
Nathan Tuck has been a member of the DCO and CPU architecture teams at NVIDIA since 2009.
Nathan has spent his professional career walking a crooked line between hardware and software. As an engineer, he is most interested in working on systems problems. Professionally, he is most interested in dynamic environments where he can make a large difference.
The cryptography mailing list
cryptography AT metzdowd.com