Linux in Windows - Implementation
Posted: 2016-04-15 05:56am
So if you haven't heard, Microsoft created a way to run native Linux binaries on Windows.
I have to say it works pretty well, but that's not why I decided to post about it. Rather lets talk details.
I've been working this the past day, total of 3 hours of work. This is a quick snippet of how this is implemented, I'll hopefully post more over time. This isn't prettied up to be a blog post.
So let's start with something simple, what's running?
Right away we can see we're really running linux binaries (this can be verified using SHA1) and not some port, most of the standard programs are unaware they're running on Windows.
But still, how does stuff work? For example, libc?
So libc is still libc (I didn't check the hashs), which means syscalls are still expecting Linux conventions to work.
Now, a quick primer. syscall is an x64 mechanism to transition to kernel mode, used by every OS. It's a hardware mechanism meaning it can't differntiate on it's own between a regular "Windows" syscall and the fact we want to reach Linux on Windows code. So what happens?
Apperently, Microsoft is using it's Project Drawbridge to implement a "container OS" inside Windows. This should be the underpinning for the Windows Containers alternative, but it's being used here to implement "Linux inside Windows".
I'll skip the init code, but the syscall mechanism in Windows now does the following branch.
What happens when we run into this branch? We reach code called LxpSysDispatch, which draws from a large syscall table (312 syscalls, not sure which linux kernel version runs precisely 312 syscalls) and runs the appropiate function, in this case.
Inside we have totally normal Windows kernel mode code.
That's all for today. I've started working out how /dev and /prov are implemented and have some things to say about that, but I'll get back to homework.
I have to say it works pretty well, but that's not why I decided to post about it. Rather lets talk details.
I've been working this the past day, total of 3 hours of work. This is a quick snippet of how this is implemented, I'll hopefully post more over time. This isn't prettied up to be a blog post.
So let's start with something simple, what's running?
Right away we can see we're really running linux binaries (this can be verified using SHA1) and not some port, most of the standard programs are unaware they're running on Windows.
But still, how does stuff work? For example, libc?
So libc is still libc (I didn't check the hashs), which means syscalls are still expecting Linux conventions to work.
Now, a quick primer. syscall is an x64 mechanism to transition to kernel mode, used by every OS. It's a hardware mechanism meaning it can't differntiate on it's own between a regular "Windows" syscall and the fact we want to reach Linux on Windows code. So what happens?
Apperently, Microsoft is using it's Project Drawbridge to implement a "container OS" inside Windows. This should be the underpinning for the Windows Containers alternative, but it's being used here to implement "Linux inside Windows".
I'll skip the init code, but the syscall mechanism in Windows now does the following branch.
What happens when we run into this branch? We reach code called LxpSysDispatch, which draws from a large syscall table (312 syscalls, not sure which linux kernel version runs precisely 312 syscalls) and runs the appropiate function, in this case.
Inside we have totally normal Windows kernel mode code.
That's all for today. I've started working out how /dev and /prov are implemented and have some things to say about that, but I'll get back to homework.