[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

* 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

* 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).


crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

More information about the libre-riscv-dev mailing list