On Wed, Feb 22, 2012 at 1:53 PM, H. Peter Anvin [off-list ref] wrote:

On 02/22/2012 11:47 AM, Will Drewry wrote:

quoted

quoted

I highly disagree with every filter having to check the mode: Filters that
don't check the arch on e.g. x86 are buggy, so they have to check it, even
if it's a 32-bit or 64-bit only system, the filters can't know that and
needs to check the arch at every syscall entry. All other info in the data
depends on the arch, because of this there isn't much code to share between
the two archs, so you can as well have one filter for each arch.

Alternative approach: Tell the arch at filter install time and only run the
filters with the same arch as the current system call. If no filters are run,
deny the systemcall.

This was roughly how I first implemented compat and non-compat
support.  It causes some implicit behavior across inheritance that is
not nice though.

This is trivially doable at the BPF level, right?  Just make this the
first instruction in the program (either deny or jump to a separate
program branch)... and then there is still "one program" without any
weird inheritance issues?

Exactly, and that's what the patch does now (after your feedback :)

ld arch
je arch, 1, 0
ret SECCOMP_RET_KILL
<rest of bpf program>

At this point, I don't think it makes sense to do it a different way
than just in the BPF program even if it does mean leaving out the
check could leave the program open to compat-style bugs.  At least a
shared library and/or good practices should be able to catch that
error.

thanks!
will