3 ms·

Some of these security/safety techniques are intended to be primarily used in debug kernels precisely because the overhead is too high. For example, the most re

Some of these security/safety techniques are intended to be primarily used in debug kernels precisely because the overhead is too high. For example, the most recent kernel 5.17 added a feature called page table check which adds extra consistency checking to operations that modify the page table. The overhead is high enough that probably no one is going to run with page table checks on desktop kernels or in production, but having the feature there is useful for developers who want to run additional checks against their changes. Think of it like asan: no one really runs asan binaries in production, but being able to build asan binaries for testing changes is still very useful. I'm not sure the exact overhead for IBT so I'm not sure whether this is the case for this feature. But in general not all of these safety features are intended to be built into production kernels.

aseipp 5y ago
Almost every CFI implementation I've seen is definitely intended for production use cases. There is work to combine the coarse-grained CFI aspects of Intel's IBT implementation with the more fine-grained CFI implementation available in systems like PaX/grsecurity, which is based on the assumption that the ABI prototype matches what was detected at compile time. The synthetic benchmarks for Intel's Coarse IBT alone is somewhere in the 1% range for the small number of benchmarks they have here[1] (ok, let's be honest, I don't expect x264 to contain many indirect branches in the fast path of SPEC, but whatever.) I believe Intel originally aimed for something originally in the 1-5% range but I can't find a reference. If that's it, then it seems ok enough if you're paranoid, but if you're paranoid the fine-grained approach improves things quite a bit. This all still seems to be a ways off for everyone but I guess the kernel 5.18 support is a start. [1] https://www.spinics.net/lists/kernel-hardening/msg05347.html https://www.spinics.net/lists/kernel-hardening/msg05347.html

aseipp 5y ago

Almost every CFI implementation I've seen is definitely intended for production use cases. There is work to combine the coarse-grained CFI aspects of Intel's IBT implementation with the more fine-grained CFI implementation available in systems like PaX/grsecurity, which is based on the assumption that the ABI prototype matches what was detected at compile time. The synthetic benchmarks for Intel's Coarse IBT alone is somewhere in the 1% range for the small number of benchmarks they have here[1] (ok, let's be honest, I don't expect x264 to contain many indirect branches in the fast path of SPEC, but whatever.) I believe Intel originally aimed for something originally in the 1-5% range but I can't find a reference. If that's it, then it seems ok enough if you're paranoid, but if you're paranoid the fine-grained approach improves things quite a bit. This all still seems to be a ways off for everyone but I guess the kernel 5.18 support is a start. [1] https://www.spinics.net/lists/kernel-hardening/msg05347.html https://www.spinics.net/lists/kernel-hardening/msg05347.html