4 ms·

> I'm a bit at loss how this improves security or why it is necessary. If the kernel needs an external library as gatekeeper, something fundamentally went wrong

> I'm a bit at loss how this improves security or why it is necessary. If the kernel needs an external library as gatekeeper, something fundamentally went wrong. It's not about defending the kernel from the user mode process. It's a mitigation to make exploiting usermode RCEs like buffer overflows a bit harder by possibly preventing some forms of ASLR bypass. MS might do it in part for security, but likely aloo to prevent people from relying on unstable implementation details, which makes changing those details harder for MS because they try to avoid breaking popular applications. > And why would, say a Lisp compiler use the C library On unix based systems libc doubles as (part of) the OS's API. BSD in particular has no stable syscall interface, code must go through libc. Its libc doesn't even have a stable ABI across major versions, which is annoying if you're not using C. Non C languages are clearly second class citizens on BSD. Linux on the other hand does have a stable documented syscall interface, so you are allowed to call the kernel directly, without relying on any OS provided usermode libraries. On Windows it's similar to BSD, but you have to go through different OS provided libraries (at minimum ntdll, usually the Win32 API). At least these have a stable ABI. On Windows libc is little more than just another dll. > but making this a requirement seems heading the wrong direction. I disagree. IMO an OS provided dynamically linked library is a great abstraction boundary. It allows the OS to change its kernel interface or even turn operations that previously needed to transition into the kernel into purely usermode functions. For example the OS might provide a mutex which in the first version transitions to the kernel on every lock attempt, while later it's replaced by a futex based implementation which only transitions on contented locks. Or more relevant to the linked article, it allows implementing the same API on a completely different kernel (like Wine does), without increasing the kernel's API surface.

rstuart4133 6y ago
> IMO an OS provided dynamically linked library is a great abstraction boundary. In theory, yes that's true. In practice it's a question of whether it actually reduces anybodies work load. If everybody respected the boundary I sure it would reduce Microsofts work load. But as has been reported repeatedly here, that's isn't how it's worked out in practice. Not only do applications not respect it, Microsoft finds itself in the position of having to ensure some of those applications keep working on newer kernel versions despite the fact they've wilfully violated the rules. So we end up the Windows GUI having to expose with "compatibility levels", and users having to deal with it. That doesn't sound like a win to me. There are other ways of doing it that wouldn't suffer from that fate. Trampolines (a page the kernel creates in user space that intercepts some syscalls) is one way that Linux uses. I don't think Linux does, but it wouldn't be hard to insist that any syscall come from those pages. Do that and you have your cake (low overhead user space mediating some calls), and get to eat it to (you can safely assume every one uses it).
- ChrisSD 6y ago
  Except that the Windows applications that do use syscalls directly (i.e. anti-cheat software) are intended to break when something changes. It's part of their way of defending against tampering. It's also part of why they need to be continually updated and why some old games won't work at all on newer OSes until a patch is applied to hack out the anti-cheat engine. If syscalls were stable, they'd just try to use some other means to obfuscate their OS calls and ensure it's sufficiently fragile as to break easily if something changes. tl;dr the lack of stability is a feature not a bug for this use case.
trasz 6y ago
Not sure about other BSDs, but FreeBSD does have both stable syscall interface, and stable libc interfaces, which keep ABI both across major, and minor versions. Situation for non-C languages is pretty similar to what you'd expect in Linux, there's nothing second class there.

rstuart4133 6y ago

> IMO an OS provided dynamically linked library is a great abstraction boundary. In theory, yes that's true. In practice it's a question of whether it actually reduces anybodies work load. If everybody respected the boundary I sure it would reduce Microsofts work load. But as has been reported repeatedly here, that's isn't how it's worked out in practice. Not only do applications not respect it, Microsoft finds itself in the position of having to ensure some of those applications keep working on newer kernel versions despite the fact they've wilfully violated the rules. So we end up the Windows GUI having to expose with "compatibility levels", and users having to deal with it. That doesn't sound like a win to me. There are other ways of doing it that wouldn't suffer from that fate. Trampolines (a page the kernel creates in user space that intercepts some syscalls) is one way that Linux uses. I don't think Linux does, but it wouldn't be hard to insist that any syscall come from those pages. Do that and you have your cake (low overhead user space mediating some calls), and get to eat it to (you can safely assume every one uses it).

ChrisSD 6y ago
Except that the Windows applications that do use syscalls directly (i.e. anti-cheat software) are intended to break when something changes. It's part of their way of defending against tampering. It's also part of why they need to be continually updated and why some old games won't work at all on newer OSes until a patch is applied to hack out the anti-cheat engine. If syscalls were stable, they'd just try to use some other means to obfuscate their OS calls and ensure it's sufficiently fragile as to break easily if something changes. tl;dr the lack of stability is a feature not a bug for this use case.

trasz 6y ago

Not sure about other BSDs, but FreeBSD does have both stable syscall interface, and stable libc interfaces, which keep ABI both across major, and minor versions. Situation for non-C languages is pretty similar to what you'd expect in Linux, there's nothing second class there.