And that JIT has additional considerations on Apple silicon, where there is specific hardware that needs to be taken into account: https://developer.apple.com/documentation/apple_silicon/port...

I ran into another quirk with MAP_JIT recently, but going the other direction in time.

If you supported an older platform (High Sierra, which up until recently was... valid...), you would need to explicitly _not_ pass MAP_JIT into mmap there. It makes total sense once you find the bug, but it was also an easy one to overlook.

Tracking that down was kind of annoying.

A JIT is a major potential source of malware enablement and thus a security consideration.

applogies if its an ignorant question but, if the os had proper access protections, even with a buffer overflow or other exploits to an app itself, how can that enable malware just by having a JIT?

It cannot; Apple's security policy towards third-party JITs is misguided. Such a feature is useful if you are interested in providing defense-in-depth for a JIT that you have taken effort to secure and would like stronger, hardware-backed mitigations for. The API should really be opt-in for the apps that want it–the real consumers of it are going to Chrome and Firefox.

JIT requires bypassing exploit mitigations e.g. W^X. JIT doesn't make an app that's already been subverted any more dangerous than it would otherwise be, but it makes it easier to exploit the app in the first place.