On Thu, Feb 16, 2012 at 3:34 PM, H. Peter Anvin [off-list ref] wrote:

On 02/16/2012 01:28 PM, Markus Gutschke wrote:

quoted

I think, the documentation said that as soon as prctl() is used to set
a bpf filter for system calls, it automatically disallows system calls
using an entry point other than the one used by this particular
prctl().

I was trying to come up with scenarios where this particular approach
causes problem, but I can't think of any off the top of my head. So,
it might actually turn out to be a very elegant way to reduce the
attack surface of the kernel. If we are really worried about userspace
compatibility, we could make the kernel send a signal instead of
terminating the program, if the wrong entry point was used; not sure
if that is needed, though.

Let's see... we're building an entire pattern-matching engine and then
randomly disallowing its use because we didn't build in the right bits?

Sorry, that's asinine.

Put the bloody bit in there and let the pattern program make that decision.

Easy enough to add a bit for the mode: 32-bit or 64-bit.  It seemed
like a waste of cycles for every 32-bit program or every 64-bit
program to check to see that its calling convention hadn't changed,
but it does take away a valid decision the pattern program should be
making.

I'll add a flag for 32bit/64bit while cleaning up seccomp_data. I
think that will properly encapsulate the is_compat_task() behavior in
a way that is stable for compat and non-compat tasks to use.  If
there's a more obvious way, I'm all ears.

thanks!
will