Stephen Kell
Stephen Kell
Since we don't want to catch sigreturns, this is serendipitous in a way. But it's a problem that they sneak through the 'real' vDSO rather than our fake one. Not...
This is a known problem. I have seen this work successfully, but it is not reliable because the compiler doesn't know what we're doing. Once the stack is zapped, any...
I haven't tested it but am pretty sure programs using ```sigaltstack``` will screw with one or more things.
At the moment, applications with their own SIGILL handler are a problem. We can support this by chaining the handler, so that a SIGILL that isn't ours can be passed...
Our xed-based decode is especially slow, but even with the libx86emulate one, it takes too long to trap a whole segment of a large library like glibc. With xed, the...
Our bootstrapping approach means that we (should) have our own handlers for ```mmap()``` and friends, in addition to the client's possible instrumentation of those calls. So a single ```replaced_syscalls``` array...
Instead of trapping all syscalls, some binary analysis can reveal (to the non-paranoid) that a given syscall site only ever makes a given syscall. If we're not interested in instrumenting...
Taking a double trap on each system call is fine for some applications, but it would be better to avoid the slowdown. We could use a jump- or call-based instrumentation,...
We can already optionally do a "paranoid scan" which warns on intra-instruction byte sequences that incidentally can perform system calls. But it's just a warning. Ideally we would have a...
We need to avoid distinct simultaneous W and X mappings of the same underlying object, such as a file that is MAP_SHARED. That would have the same effect as a...