On Thu, Feb 16, 2012 at 3:34 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > On 02/16/2012 01:28 PM, Markus Gutschke wrote: >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
