3 ms·

XNU: The Kernel (2003)

29 points by vezzy-fnord 11y ago

nickpsecurity 11y ago
XNU: The story of the kernel designers that should've listened to Liedtke. ;) It is an interesting compromise, though.
- pcwalton 11y ago
  The Mach API honestly isn't that bad for IPC; for passing IPC channels around between processes, I prefer it to the horrors of cmsg. It just has terrible documentation and the interactions with the Unix subsystem are pretty bad.
  - comex 11y ago
    MIG, the RPC interface generator, is pretty nasty though, if you want to send anything more complex than scalar parameters. For anyone who doesn't know, Apple has sort of deprecated raw Mach in favor of XPC, a wrapper API that sends structured data (plist/JSON-like objects, plus capabilities as an additional data type). It's much nicer to use, but sacrifices a bit of performance and, I'd say, somewhat increases the likelihood of security vulnerabilities, because there's more wiggle room to send invalid data. (Until recently, using the accessor methods for the wrong kind of object in the C API, which uses a 'xpc_object_t' type for everything, could cause memory corruption, which was thoroughly demonstrated by Google Project Zero. That's been fixed, but there's still room for logic errors..)
    - pcwalton 11y ago
      Yeah, I never used the MIG part of it. For what I'm doing now, I use platform-independent autogenerated safe serialization code and use Mach only as a low-level transport mechanism for raw bytes and capabilities. It works fine for that.
  - nickpsecurity 11y ago
    It's really the Mach implementation, complexity, and performance that I have against it. Close to a decade was spent trying to secure Mach-based systems even at the design level. The L4-style and separation kernels took around a few years each to do it down to implementation. Other concerns were pushed into simplified components which could be independently verified and even run in kernel-mode if absolutely necessary for performance. A similar approach with a UNIX would be Minix 3 or GenodeOS. And IPC on L4 and sep kernels is FAST: often stays in L1 cache. :) Although I still prefer pointer-passing architectures instead for performance. Just not many capability-centered hardware schemes around anymore outside CheriBSD. So, we gotta work the MMU and kernel/user mode to our benefit. Take what we can get. EDIT: to add "what we can get." Submitted prematurely for unknown reason.

29 points by vezzy-fnord 11y ago

nickpsecurity 11y ago

XNU: The story of the kernel designers that should've listened to Liedtke. ;) It is an interesting compromise, though.

pcwalton 11y ago
The Mach API honestly isn't that bad for IPC; for passing IPC channels around between processes, I prefer it to the horrors of cmsg. It just has terrible documentation and the interactions with the Unix subsystem are pretty bad.
- comex 11y ago
  MIG, the RPC interface generator, is pretty nasty though, if you want to send anything more complex than scalar parameters. For anyone who doesn't know, Apple has sort of deprecated raw Mach in favor of XPC, a wrapper API that sends structured data (plist/JSON-like objects, plus capabilities as an additional data type). It's much nicer to use, but sacrifices a bit of performance and, I'd say, somewhat increases the likelihood of security vulnerabilities, because there's more wiggle room to send invalid data. (Until recently, using the accessor methods for the wrong kind of object in the C API, which uses a 'xpc_object_t' type for everything, could cause memory corruption, which was thoroughly demonstrated by Google Project Zero. That's been fixed, but there's still room for logic errors..)
  - pcwalton 11y ago
    Yeah, I never used the MIG part of it. For what I'm doing now, I use platform-independent autogenerated safe serialization code and use Mach only as a low-level transport mechanism for raw bytes and capabilities. It works fine for that.
- nickpsecurity 11y ago
  It's really the Mach implementation, complexity, and performance that I have against it. Close to a decade was spent trying to secure Mach-based systems even at the design level. The L4-style and separation kernels took around a few years each to do it down to implementation. Other concerns were pushed into simplified components which could be independently verified and even run in kernel-mode if absolutely necessary for performance. A similar approach with a UNIX would be Minix 3 or GenodeOS. And IPC on L4 and sep kernels is FAST: often stays in L1 cache. :) Although I still prefer pointer-passing architectures instead for performance. Just not many capability-centered hardware schemes around anymore outside CheriBSD. So, we gotta work the MMU and kernel/user mode to our benefit. Take what we can get. EDIT: to add "what we can get." Submitted prematurely for unknown reason.