4 ms·

Doesn't this still mean that some security issues may go unpatched in older OS versions? I wouldn't expect them to backport major architectural changes, but th

Doesn't this still mean that some security issues may go unpatched in older OS versions? I wouldn't expect them to backport major architectural changes, but they would need to fix the security issue in some other way, otherwise malware will exploit it.

dagmx 4y ago
In my comment: > not all security fixes (note: not a patch) can apply to older operating systems because some depend on architectural changes. Per your second point, how would you go about preventing a kext from wreaking havoc in an older OS without changing the fundamental nature of kernel interaction that would only apply to a newer OS? Not everything is backwards patchable. Some things are results of decades long development practices that patching would cause the OS to break for users who aren't able to upgrade yet. e.g if you break my ability to use kexts on an older OS, but third party hardware I depend on still requires a kext, which is worse? A low risk of malware, or not being able to do my job at all?
- Liquid_Fire 4y ago
  > Not everything is backwards patchable. Some things are results of decades long development practices that patching would cause the OS to break for users who aren't able to upgrade yet. Of course. I wouldn't expect them to backport fixes for things that were considered outside the scope of security protections in the original version. But I also expect cases like this to be uncommon, because how many things can you completely rearchitect each version? The article also says: > Joshua Long has tracked the CVEs patched by different macOS and iOS updates for years and generally found that bugs patched in the newest OS versions can go months before being patched in older (but still ostensibly “supported”) versions, when they’re patched at all. Focusing just on the issues that do actually get patched (if we assume the ones that don't fall into the category you describe), if they are getting fixed months later this still leaves these "supported" systems vulnerable for months.
  - dagmx 4y ago
    With recent OS versions they’ve actually been rearchitecting a lot, all the way from the kernel to user space frameworks to enable those changes and down to things like their bootloaders. See DriverKit and ExtensionKit for some examples but there’s been several analysis of the OS updates each year. I assume that’ll settle with time because you’re right that it’s not something that should be often. However that only applies to single code paths. The OS upgrades different things each year so it becomes frequent if you account for everything. As for delays for older systems, that is unfortunate. It’s likely just a resourcing issue with all hands trying to get the newest OS to be stable since the goal is to keep users moving forward to architecturally more modern OS versions . The security patches for older systems are therefore a crutch till they can get those users onto the newer OS.

dagmx 4y ago

In my comment: > not all security fixes (note: not a patch) can apply to older operating systems because some depend on architectural changes. Per your second point, how would you go about preventing a kext from wreaking havoc in an older OS without changing the fundamental nature of kernel interaction that would only apply to a newer OS? Not everything is backwards patchable. Some things are results of decades long development practices that patching would cause the OS to break for users who aren't able to upgrade yet. e.g if you break my ability to use kexts on an older OS, but third party hardware I depend on still requires a kext, which is worse? A low risk of malware, or not being able to do my job at all?

Liquid_Fire 4y ago
> Not everything is backwards patchable. Some things are results of decades long development practices that patching would cause the OS to break for users who aren't able to upgrade yet. Of course. I wouldn't expect them to backport fixes for things that were considered outside the scope of security protections in the original version. But I also expect cases like this to be uncommon, because how many things can you completely rearchitect each version? The article also says: > Joshua Long has tracked the CVEs patched by different macOS and iOS updates for years and generally found that bugs patched in the newest OS versions can go months before being patched in older (but still ostensibly “supported”) versions, when they’re patched at all. Focusing just on the issues that do actually get patched (if we assume the ones that don't fall into the category you describe), if they are getting fixed months later this still leaves these "supported" systems vulnerable for months.
- dagmx 4y ago
  With recent OS versions they’ve actually been rearchitecting a lot, all the way from the kernel to user space frameworks to enable those changes and down to things like their bootloaders. See DriverKit and ExtensionKit for some examples but there’s been several analysis of the OS updates each year. I assume that’ll settle with time because you’re right that it’s not something that should be often. However that only applies to single code paths. The OS upgrades different things each year so it becomes frequent if you account for everything. As for delays for older systems, that is unfortunate. It’s likely just a resourcing issue with all hands trying to get the newest OS to be stable since the goal is to keep users moving forward to architecturally more modern OS versions . The security patches for older systems are therefore a crutch till they can get those users onto the newer OS.