Dan Guido

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

Agree with this. It is microsofts biggest security failing imo. You need like a PhD in windows to write a half decent sandbox. Knowledge of SDs, low integrity, low box, jobs, desktops, sessions, and semi or undocumented process flags

Yeah 100% agree it’s not good enough. I own the sandbox now and a better/real public api is at the top of the list