Dan Guido

Alex is right, i promise you if it made sense to do seccomp-bpf like things for Windows we would have done it by now. Windows is a different beast entirely. Hyper-v/WDAG containers are the best way we currently have to abstract away attack kernel surface.https://twitter.com/aionescu/status/1092263015699730437 …

The real question is when are we going to give HV containers to app developers and when can we get enough density and perf. I believe in @mamyun ;)

I don't see why it couldn't work, seccomp-bpf doesn't require you to be a libc developer. I think HV containers solve a different problem.

NT/win32k syscalls are more or less abstracted from the public API. So, exposing syscall filtering at that level would be fragile as we update Windows and as apps evolve. It needs to be exposed at a higher level. We're investigating...

It’s worse than that. You have NtUserMessageCall and the like which have dozens or hundreds of sub functions based on message type. Many APIs generate implicit messages. Blocking at the entry point level is way to coarse to get comparable security value to seccomp

That's just plain not true Dave, it sounds like you think seccomp-bpf is just filtering based on syscall number. The "bpf" part means that there is a little turing complete program that can examine parameters, such as class or message type, and decide an action.

I've very familiar with seccomp-bpf and what it can do :) My point is finding the APIs is hard enough, but not close to sufficient. I think total cost/work involved for developers to build an effective filter on windows is massive