Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Drawbridge

research.microsoft.com

Post reply on HN
Print view View original

11–20 of 45 posts

Re: Drawbridge

#11

Post by pinkyand »

roc wrote: post #7
majke wrote: post #5

> it consists of a closed set of 45 downcalls with fixed semantics that provide a stateless interface. If the features 800+ syscalls can be put into 45 syscalls, why not make an operating system that has only 45 syscalls? Then make the kernel modular.... and we've made a full circle in the OS design :)

> "why not make an operating system that has only 45 syscalls?" Because much of Microsoft's licensing revenue is contingent upon continuing to support the edge cases that are inevitably not part of the set of programs that can be dropped into such a sandbox without problems.

There's a leak[1] talking about windows 9 possible being partly free, but some features are subscription based. That would give them the incentive to solve the security issues.

[1]http://arstechnica.com/information-technology/2014/04/the-in...

Re: Drawbridge

#12

Post by markbnj »

guiomie wrote: post #4

Not sure I get it... Basically you would get rid of IIS, and run vNext apps in a drawbridge pico process ?

I don't think so. The idea is to provide for Windows the same kind of lightweight containerization as docker/LXC provides on linux. So if it were to work the same way, you'd install IIS into your container, and run the container on a host. Having read through the post now, which doesn't have a lot of detail, it seems to me that the picoprocess and library OS concepts are a consequence of not having true kernel-level support for namespaces and something like cgroups. Docker and LXC containers don't host a minimal OS, they share the existing kernel in well-defined ways.

Re: Drawbridge

#13

Post by rayiner »

JoshTriplett wrote: post #6

The "picoprocess" here seems very similar to Linux's "seccomp" mechanism for restricting the kernel API surface. Current sandboxing mechanisms on Linux (such as Chrome's various sandboxes) use seccomp to restrict almost all syscalls, and their APIs come from IPC to more privileged processes. Two notable differences: On the one hand, seccomp provides much more flexibility about the subset of kernel API offered to the…

This seems to me to be more along the lines of work into exokernels: most of the "kernel" runs as a library in user mode.[1] The application still has a full range of functionality available. The "45 API calls" is not what the user process can access, but the interface between the, untrusted, user-mode kernel and the, secure, kernel-mode kernel.

[1] http://research.cs.wisc.edu/areas/os/Qual/papers/exokernel.p...

Re: Drawbridge

#14

Post by dunno »

So, this is this a means to bridge the gap between Hyper-V, Hyper-V app streaming and Docker on the windows side? I'm kinda confused what the use case is compared to other existing product offerings.

Re: Drawbridge

#15

Post by shaurz »

majke wrote: post #5

> it consists of a closed set of 45 downcalls with fixed semantics that provide a stateless interface. If the features 800+ syscalls can be put into 45 syscalls, why not make an operating system that has only 45 syscalls? Then make the kernel modular.... and we've made a full circle in the OS design :)

I would welcome a new Windows API to replace Win32. Not sure if they would ever expose it or continue with the old legacy crap.

Re: Drawbridge

#16

Post by CyberShadow »

JoshTriplett wrote: post #6

The "picoprocess" here seems very similar to Linux's "seccomp" mechanism for restricting the kernel API surface. Current sandboxing mechanisms on Linux (such as Chrome's various sandboxes) use seccomp to restrict almost all syscalls, and their APIs come from IPC to more privileged processes. Two notable differences: On the one hand, seccomp provides much more flexibility about the subset of kernel API offered to the…

> they may have an efficient mechanism for trapping NT "syscalls"

I believe this is not really necessary. The syscall ABI is not stable from Windows version to Windows version - ABI stability is instead provided via the userspace DLLs (kernel32, user32 etc.), which are the official API applications are expected to use.

Some processes might invoke the syscalls directly, but this is a narrow use case (e.g. security software or copy protection wrappers might use syscalls to bypass userspace API hooks).

Re: Drawbridge

#17

Post by Sanddancer »

roc wrote: post #7
majke wrote: post #5

> it consists of a closed set of 45 downcalls with fixed semantics that provide a stateless interface. If the features 800+ syscalls can be put into 45 syscalls, why not make an operating system that has only 45 syscalls? Then make the kernel modular.... and we've made a full circle in the OS design :)

> "why not make an operating system that has only 45 syscalls?" Because much of Microsoft's licensing revenue is contingent upon continuing to support the edge cases that are inevitably not part of the set of programs that can be dropped into such a sandbox without problems.

You missed the joke. NT was originally a pretty hardcore microkernel, with even things like graphics drivers being in userspace. However, in the name of performance, more and more stuff was brought into kernel space.

Re: Drawbridge

#18

Post by pdwetz »

dunno wrote: post #14

So, this is this a means to bridge the gap between Hyper-V, Hyper-V app streaming and Docker on the windows side? I'm kinda confused what the use case is compared to other existing product offerings.

"Docker for Windows" is what hit my mind while reading it. Worth noting it's from MS research, so it doesn't mean you'll see it as is (if at all).

Re: Drawbridge

#19

Post by p4bl0 »

I'm wondering if the Library OS could be used in the Wine project or in a new Wine-like project to run Windows programs under other operating systems.

Re: Drawbridge

#20

Post by iNate2000 »

shaurz wrote: post #15
majke wrote: post #5

> it consists of a closed set of 45 downcalls with fixed semantics that provide a stateless interface. If the features 800+ syscalls can be put into 45 syscalls, why not make an operating system that has only 45 syscalls? Then make the kernel modular.... and we've made a full circle in the OS design :)

I would welcome a new Windows API to replace Win32. Not sure if they would ever expose it or continue with the old legacy crap.

I thought that Microsoft intended WinRT to replace Win32...
Post reply on HN