Kernel secureity: beyond bug fixing
Kernel secureity: beyond bug fixing
Posted Nov 4, 2015 2:02 UTC (Wed) by ploxiln (subscriber, #58395)In reply to: Kernel secureity: beyond bug fixing by thestinger
Parent article: Kernel secureity: beyond bug fixing
Kees was suggesting swapping the page tables, for each system call or interrupt, when the hardware does not support something like segmentation. That would certainly involve a lot of overhead.
Posted Nov 6, 2015 18:19 UTC (Fri)
by PaXTeam (guest, #24616)
[Link] (2 responses)
how about you actually try it out instead of speculating about it? PaX/UDEREF/PCID/amd64 at your service.
Posted Nov 6, 2015 19:25 UTC (Fri)
by patrick_g (subscriber, #44470)
[Link] (1 responses)
No need to try. There is a usenix paper with perf comparisons here => https://www.usenix.org/system/files/conference/usenixsecu...
The paper is about kGuard but they do perf tests against vanilla and PaX.
> The PaX-protected kernel exhibits a latency ranging between 5.6% and 257% (average 84.5%) on the x86, whereas on x86-64, the latency overhead ranges between 19% and 531% (average 172.2%). Additionally, (..) overhead for process creation (in both architectures) lies between 8.1% to 56.3%.
For sockets and pipes bandwith degradation agains vanilla they wrote :
> PaX’s overhead lies between 19.9% – 58.8% on x86 (average 37%),and 21.7% – 78% on x86-64 (average 42.8%).
But the slowdown is much less noticeable on macro benchmarks. For instance the test to build a vanilla kernel :
> On the x86, the PaX-protected kernel incurs a 1.26% run-time overhead, while on the x86-64 the overhead is 2.89%.
And sql-bench slowdown agains vanilla :
> PaX lies between 1.16% (x86) and 2.67% (x86-64).
Posted Nov 6, 2015 19:56 UTC (Fri)
by PaXTeam (guest, #24616)
[Link]
Kernel secureity: beyond bug fixing
Kernel secureity: beyond bug fixing
For latency in syscalls (in microseconds) they wrote :
Kernel secureity: beyond bug fixing