3 ms·

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

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 1y ago
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 https://tomchothia.gitlab.io/Papers/EuroSys19.pdf 1. https://lf-riscv.atlassian.net/wiki/spaces/TFXX/pages/53837970/Ratification+Plan https://lf-riscv.atlassian.net/wiki/spaces/TFXX/pages/538379... 2. https://sel4.org/Summit/2024/slides/hardware-support.pdf https://sel4.org/Summit/2024/slides/hardware-support.pdf
- eigenform 1y ago
  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 1y ago
    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.
0cf8612b2e1e 1y ago
Furthermore, if the OS level mitigations are in place, would the hardware ones be disabled?
bjackman 1y ago
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 1y ago
  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.

snvzz 1y ago

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 https://tomchothia.gitlab.io/Papers/EuroSys19.pdf 1. https://lf-riscv.atlassian.net/wiki/spaces/TFXX/pages/53837970/Ratification+Plan https://lf-riscv.atlassian.net/wiki/spaces/TFXX/pages/538379... 2. https://sel4.org/Summit/2024/slides/hardware-support.pdf https://sel4.org/Summit/2024/slides/hardware-support.pdf

eigenform 1y ago
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 1y ago
  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.

0cf8612b2e1e 1y ago

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

bjackman 1y ago

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 1y ago
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.