* Will Drewry [off-list ref] wrote:

quoted

This is *far* more generic still yields the same short-term end result as 
far as your sandboxing is concerned.

Almost :/ [...]

Hey that's a pretty good result from a subsystem that was not written with your 
usecase in mind *at all* ;-)

[...]  I still need to review the code you've pointed out, but, at present, 
the ftrace hooks occur after the seccomp and syscall auditing hooks.  This 
means that that code is exposed no matter what in this model.  To trim the 
exposed surface to userspace, we really need those early hooks.  While I can 
see both hacky and less hacky approaches around this, it stills strikes me 
that the seccomp thread flag and early interception are good to reuse.  One 
option might be to allow seccomp to be a secure-syscall event source, but I 
suspect that lands more on the hack-y side of the fence :)

Agreed, there should be no security compromise imposed on your usecase, at all.

You could move the event callback sooner into the syscall-entry sequence to 
make sure it's the highest priority thing to process?

There's no semantic dependency on its current location so this can be changed 
AFAICS.

Thanks,

	Ingo