Hacker News Reader

Comment by Scaevolus | Hacker News Reader

There's insufficient motivation for OS creators. It's possible to compile C code with various hardening options and pay a few percent overhead for it, but it remains almost entirely in the realm of academia...

Except for the Xbox. Someone hacking an Xbox would lose _Microsoft_ money through piracy, which hurts their bottom line!

As a result, the Xbox runs a type 1 hypervisor with various compiler hardening options like Control Flow Integrity enabled, and are generally some of the most locked down consumer devices sold today.

What's Apple's motivation beyond bad press? iMessage was parsing media sent to it with a pdf parser. Sure, some activists in repressive regimes will get spied on and executed, but it's just so much effort to invest dev effort on rewrites for security when you could find new ways to send cute animated gifs to each other.

View on HN

Which hardening options are Apple ignoring? I would have thought the standard types of ones (debian's default) would also be set on macos/ios, eg https://help.apple.com/xcode/mac/current/#/devf87a2ac8f

From what I can tell all NSO's rigmarole of making a virtual machine in the PDF parser is to work around the existing mitigations.

I guess they could also turn on asan etc in production but that's more than a few percent slowdown.

I don‘t know anything about the benefits of these options but if the tradeoff is only a slowdown of the device this should be an option given to the user. Maybe even payed for („hardened version“ at buy time) or through a subscription.

Just an anecdote but I use GrapheneOS on my phone. It's a security focused OS based on Android AOSP with in particular a secure memory allocation function.

The whole OS feels much slower than regular Google Android, Osmand (map app) is barely usable (on a Pixel 4XL which isn't a low end phone by any means).

So I don't think we can discount how much slower a device will be with a more secure OS. It might be invisible on desktops, but certainly not on mobile.

If the secure OS had the same development velocity as the OEM profit OS, the secure OS would be much better optimized than it currently is and likely much much more secure, too.

Android and iOS are optimized in general and for example Google or Samsung also optimize and distribute it for specific hardware. GrapheneOS is not well funded and has little influence in hardware development. The development of Graphene from AOSP is pretty much guaranteed to de-optimize it in the short term.

While there is little about mobile that would cause a secure OS to be noticably slower, much less mature software with many fewer deployments is expectedly less optimized.

Address Sanitizer is not meant to be used as security hardening.

Maybe we should use Xbox instead of phones for secure communication?

Reply on news.ycombinator.com