[libre-riscv-dev] [Bug 209] spectre-proof speculative execution

[libre-riscv-dev] [Bug 209] spectre-proof speculative execution

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=209

Yehowshua <yimmanuel3@gatech.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yimmanuel3@gatech.edu

--- Comment #3 from Yehowshua <yimmanuel3@gatech.edu> ---
According to the Spectre paper here: https://spectreattack.com/spectre.pdf

there are multiple Spectre style vulnerabilities. I will focus here on Spectre
variant 1 from the paper.

The solution I present below comes from the Solutions section of the paper in
"Mitigation Options".

Variant 1 of the attack can be prevented by having commit buffers from L2 or
memory to L1 during speculative execution, and by having a commit buffer from
reg to L1.

Its all about making sure that cache is reverted during L1 so that you can
cache flushes cannot leak sensitive information.

Oh, and cache flushes should be disallowed during speculative execution.

The timing concept you describe

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 209] spectre-proof speculative execution

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=209

--- Comment #4 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Yehowshua from comment #3)

> Its all about making sure that cache is reverted during L1 so that you can
> cache flushes cannot leak sensitive information.

so basically this extends the Dependency Matrix "Shadow" concept actually
right down into the Caches.

(if a Shadow exists it is because there is some "damage" that could occur due
to cancellation).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] [Bug 209] spectre-proof speculative execution

[Yehowshua]

> On May 18, 2020, at 3:24 PM, bugzilla-daemon@libre-soc.org wrote:
> 
> so basically this extends the Dependency Matrix "Shadow" concept actually
> right down into the Caches.

Exactly - keep in mind that this is only for variant 1.
I’ll read up on the other variants later.

Why do CPUs have to be so complicated...

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] [Bug 209] spectre-proof speculative execution

[Luke Kenneth Casson Leighton]

On Mon, May 18, 2020 at 8:25 PM Yehowshua <yimmanuel3@gatech.edu> wrote:

> > so basically this extends the Dependency Matrix "Shadow" concept actually
> > right down into the Caches.
>
> Exactly - keep in mind that this is only for variant 1.
> I’ll read up on the other variants later.
>
> Why do CPUs have to be so complicated...

Hugh said on one of the Virtual Coffee Calls, he's been in touch with
the IBM engineers for many years.  back when they first met, they told
him - straight up - that CPU design is hard.  however - it took
several years for him to properly and actually appreciate that when
they said "hard" they did not mean it in the ordinary sense of
"certain kinds of software engineering problems are hard", they meant,
like, REALLY hard.

this is why i recommended that we go with python, because not only can
we apply OO (Object-Orientated) techniques, we tap directly into the
"default mindset" behind python, which is that you *do not* write code
- ever - without having an adequate unit test.

this in combination with patiently following Mitch's advice of
drilling down to first principles, i am confident that we'll do fine.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 209] spectre-proof speculative execution

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=209

--- Comment #5 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
On Mon, May 18, 2020 at 8:25 PM Yehowshua <yimmanuel3@gatech.edu> wrote:

> > so basically this extends the Dependency Matrix "Shadow" concept actually
> > right down into the Caches.
>
> Exactly - keep in mind that this is only for variant 1.

there may still be some impact.  reduction in TLB entry availability
may cause timing alterations.

the L0 Cache/Buffer *might* actually be the accidentally-already-designed
place where speculation stops.  i stress "might".

> I’ll read up on the other variants later.
>
> Why do CPUs have to be so complicated...

:)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 209] spectre-proof speculative execution

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=209

--- Comment #6 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
actually, you know what?  collating all "shadow" signals right down into
the L0CacheBuffer might be a really good way to ensure that there is time
for the L0CacheBuffer to "collate" (merge) multiple requests.

right now, as it stands, each request that comes in, if sent immediately
on an elstrided sequence, could be followed up by another request that
*could* have been merged with the 1st into the exact same cache-line...
if only the 1st had been delayed for just one cycle.

if there is a good reason to delay them, this actually could be beneficial.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev