[Libre-soc-dev] Wishbone and House Contract Of Sale Proposition

[lkcl]

On October 28, 2021 6:37:47 PM UTC, Jacob Lifshay <programmerjake at gmail.com> wrote:
>That said, I think speculative execution should be limited to only
>inside a
>cpu core with its associated caches, we *should not* attempt full chip
>speculation, especially because handling speculation across multiple
>cpu
>cores is a hard problem and very likely to have spectre-style
>bugs...just
>think how easy it is to leak info if one core's speculative execution
>causes another core to go slower/faster, as well as what happens if one
>core speculatively writes to shared memory, and another core can see
>that,
>and intentionally leak it through a spectre-style vulnerability, before
>it's canceled.

for all of these speed optimisations, it is pretty much guaranteed that you hit resource contention, and that's where you get info leak.

this is unavoidable except for architectures like The Mill which are fully timing-predictable (100% fixed timing) so much so that the compiler can do the entire static allocation at compiletime, in fact that is literally the entire point of the Mill.

(and look how much work had gone into the Mill llvm compiler, and binaries are not portable)

the only other way to avoid timing info leak is to massively oversubscribe backend Function Units and internal buses so badly that at no time and under no circumstances will any instruction issue ever stall or result in any kind of resource contention, not for memory, not for cache, not for TLB, not for Virtual Memory, not for pipelines, not for Reservation Stations, not for regfile ports, not for SMP, nothing.

this is of course absolutely hopelessly unrealistic but it is what it takes to ensure zero timing leaks.

for example if you have 8 way SMP and you want to absolutely guarantee no one core can affect timing in another core you have to have a fricking *8* port cache snoop bus, because of course you can't just have a single broadcast bus between all 8 cores because that single bus is, of course, by definition, a contended resource!

start to see how insane it is to try to stick religiously to "we must totally and absolutely eliminate all timing information leakage"?

at some point you have to make a decision "is this really worth screwing around with to such an extent that performance is degraded by 10% then 30% then 50%, to create something that is so complex we delay the entire project by years, and nobody wants to but it because performance absolutely sucks"?

(linus torvalds is getting particularly fed up with intel speculative patches, not just the complexity, the performance loss that results ).

basically it's a really tough call that requires being pragmatic and up-front.

l.