[Cryptography] RISC-V isn't the answer

[Tony Arcieri]

On Mon, Jan 22, 2018 at 2:34 PM, Bill Frantz <frantz at pwpconsult.com> wrote:
>
> The immediate question that occurs to me is, "How do we handle shared
> memory? Both R/O and R/W?".
>

For an architecture like lowRISC (based on Berkeley's Rocket RISC-V core, I
believe), the answer is, for every word of memory (i.e. 64-bits) include a
set of attribute bits that control a number of rich attributes. lowRISC
also features complete physical separation of control and data, meaning
that it should be physically impossible for these out-of-band tags to be
interfered with by program logic.

If we have a separate cache for each protection domain, then that domain is
> the only thing that can affect what is in that cache. Can we afford to
> fetch a shared word from a sister cache entry, or does that signal too much
> information? What about memory which is shared between mutually suspicious
> actors? (Probably R/O, but there may be uses for R/W.) There are a whole
> lot of questions.
>

Much in the same way Meltdown was mitigated using KPTI to check page-level
attributes, an every-word-tagged memory architecture could respect
word-level attributes. This gives you the benefits of having shared memory
with the same protections you might hope to gain from a coarsely-grained
partitioned cache.

In this sort of architecture, speculation units could proceed until they
hit a memory access violation, at which point the memory becomes
inaccessible as enforced (via a synchronous check) by the various memory
subsystems. This should prevent the sidechannel from even happening in the
first place (i.e. all memory subsystems synchronously deny access to the
CPU for requests with insufficient privilege), without placing an undue
burden on speculation unit designers.

One approach I like is a massive number of simple cores that don't
> speculate.


 This approach is where RISC-V soars today:
https://fuse.wikichip.org/news/686/esperanto-exits-stealth-mode-aims-at-ai-with-a-4096-core-7nm-risc-v-monster/

-- 
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180122/f2f8640a/attachment.html>