| |||||||||||||
Attacking hardened Linux systems with kernel JIT sprayingAttacking hardened Linux systems with kernel JIT sprayingPosted Nov 19, 2012 20:51 UTC (Mon) by nybble41 (subscriber, #55106)In reply to: Attacking hardened Linux systems with kernel JIT spraying by Cyberax Parent article: Attacking hardened Linux systems with kernel JIT spraying
> Page faults are WAY too costly for that.
Understood, though surely it must depend on what the JIT module is being used for? Page fault can't be _too_ costly given that they're used for copy-on-write, stable pages, lazy initialization, certain forms of I/O mapping, and IIRC some forms of system call, but of course the whole point of using interpreted byte code or a JIT in kernel mode is to avoid as much overhead as possible.
As an alternative to running a full userspace helper process, a page fault would probably be acceptable. As an alternative to waking up the application to do it's own packet filtering, as in BPF, you're probably right that it's too high.
(Log in to post comments)
Attacking hardened Linux systems with kernel JIT spraying Posted Nov 19, 2012 20:54 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
in the case of copy-on-write and lazy initialization, the page fault is accepted because of two things.
1. the work that needs to be done is significant enough that the page fault cost is relatively small in comparison.
2. In a very large percentage of cases, the page fault never happens, and so both the page fault and the initialization are avoided.
In the case of JIT modules, the page fault is expensive compared to the work being done, and the probability of triggering the page fault is high.
|
|||||||||||||