[actualwitch]

> Scanning Apple's release notes or security update disclosures for the update doesn't reveal any smoking guns

Wait what? So 10 screens of bangers like "An app may be able to execute arbitrary code with kernel privileges" and "An attacker with arbitrary kernel read and write capability may be able to bypass kernel memory protections. Apple is aware of a report that this issue may have been exploited." are not considered smoking guns?

[altairprime]

End users typically don’t tolerate security fixes that alter or break existing functionality, so it would be in line with common responses for those ten screens of security concerns to be disregarded. One of the fixes this release is untrainable SIGKILLs programs for illegal memory accesses, which is a perfectly boring and sensible security practice — and also is causing much of the drama everyone’s seeing. Presumably there’s also a new Celebrite attack over USB-C / PCIe / Thunderbolt, and fixing it urgently has uncovered either a USB/TB spec bug, an implementation bug in the OS, or an implementation bug in the devices. It’s usually the devices, but sometimes it’s not.

[Aloisius]

> One of the fixes this release is untrainable SIGKILLs programs for illegal memory accesses, which is a perfectly boring and sensible security practice

Why is preventing trapping on an illegal memory access a sensible security practice?

Preventing the access, sure, but I'm not seeing what force killing a process does for security, especially given there are perfectly reasonable reasons why one might want to trap the signal.

[grodriguez100]

> One of the fixes this release is untrainable SIGKILLs programs for illegal memory accesses, which is a perfectly boring and sensible security practice

The signal raised for page faults should be (and actually was, before 14.4) SIGSEGV, and not SIGKILL. This behaviour is even defined by POSIX.

There is no reason why this should change, specially not in the final release instead of in the public betas and early access releases (where the change was not present).

[altairprime]

To clarify so that I’m not responding incompletely, are we seeing all page faults, i.e. process swapped to disk, now raise SIGKILL — or is this behavior reserved only for certain page faults, i.e. out-of-bounds and permission-denied (R^X) accesses?

The former would be a catastrophic defect and probably result in the release being pulled from distribution.

The latter would be a new classification of certain kinds of page faults as “safe” and “unsafe”, and only the safe ones are allowed to comply with POSIX signal handling. Perhaps they’ll propose an update to POSIX now that the zero day response has shipped.