[libre-riscv-dev] Avoiding Spectre or Meltdown
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Mon May 18 14:26:29 BST 2020
On Monday, May 18, 2020, Yehowshua <yimmanuel3 at gatech.edu> wrote:
> I know Jacob mentioned some scheme earlier.
>
> If you shadow commits to memory(really cache) during speculation by having
> commits placed in a buffer, which you can ignore once branch is resolved,
> wouldn’t that avoid some problems with Spectre and Meltdown?
hmm hmm i honestly do not know. my understanding of these OoO issues is
limited.
* we can calculate the Effective Address (immediate or indexed) and i
deliberately put in a "hold" system (addr.request and addr.go), so even
starting the actual LDST can be shadowed (defined as a prohibition against
committing).
* when addr.go is sent, there will be either a "address is ok" or an
exception signal comes back.
* a ST will subsequently wait for an explicit "st.go" however LD at present
assumes it may proceed at any time
therefore at the moment, it is the address computation which can proceed
speculatively without causing "spec/melt" harm.
however beyond the "addr.go" point, the assumption is that if no exception
comes back, all resources required to complete the LD or ST have been
reserved (TLBs established, L1 cache line valid and held) and there is a
100% guarantee that the operation will succeed.
how those API rules interact with spec/melt i do not really know.
i *believe* it is that you are not allowed to attempt "speculative
anything" which could cause an exception, is that right?
if that is the case we will need to hold all addr.go firing until any form
of shadowing (branches etc) are 100% clear.
this would result in performance that completely sucks, especially in tight
inner loops.
i would advocate making it possible to set a bit that changes that
behaviour at the hardware level (supervisor bit).
l.
--
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
More information about the libre-riscv-dev
mailing list