The vulnerability also isn't present in standard AOSP GKI kernels (including the stock Pixel OS) or GrapheneOS kernels since they use a minimal kernel with tons of functionality disabled. Other OEMs may enable it but SELinux policy won't permit accessing it. OEMs can weaken SELinux policy but they're restricted by the neverallow rules which disallow permitting apps to access a list of non-standard socket types including AF_ALG.

The vulnerability also isn't present in standard AOSP GKI kernels (including the stock Pixel OS) or GrapheneOS kernels since they use a minimal kernel with tons of functionality disabled.

Kernel attack surface is mainly done via SELinux policies on AOSP including ioctl command allowlists per device type such as permitted GPU driver ioctl commands, io_uring only being permitted for a few core processes and much more. AOSP uses seccomp-bpf for apps, etc. too but it's mainly SELinux doing kernel attack surface reduction in practice.

https://developer.apple.com/documentation/Xcode/enabling-enh...

https://support.apple.com/en-ca/105120

You're thinking of Apple saying they haven't detected a case of a device with Lockdown Mode exploited in the wild themselves. Extremely few devices use Lockdown Mode and Apple has very little insight into successful exploits so there isn't much opportunity for them to detect it in the first place. Lockdown Mode bundles everything together and has very inconvenient changes many people won't accept. That greatly reduces usage even by people fully aware of it who want a lot of what it provides. For example, there's

Apple has said they haven't seen a case of a device with Lockdown Mode being exploited which is extremely misleading. Apple doesn't have that much visibility into devices being exploited and would mostly seen failed attempts. All of the Lockdown Mode functionality being bundled together contributes to it barely being used. There's no opt-out system for most of it beyond disabling it as a whole. Only a subset of the Safari restrictions can be partially disabled per-app and per-site which doesn't fully restore web compatibility. It's more that hardly anyone is using it and that Apple doesn't have much insight into apps and the OS being exploited successfully in the first place. Lockdown Mode is definitely useful but people should read about what it actually does and compare that to how devices get exploited. Apple's memory corruption exploit protections aren't tied to Lockdown Mode.

The portions of SailfishOS specific to it are largely closed source including the user interface and application layer. It isn't possible to fork the overall operating system. It has much worse privacy and drastically worse security than the Android Open Source Project even without taking the GrapheneOS improvements into account. It's in an entirely different space and this has no connection to it.

https://privsec.dev/posts/android/banking-applications-compa... has a UK section.

> The latter even has most of the modem software freed.

Pinephones have entirely closed source baseband firmware. They use a highly unusual cellular radio which includes both an incredibly outdated Qualcomm baseband processor with atrocious updates and security combined with an extremely outdated proprietary fork of Android running on an extra CPU core which isn't present in any mainstream smartphone. It's only replacing the unusual extra OS which has been done. That whole component doesn't exist on other smartphones and the only reason it's possible to replace it is because the whole radio has absolutely atrocious security. The radio is connected via a far higher attack surface USB connection providing far less isolation for the OS and the USB connection can be used to flash the proprietary Android OS via the fastboot protocol. The baseband firmware itself doesn't have any replacement available.