4 ms·
Yesterday I was reading about seccomp (short for secure computing mode in the Linux kernel) [0][1]. The Wikipedia entry surprised me with the following sentence
by qwertox 5y ago
Yesterday I was reading about seccomp (short for secure computing mode in the Linux kernel) [0][1]. The Wikipedia entry surprised me with the following sentence:
> In some kernel versions, seccomp disables the RDTSC x86 instruction, which returns the number of elapsed processor cycles since power-on, used for high-precision timing.
The article says the following:
> I tried to measure the difference between the programmed TSC value and when execution was actually interrupted (not when the interrupt handler starts running, but when the old execution context is interrupted - you can measure that if the interrupted execution context is just running RDTSC in a loop); [...]
Would using (or "enabling" seccomp, I don't know how it is used) mitigate this kernel race? How would one go about enabling it? Is this an optional setting in AppArmor / SELinux?
[0] https://man7.org/linux/man-pages/man2/seccomp.2.html https://man7.org/linux/man-pages/man2/seccomp.2.html
[1] https://en.wikipedia.org/wiki/Seccomp https://en.wikipedia.org/wiki/Seccomp
- tptacek 5y agoProbably not; he was just using rdtsc to try to figure out why there was so much variability in the absolute timeouts he was specifying with timerfd_settime, and my impression was that he gave up and just accepted the 30% hit rate --- which is absurdly high for such a tight race.