back
15 comments
This is a misleading title.

The official stance from their document they’re quoting is:

- older operating systems receive security patches

- not all security fixes (note: not a patch) can apply to older operating systems because some depend on architectural changes.

This is the norm. You don’t want major architectural changes being back propagated to older OS versions. That’s a sys admin nightmare where a security update now breaks all your drivers because Apple would have had to port DriverKit backwards and restricted kexts.

All these sites are reporting it as some kind of failing but it’s just sensationalism.

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.

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?

> 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.

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.

Making architectural changes to create a patch implies that they only prefer to work on the latest codebase. What you are describing is a lack of commitment to long-term-support for older OS (in effect, planned obsolescence); so the head line is indeed accurate. Apple providing only partial support for older OSes can be quite meaningless depending on the security hole they decide to not fix "because it is too much work".
Your comment belies that you have never worked on kernel and system level infrastructure with mass deployment.

You can't just patch an old kernel for all security flaws because you may break other things like how third party drivers interact with the kernel. That interaction itself may be the cause of a security flaw (and in fact is, which is why they're moving to user space kernels with DriverKit)

How would you posit that you patch an architectural security hole that would break users setups if you were to backport it?

You don't backport - you create a separate hacky patch for the older codebase that temporarily fixes the issue. (In fact, that's exactly what everyone does when a serious bug is found in a current version software that they know requires an architectural change for a long term fix). Ensuring compatibility without breaking stuffs (like Windows was once famous for) or long-term support for softwares is not a new concept. What you pointed out in your comments is how Apple prioritises its resource - it's perfectly reasonable to focus only on the latest version of codebase as that is obviously easier, and Apple's business model is built on that. That's the mindset / policy that certainly gives you the luxury to think in terms of changing the architecture to fix a bug the "right" way but at the expense of ignoring older codebases.
You completely ignored my very salient and real example of where “separate hacky patches” can’t work.
This also makes me wonder who will be providing software & security updates for the current crop of EVs in 15-20 years time?

They are basically 2-ton computers on wheels, capable of inflicting huge damage if / when they are hacked or experience a catastrophic bug.

Who will be responsible?

I hope no vehicles rely on a valid SSL certificate.

This is an odd take because EVs are no more computers on wheels than ICE cars. They probably actually have fewer electrical components to drive and monitor.

You’re likely conflating that EVs tend to come with the better tech packages but in almost every case where there’s an ICE equivalent you can get the same tech packages in the equivalent car.

Now if your point is long term software updates, this has been an issue for many years across many manufacturers.

It’s very much like Android vs iOS where many android phones don’t receive updates after a small period due to the low incentive to the manufacturer and the high variance in SKUs .

However in vehicles like Volvo, Tesla etc where they’ve kept variance low there’s quite a lot of software updates over time.

> This is an odd take because EVs are no more computers on wheels than ICE cars. They probably actually have fewer electrical components to drive and monitor.

Somewhat true, somewhat untrue. All modern cars have at least some kind of ECU, and have done now for a long time now, with lots of sensors etc for engine management and more - however comparatively these are simple and un-networked devices with a singular purpose - managing the engine and basic electronics (lights, wipers, critical stuff). Some modern luxury cars including ICEs and EVs have gone way beyond this and added "entertainment units" aka distractotrons, and then networked the entire car to this thing (including the ECU) as a central control with remote network access, and millions of lines of code more than the majority of OS and browsers.

Perhaps it's because most EVs are luxury cars, but EVs do tend to fall into the latter category of overcomplicated networked monstrosities. Especially tesla, where a software update can brick something as trivial and traditionally dependable and independent as an electric window motor.

Simple ECUs should make the need for security patches extremely unlikely simply due to the attack surface. There should be an international automaker law that prohibits them from making a networked, remotely accessible ECU, keep the distractotron as a separate thing so that when it inevitably bricks itself it wont take the actual car with it.

I believe the answer will have to come from above, i.e. governments.

Industry is unable to self-regulate on this.

EV Manufacturers: "Repeat after me - planned obsolescence is a feature."
subscriptions hasten the end-of-life equation