There was some work done on XOM (eXecute-only-memory) for arm64, but on at least x86 there isn't a separate page table bit for just read permissions, so there's no way[0][1] to express R^X, PROT_EXEC without PROT_READ is not possible.

Amusingly the 80286 supported execute-only segments, but this was dropped from 32-bit x86.

[0] It is possible on Intel in VM guests using EPT (Extended Page Tables), mlarkin@ experimented with protecting the host kernel in a special VM, called "Underjack". AMD SVM supports nothing like this.

[1] The custom AMD APU SoC in Sony's PS5 console supports "xotext" via NDA'd extensions, but there's no public documentation. (If _anyone_ knows details, pls share)

... btw, PROT_WRITE-only mappings are also impossible on x86 as well, so PROT_WRITE implicitly means PROT_READ. Not that I'm aware of any valid reason anyone might want this.

> there's no way[0][1] to express R^X, PROT_EXEC without PROT_READ is not possible.

I'll also add a [2]:

[2] There's no way to do it in the page tables. But, if you have Protection Keys for Userspace (PKU), you can get it ... kinda. You can have a PROT_READ|PROT_EXEC mapping, assign it a pkey, then set PKEY_DISABLE_ACCESS in the PKRU register for that key. In fact, if you have a PKU CPU and you do an unadorned mmap(PROT_EXEC), the kernel will allocate you a pkey and do this under the covers FOR you. Anyone who can execute WRPKRU can easily undo this protection, but it's better than nothing.

kinda indeed.

As far as I can tell Intel PKU was only on Server-CPUs/Xeons until at least the 11th Gen (only later models?), and AMD Zen 3.

OpenBSD doesn't support protection keys, in any case.

Why do you expect removing PROT_READ to provide a security gain when running open source software compiled using reproducible builds? Just the offset into an executable memory mapping is enough to know the executable code to be found. Sure it's a bit annoying, but it wouldn't prevent attackers from using it as ROP gadget.

It is not think that improves security as an attacker does not need to read the executable code (remotely) to find the gadget or attack. More precisely, it is unreliable to rely on the confidentiality of such static information to achieve security.

This breaks PAN on ARM due to various unfortunate choices in the spec.