On Wed, Jun 11, 2014 at 3:28 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Wed, Jun 11, 2014 at 3:27 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: >> On 06/11/2014 03:22 PM, Andy Lutomirski wrote: >>> On Wed, Jun 11, 2014 at 3:18 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: >>>> On 06/11/2014 02:56 PM, Andy Lutomirski wrote: >>>>> >>>>> 13ns is with the simplest nonempty filter. I hope that empty filters >>>>> don't work. >>>>> >>>> >>>> Why wouldn't they? >>> >>> Is it permissible to fall off the end of a BPF program? I'm getting >>> EINVAL trying to install an actual empty filter. The filter I tested >>> with was: >>> >> >> What I meant was that there has to be a well-defined behavior for the >> program falling off the end anyway, and that that should be preserved. >> >> I guess it is possible to require that all code paths must provably >> reach a termination point. >> > > Dunno. I haven't ever touched any of the actual BPF code. This whole > patchset only changes the code that invokes the BPF evaluator. Yes, this is how BPF works: runs to the end or exit early. With seccomp BPF specifically, the return value defaults to kill the process. If a filter was missing (NULL), or empty, or didn't explicitly return with a new value, the default (kill) should be taken. -Kees -- Kees Cook Chrome OS Security -- 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
