On Tue, Jul 14, 2015 at 6:24 PM, Andrew Lutomirski <andy@xxxxxxx> wrote: > On Tue, Jul 14, 2015 at 6:14 PM, Kenton Varda <kenton@xxxxxxxxxxxx> wrote: >> Note that we would *love* the ability to more cleanly and robustly >> filter / rewrite syscalls in userspace, for exactly this sort of >> thing. But it seems the available options (ptrace and LD_PRELOAD) are >> far too difficult and quirky to use effectively as-is. > > The latter is very much on my todo list. The performance will suck > less than ptrace, but it still won't be fantastic. It'll be extra > tricky here because you'll be accessing user memory, too. > > Kees, have you or any of the Chromium people played with better > trapping mechanisms? There's my awful patch set to help enable > something better, but I've tabled it until the x86 entry cleanups are > done, because it's just too messy right now. For our purposes, I think I really just want to convert `syscall` instructions into regular old calls to some well-defined address where I can put my filtering code. I'm fine with the filter being in userspace where the process can attack it because the purpose of the filter is only compatibility fix-ups, not security enforcement. seccomp-bpf can basically do this by raising SIGSYS, but it seems like things break down when you get into details. E.g. you need the filter itself to be able to make syscalls, so you need seccomp to *not* block the syscall instructions made by the filter, which seems to require that the filter code be loaded in a reliable location in memory, which is kind of impossible. Also, performance. -Kenton -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
