Hacker News Reader

There's about one way[0] to fix timing side channels.

The RISC-V ISA has an effort to standardize a timing fence[1][2], to take care of this once and for all.

0. https://tomchothia.gitlab.io/Papers/EuroSys19.pdf

1. https://lf-riscv.atlassian.net/wiki/spaces/TFXX/pages/538379...

2. https://sel4.org/Summit/2024/slides/hardware-support.pdf

I'm all for giving programmers a way to flush state, and maybe this is just a matter of taste, but I wouldn't characterize this as "taking care of the problem once and for all" unless there's a [magic?] way to recover from the performance trade-off that you'd see in "normal" operating systems (ie. not seL4).

It doesn't change the fact that when you implement a RISC-V core, you're going to have to partition/tag/track resources for threads that you want to be separated. Or, if you're keeping around shared state, you're going to be doing things like "flush all caches and predictors on every context switch" (can't tell if thats more or less painful).

Anyway, that all still seems expensive and hard regardless of whether or not the ISA exposes it to you :(

The research (multiple papers; note they have published and presented more than I linked) they've done prove that hardware help is necessary.

i.e. not about reducing cost, but about being able to kill timing side channels at all.

Reply on news.ycombinator.com