@kwanre Well, no browser today (except Links/Lynx) fully support W^X due to the JIT.

Firefox creates memory mappings that are RW, writes the JIT code to them, then upgrades them to RX.

Chrome/Chromium creates memory mappings that are RWX, writes the JIT code to them, then executes them.

@lattera No, I get that and I'm aware of the whole JIT issue.
I just thought Iridium doesn't use W^X *at all*

And now I looked it up and realise it's a fork of Chrome/Chromium. I was unaware of this project :o
Neat!

@kwanre Well, applications themselves don't (or shouldn't) have a say in W^X enforcement. W^X is (or should be) enforced by the kernel.

For example, when an application mmap(RWX)'s a new page, #HardenedBSD will silently drop the X bit.

When an application mprotect(RW->RX)'s an existing page, #HardenedBSD will have mprotect return EPERM.

@lattera
Let's just say shouldn't. I must admit I'm not familiar with *BSD it's been years I've used OpenBSD. But that's pretty cool of HardenedBSD.

On other platforms though... (for example Windows I can just call VirtualProtect and make any page on heap RWX. Or compile an ELF with executable stack enabled - yes, I realise stack is different from heap, but the point is there are many ways to mess with NX whether that's through malice or incompetence...)

@lattera Now, I will have to check HardenedBSD out ^^

@kwanre #HardenedBSD has disabled the ability for an ELF shared object to say "I want an executable stack" on amd64 and arm64. :)

@lattera Awesome! And clang CFI by default! Will look into replacing my Alpine boxes with HardenedBSD ones. Really neat project.
Shame about PaX/Grsec though.

@kwanre I'm still working on Cross-DSO CFI support. Non-Cross-DSO-CFI is only enabled in base for 12-CURRENT, not 11-STABLE or 10-STABLE.