Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Alternate title: Destroying General-Purpose Computing, One (Permission) Bit At A Time

If I understand correctly, one of the big unsaid implications of this article seems to be that it is now impossible to have RWX, because the hardware completely prevents it. APRR looks more like a general permissions-remapping mechanism, while SPRR appears to go beyond that.

While the technical details are certainly interesting, IMHO it's also disturbing in the same way as weapons of mass destruction or DRM. This technology is used by one company to essentially maintain control over its users, under the convincing guise of security.

What do SPRR and GXF stand for?

Given the functionality, my guess is APRR = Access Permission Remapping Registers, SPRR = Secure Permission Remapping Registers, and GXF = Guarded Execution Feature.



> This technology is used by one company to essentially maintain control over its users, under the convincing guise of security.

Its not a guise of security, it actually accomplishes it. Mac malware now has to operate within the confines of these permissions and nowadays the author has to submit a sample of the malware to Apple before it can be opened without insane prompts (this also means losing $99 and attaching their legal identity to the malware/committing identity fraud). If Apple went full-iOS on MacOS and made it so "everything must go through the App Store" then the possibility of mac malware would effectively disappear overnight into the same realm that iOS malware currently resides: jailbroken iOS devices with shady (mostly piracy-focused) apt repos.


Apple aren't doing this to eliminate malware from their systems. Probably just gearing up to the point where it's impossible to run any application that Apple isn't getting a cut of (or is free).

Realistically, malware only affects a tiny fraction of users, and only a further tiny fraction suffer demonstrable loss from it.


Malware in the past has been an enormous problem, with huge numbers of average users affected. To say that we don't need protection against malware because it's not a major problem now is circular reasoning, and ignores literally decades of effort to bring the problem under control.

For a certain generation of adults, going to visit your non-technical parents socially meant budgeting extra time to eradicate the adware of the month. It was a constant problem affecting large swaths of users, and fixing it was beyond the technical ability of most people.

Edited: fix typo.


fwiw, you can disable almost all of Apple's enhanced security features easily on macOS systems.

Their whole design is incredibly neat and well done! If you like these features (or just don't care) the default install does make attacker's lives harder.

But if you disagree with these features or just don't like them you can just boot into recovery mode, authenticate with your password and disable almost everything for macOS.

And if you just like the hardware you can do the same and install a custom kernel like Linux or *BSD and do whatever you want.

You can even have triple boot into one macOS with full security enabled, another macOS install with everything disable and a third "macOS" which actually is Linux.

They spend a lot of effort and engineering time to make all this possible.


This is true on the iOS platforms I'd say but it's not on the macOS ones: There you can just run your own code shortly after the SoC boots and then just leave SPRR/GXF disabled. That way you can easily have all rwx pages all you want.

you can also just map the same physical memory once as rw- and once as r-x even with SPRR enabled there.


Is this true? Wouldn't it mean any JIT-based language would not work on Apple Silicon? I must be misunderstanding you


A register in usermode lets you choose rw- and r-x, but rwx is not a choice. JITs will work, but need to swap between the two; SMC/XMC won't.


Ahh okay, I see, thank you for the explanation!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: