Wow. That is a BIG screw up if they're having to push an entire month's security updates across the board.
If anyone from Microsoft reads this: This is why cumulative updates suck, and you shouldn't force them on everyone. :)
If anyone from Microsoft reads this: This is why cumulative updates suck, and you shouldn't force them on everyone. :)
They push once a month because back in the day they pushed whenever they had an update, and enterprises really hated that because it meant that sometimes 1000s of computers were all out of commission running updates at the same time.
So MS and the enterprises agreed on a specific day of the month that updates would get pushed, so that the enterprises could plan accordingly as best fit their needs.
Some enterprises just run the updates that night and let everyone know to expect some slowness or downtime, and some of them only let the update run on their testing machines so they can validate the update in their environment before allowing it out to all the other machines.
But the main point is that the updates are predictable because that is what the customers asked for.
well. Let's say you have 10 security flaws to patch. 9 patches are fine, but in 1 you have detected a show-stopping issue.
If all you can deploy is one cumulative update, then that one issue is stopping the whole update. If you can deploy patches one-by-one (all on the same patch day, yes, but still separate from each other), then you can ship 9 patches for 9 holes and hold the one patch back until next month.
Of course you could also create a new cumulative update containing only 9 patches, but I assume that's more difficult to do and will require more testing.
What happens if patch seven fails? How about six? How about six and seven? There are an exponential number of failure cases with multiple patches vs one.
I think the cumulative patches work fairly well, they install much faster than the old ones. I am however troubled by the amount of security fixes Microsoft has to do every month. This shows that security is mostly an afterthought at Redmond.
I think it's more due to the sheer surface.
And for comparison, I think Ubuntu updates almost as much. It just reboots less due to architectural differences.
With that said, Canonical updates the whole system and all applications. Microsoft updates only the core system, even Office is not updated unless you manually opt in.
If a computer has to go out of commission for a security update, you are doing it wrong (as an OS vendor). Doing cumulative updates is only band-aid. The real solution is make the OS modular and reliable enough to replace/restart components while it is running.
Generally, however, processes don't get restarted after updates and libraries don't get reloaded, so without rebooting, you're still running the unpatched versions.
I don't know if RHEL has a clever way to figure out what needs to be restarted (it's not entirely impossible, thanks to systemd), but pretty much everyone under "et al." has this problem.
See Peter Larsen's comment here: https://lwn.net/Articles/702664/ for a more authoritative take on this, I deserted to BSD land long ago...
tl;dr Rolling out the updates without restarting is one thing, and it's done, and Microsoft could do it too, they just take the easy route. Applying them without restarting is a very different and far murkier story.
It's possible determine what processes run outdated library code. There are tools which hook into the package manager which do this, like https://github.com/liske/needrestart
This is a reasonable solution if you're running relatively non-critical processes on a single machine. If you really want to avoid downtime, a cluster with rolling updates seems like a solution with far fewer headaches.
Non-critical covers a lot these days, fortunately :-).
It'll eventually get reinvented :-).
However, the opposite problem - that of (thread-safely) ensuring that you're not stepping on another process' file when you're writing, wiping or moving it - is pretty tedious under Unix. The only way to do it reliably - that I know of - is via flock, which is opt-in and therefore not always an option (e.g. the other process is a third-party application that doesn't lock its files), and doesn't work on remote filesystems
There is no design decision without at least one compromise hanging on its tail.
Having said that, is is nice to be able to fully update an OS, including kernel, whilst running, but ultimately it is just a matter of abstraction levels and marketing.
https://www.codeproject.com/Articles/1043089/HotPatching-VER...
The executable needs to be compiled with support for hotpatching, and this doesn't address all possible exploit vectors.
The updates should all ship on Patch Tuesday for the reasons above. The problem is that "an issue" has interfered with "all updates" because "all updates" is now "one update".
For instance, one of the things that most articles did not cover about this issue is that Adobe released a new version of Flash Player on Tuesday to coincide with Patch Tuesday, when Microsoft would've released theirs as well. IE and Edge get their Flash Player updates from Microsoft through Windows Update now.
However, that didn't happen this month, because the cumulative broke. And so now people can look at the Chrome and Firefox Flash Player updates and exploit the remote code execution vulnerabilities in IE and Edge, which are now at risk.
In other examples, Microsoft has released updates which broke things like network printing on Windows 10. Enterprises had to make the choice to either not be able to print, or not get security updates until Microsoft finally fixed it two months later. Without the ability to pick and choose updates, when an update has a problem or compatibility issue, companies are going to end up just stopping updates, which is bad for everyone. In the past, we'd just hold the problematic update, but with cumulatives, it's not possible.