4 ms·

> Disable mitigations for CPU vulnerabilities This begs a questions, which type of applications that are ok to disable mitigation?

nullc 6y ago
Rendering or benchmarking on an isolated network.
jcelerier 6y ago
if you are in control of all the code you are running, are using desktop software that does not connect to the internet...
steventhedev 6y ago
For the majority of applications that follow this guide (or need to), the OS mitigations don't matter anyways: 1. They're running only trusted code. 2. L1 cache attacks aren't relevant if there's only one thread ever running on a given core. 3. Kernel-bypass networking means there are no system calls in the hot path anyways, so the OS mitigations won't even run in the first place. If you're already doing all this it may be easier/better to look at using FPGAs instead. The advantage of this approach is that you don't need to procure a card with enough LUTs to house your design, and it allows the Ops team to contribute to performance.
- toast0 6y ago
  If you've reduced the number of syscalls, the mitigations almost don't matter. Turning off the mitigations is more important if you're using the kernel stack for something like a tuned HAProxy installation which is mostly syscalls.
WJW 6y ago
Applications for which you can be sure that no other applications are running on the same box, either: 1. Because it's completely airgapped from the bigger internet and you control everything on it. Think complex embedded systems like radar HW control on military ships. The ships I was sailing on had 6 full racks per radar just for things like track maintenance and missile up/downlink scheduling. At some complexity level it becomes worth it to "lift" apps out of the embedded domain and make use of the facilities a bigger OS like Linux provides, but you often still have fairly tight realtime and performance requirements. A HFT server only connected to an exchange server could also count. 2. You have adequate security measures in other parts of your setup that, after carefully evaluating the risks, you decide to forego defense-in-depth in this part of the system. There are not all that many fields where this type of microsecond chasing is all that worthwhile though. There are significant costs and risks involved and most web users won't ever notice a page load increase of of few microseconds. There are way more cost-effective performance improvements available for 99+% of companies out there CPU pinning and IRQ isolation.
netmonk 6y ago
application on private network of private corporation ...

nullc 6y ago

Rendering or benchmarking on an isolated network.

jcelerier 6y ago

if you are in control of all the code you are running, are using desktop software that does not connect to the internet...

steventhedev 6y ago

For the majority of applications that follow this guide (or need to), the OS mitigations don't matter anyways: 1. They're running only trusted code. 2. L1 cache attacks aren't relevant if there's only one thread ever running on a given core. 3. Kernel-bypass networking means there are no system calls in the hot path anyways, so the OS mitigations won't even run in the first place. If you're already doing all this it may be easier/better to look at using FPGAs instead. The advantage of this approach is that you don't need to procure a card with enough LUTs to house your design, and it allows the Ops team to contribute to performance.

toast0 6y ago
If you've reduced the number of syscalls, the mitigations almost don't matter. Turning off the mitigations is more important if you're using the kernel stack for something like a tuned HAProxy installation which is mostly syscalls.

WJW 6y ago

Applications for which you can be sure that no other applications are running on the same box, either: 1. Because it's completely airgapped from the bigger internet and you control everything on it. Think complex embedded systems like radar HW control on military ships. The ships I was sailing on had 6 full racks per radar just for things like track maintenance and missile up/downlink scheduling. At some complexity level it becomes worth it to "lift" apps out of the embedded domain and make use of the facilities a bigger OS like Linux provides, but you often still have fairly tight realtime and performance requirements. A HFT server only connected to an exchange server could also count. 2. You have adequate security measures in other parts of your setup that, after carefully evaluating the risks, you decide to forego defense-in-depth in this part of the system. There are not all that many fields where this type of microsecond chasing is all that worthwhile though. There are significant costs and risks involved and most web users won't ever notice a page load increase of of few microseconds. There are way more cost-effective performance improvements available for 99+% of companies out there CPU pinning and IRQ isolation.

netmonk 6y ago

application on private network of private corporation ...