On 8/14/23 11:59, Gernot Heiser wrote: > On 15 Aug 2023, at 00:34, Demi Marie Obenour <[email protected]> wrote: >> >>> This makes me wonder if it’d make sense to design a new CPU and/or >>> instruction set with the goal of eliminating timing and other side >>> channels. Like, we had the Lisp machines with hardware support for Lisp, >>> and now most CPUs are optimized for C and similar languages, and in turn >>> those languages are optimized for those CPUs (x86, Arm, etc.). >> >> Fully-associative caches with random eviction help a lot. > > I’d claim they don’t help at all. They might if “random” was truly random, > which in hardware is rarely the case. “Random” cache replacement is more > properly described as “unspecified”. In reality it’s usually using some > existing state (eg some counter) and as such is actually fully deterministic, > you only have to reverse-engineer the mechanism. > > Besides that, fully-associative caches (unless very small) are inherently > slow (long critical path) and energy-hungry many gates to traverse).
What about Chameleon Cache (https://arxiv.org/pdf/2209.14673.pdf)? >> Speculative taint tracking helps close some of the remaining holes. > > I’m highly sceptical too. Taint-tracking has to be highly pessimistic to be > feasible, and adds a lot of complexity to the hardware (which gets back to my > earlier argument: make it more complex and you’re making it more likely that > something goes wrong). You’re not wrong. I just don’t know if a better solution for fully dynamic workloads exists. -- Sincerely, Demi Marie Obenour (she/her/hers) _______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
