3 ms·

Right. Don’t let the perfect be the enemy of the good. If anything, Apple has demonstrated on several occasions that they are able to commit to long-term change

Right. Don’t let the perfect be the enemy of the good. If anything, Apple has demonstrated on several occasions that they are able to commit to long-term changes and the sustained effort they may require. It depends on their analysis, but if they think they should do it, they probably already have a team working on it somewhere and a plan to bring it progressively over ~5 years, with a series of incremental steps.

pjmlp 4y ago
The strategy that was communicated at WWDC was that every time a kext model has an userspace alternative, there will be one year transition, and then the following OS version won't support the former kext variant. The long term roadmap is to keep moving the infrastructure to userspace this way, until no one else besides Apple themselves can touch kernel memory space.
- saagarjha 4y ago
  The problem here is that Apple themselves have problems with their kernel-space code.
  - pjmlp 4y ago
    True, the point is that they are taking multiple paths to make macOS/iOS more secure and (we already discussed this to death), more micro-kernel like, even if not pure. A kernel with Apple only code, is more stable and secure than letting everyone to the party. Every little piece of the puzzle helps.
  - 1letterunixname 4y ago
    Yep. It does too much and it's still stuck in he 1980's. If you want security: a formally-verified microkernel that doesn't do much but memory mapping, IPC, and context switching. Everything else needs to be running either in a VM like BEAM or formally-verifiable, statically-compiled, safe "userland"-ish binaries. Going beyond PNP and ACPI, per-OS hardware drivers could be made unnecessary if vendors provided "ACPI"-like APIs that exposed standard, introspectable functions and data structures to the OS in a unified way independent of bus and architecture, i.e., a GPU, a block device, a serial port, a sensor. A universal "IOKit" would required less integration and development effort for all to support, and every OS would get support for free.

pjmlp 4y ago

The strategy that was communicated at WWDC was that every time a kext model has an userspace alternative, there will be one year transition, and then the following OS version won't support the former kext variant. The long term roadmap is to keep moving the infrastructure to userspace this way, until no one else besides Apple themselves can touch kernel memory space.

saagarjha 4y ago
The problem here is that Apple themselves have problems with their kernel-space code.
- pjmlp 4y ago
  True, the point is that they are taking multiple paths to make macOS/iOS more secure and (we already discussed this to death), more micro-kernel like, even if not pure. A kernel with Apple only code, is more stable and secure than letting everyone to the party. Every little piece of the puzzle helps.
- 1letterunixname 4y ago
  Yep. It does too much and it's still stuck in he 1980's. If you want security: a formally-verified microkernel that doesn't do much but memory mapping, IPC, and context switching. Everything else needs to be running either in a VM like BEAM or formally-verifiable, statically-compiled, safe "userland"-ish binaries. Going beyond PNP and ACPI, per-OS hardware drivers could be made unnecessary if vendors provided "ACPI"-like APIs that exposed standard, introspectable functions and data structures to the OS in a unified way independent of bus and architecture, i.e., a GPU, a block device, a serial port, a sensor. A universal "IOKit" would required less integration and development effort for all to support, and every OS would get support for free.