On Tue, Jul 14, 2015 at 6:14 PM, Kenton Varda <kenton@xxxxxxxxxxxx> wrote: > On Tue, Jul 14, 2015 at 5:53 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: >> Why wouldn't you just use an ld preload library to intercept stat() >> calls in userspace and manipulate them there? No kernel changes >> required, no app changes required.... > > In theory I love this approach but, sadly, using LD_PRELOADed > libraries in practice has a lot of problems: > - You can't intercept intra-libc calls, so other libc functions that > might call stat() potentially need to be overridden. > - You can't intercept calls from static binaries, which are common on Sandstorm. > - You can't intercept syscalls made directly via syscall() or inline > assembly, which happen from time to time. > - The library file needs to be mapped into the container somewhere. > Normally the application controls the entire container layout, so this > is awkward. > - Lots of other issues. > > Some of the above can theoretically be solved by using seccomp to > raise SIGSYS on every stat() call and perhaps using a userspace ELF > loader, but this brings its own set of complications and performance > issues and would take a long time to build. > > 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. --Andy -- 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
