4 ms·

You understand that Apple could bypass kexts too? This is an issue of trust, not a technical issue.

CountSessine 6y ago
Try to bypass kexts and you’re just asking for kernel stability issues and Mac customer crashes. Pushing these guys out of the kernel lets Apple cheat them and Mac users clean and easy.
- gruez 6y ago
  >Try to bypass kexts and you’re just asking for kernel stability issues and Mac customer crashes why would that be the case? All you'd need to do is provide some sort of private network api, and only allow apple signed code to use it.
  - throwaway2048 6y ago
    that is not how kexts work(ed), they can do completely arbitrary things to the kernel, including removing any theoretical code signing requirement.
    - gruez 6y ago
      any access? On Windows, you can write a driver that would run in kernel mode, but critical sections can't be modified[1]. I'd imagine there's something similar for mac. [1] https://en.wikipedia.org/wiki/Kernel_Patch_Protection https://en.wikipedia.org/wiki/Kernel_Patch_Protection
      - SCHiM 6y ago
        KPP is not considered a security boundary. That means, in Windows security jargon, that it's a feature that helps security. But not something that you or anyone else should consider a fail proof solution, or even something that would result in a patch if breached.
        gruez 6y ago
        If patching the kernel to intercept network requests is sufficiently hard enough that you're forced to use their "approved" way of intercepting network requests, then it's very easy for them to sneak requests through. Even if patching the kernel wasn't an issue, it still turns into a game of whack a mole because apple can sneak as many changes as they want with each macos release. It heavily favors apple, not the developers of such firewalls.
        CountSessine 6y ago
        Even if patching the kernel wasn't an issue, it still turns into a game of whack a mole Exactly - but the game itself is the problem. Firewall vendors will go hunting through kernel code for jump targets and structs to plug into hidden interfaces, and Apple will remove and change them, causing crashes and instability. Apple has some leverage if they have a program like WHQL, but even then driver writers will commit shenanigans. Push them out of the kernel altogether and now only Apple can engage in shenanigans and break user trust. Which they already have.
      - comex 6y ago
        There hasn’t been anything like that on macOS. macOS on Apple Silicon will have a form of kernel patch protection, like on iOS, but it’s designed to guard against exploits from userland, not approved kexts. It’s definitely possible for third party kexts to bypass that somehow, but possibly only by disabling Secure Boot; I haven’t looked into it.
Wowfunhappy 6y ago
It's worth noting the Apple does release the source code to XNU (albeit on a ~6 month delay), and unlike some of their other source releases, there's actually enough tooling for you to build your own kernel. So while there are still gaps, it is overall more open to review.

Try to bypass kexts and you’re just asking for kernel stability issues and Mac customer crashes. Pushing these guys out of the kernel lets Apple cheat them and Mac users clean and easy.

gruez 6y ago
>Try to bypass kexts and you’re just asking for kernel stability issues and Mac customer crashes why would that be the case? All you'd need to do is provide some sort of private network api, and only allow apple signed code to use it.
- throwaway2048 6y ago
  that is not how kexts work(ed), they can do completely arbitrary things to the kernel, including removing any theoretical code signing requirement.
  - gruez 6y ago
    any access? On Windows, you can write a driver that would run in kernel mode, but critical sections can't be modified[1]. I'd imagine there's something similar for mac. [1] https://en.wikipedia.org/wiki/Kernel_Patch_Protection https://en.wikipedia.org/wiki/Kernel_Patch_Protection
    - SCHiM 6y ago
      KPP is not considered a security boundary. That means, in Windows security jargon, that it's a feature that helps security. But not something that you or anyone else should consider a fail proof solution, or even something that would result in a patch if breached.
      - gruez 6y ago
        If patching the kernel to intercept network requests is sufficiently hard enough that you're forced to use their "approved" way of intercepting network requests, then it's very easy for them to sneak requests through. Even if patching the kernel wasn't an issue, it still turns into a game of whack a mole because apple can sneak as many changes as they want with each macos release. It heavily favors apple, not the developers of such firewalls.
        CountSessine 6y ago
        Even if patching the kernel wasn't an issue, it still turns into a game of whack a mole Exactly - but the game itself is the problem. Firewall vendors will go hunting through kernel code for jump targets and structs to plug into hidden interfaces, and Apple will remove and change them, causing crashes and instability. Apple has some leverage if they have a program like WHQL, but even then driver writers will commit shenanigans. Push them out of the kernel altogether and now only Apple can engage in shenanigans and break user trust. Which they already have.
    - comex 6y ago
      There hasn’t been anything like that on macOS. macOS on Apple Silicon will have a form of kernel patch protection, like on iOS, but it’s designed to guard against exploits from userland, not approved kexts. It’s definitely possible for third party kexts to bypass that somehow, but possibly only by disabling Secure Boot; I haven’t looked into it.

Wowfunhappy 6y ago

It's worth noting the Apple does release the source code to XNU (albeit on a ~6 month delay), and unlike some of their other source releases, there's actually enough tooling for you to build your own kernel. So while there are still gaps, it is overall more open to review.