On 02/22/2012 11:47 AM, Will Drewry wrote: >> >> 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? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html