My understanding was that many of the fixes for speculative execution issues themselves led to performance degradation, does anyone know the latest on that and how this compares?

Are these performance hit numbers inclusive of turning off the other mitigations?

▲

snvzz 6 days ago | parent | next [-]

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

▲

eigenform 5 days ago | parent [-]

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 :(

	▲	snvzz 5 days ago \| parent [-]
		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.

▲

bjackman 5 days ago | parent | prev | next [-]

These numbers are all Vs a completely unmitigated system. AND, this is an extra-expensive version of ASI that does more work than really needed on this HW, to ensure we can measure the impact of the recent changes. (Details of this are in the posting).

So I should probably post something more realistic, and compare against the old mitigations. This will make ASI look a LOT better. But I'm being very careful not to avoid looking like a salesman here. It's better that I risk making things look worse than they are, than risk having people worry I'm hiding issues.

	▲	Eridrus 5 days ago \| parent [-]
		Not sure if you wrote this article and I appreciate an engineering desire to undersell, but if this is faster than what people actually do in practice, then the takeaway is different than if it is slower, so I think you're doing folks a disservice by not comparing to a realistic baseline in addition to an unmitigated one.

▲

0cf8612b2e1e 6 days ago | parent | prev [-]

Furthermore, if the OS level mitigations are in place, would the hardware ones be disabled?