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 …
-
Show this thread
-
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 ;)1 reply 0 retweets 8 likesShow this thread -
Replying to @dwizzzleMSFT @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.
2 replies 0 retweets 2 likes -
Replying to @taviso @dwizzzleMSFT
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...
2 replies 0 retweets 1 like -
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
1 reply 0 retweets 2 likes -
Replying to @dwizzzleMSFT @mamyun
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.
4 replies 1 retweet 8 likes
Not that it affects your argument, but BPF isn't Turing complete. BPF programs have to be guaranteed to terminate, which rules out Turing completeness.https://lwn.net/Articles/773605/ …
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.