Hacker News Reader

Comment by cranium | Hacker News Reader

For those heading into the comments to know what this is about: W^X is a protection policy on memory with the effect that every page in memory can either be written or executed but not both simultaneously (Write XOR eXecute). It can prevent, for example, some buffer overflow attacks.

View on HN

I guess I've never understood this. The W^X is a response to one of the classic Multics paper attacks, but doesn't actually work well in a world where JavaScript, JVM byte code, and other non-native code is "sort-of executable". Why not put the effort into a great MMU so that every allocation is its own "page" for the purpose of triggering page faults on overruns?

There's already work on that sort of thing with crash-safe.org and Cambridge's CHERI. SVA-OS by Criswell et al to a degree.

These kind of protections are for widespread use protecting legacy codebases they don't want to straight up fix or take performance hit of tools like Softbound+CETS. Incidentally, tradeoffs like that usually fail. ;)

Won't it still work well for all that code that isn't actively translated code, which is probably the vast majority of software that's run on OpenBSD?

>Why not put the effort into a great MMU

The people who are writing for OpenBSD can not "put their effort" into hardware changes to entire platforms.

They can do something to improve their own OS, however.

> Why not put the effort into a great MMU so that every allocation is its own "page" for the purpose of triggering page faults on overruns?

Do you perhaps mean "every allocation is its own address space"? I guess that would require pointers that are double the size of regular pointers (the first half pointing to the address space, and the second half being an index into that space).

Don't most of those end up JIT'd into native binary code, anyhow? The compiler would output code into a W page, then flip it to an X page and jump in.

If it's just an interpreter, then the "sort-of executable" is just data being read, and the page can stay write-only.

Is this why JavaScript is deathly slow on my OpenBSD install and no the previous Arch Linux install?

http://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in-...

> Why not put the effort into a great MMU so that every allocation is its own "page" for the purpose of triggering page faults on overruns?

We used to have that, they're called segments.

Only one processor did it like it really meant it:

https://en.wikipedia.org/wiki/Intel_iAPX_432#Object-oriented...

Look up i960. Had most key parts with otherwise normal RISC.

It seems to have been the i960MX and i960MC which had the funky object-oriented memory; they have long since been discontinued, and i can't find any documentation about them online, sadly.

EDIT: There's a passing mention in a book [1]

> The Intel i960 extended architecture processor used a tagged architecture with a bit on each memory word that marked the word as a "capability", not as an ordinary location for data or instructions. A capability controlled access to a variable-sized memory block or segment. The large number of possible tag values supported memory segments that ranged in size from 64 to 4 billion bytes, with a potential 2^256 different protection domains.

[1] https://books.google.co.uk/books?id=O3VB-zspJo4C&pg=PA189#v=...

Type i960 wikipedia into Google. It has a description plus a link to ISA datasheet in references section. About enough info to recreate it.

EDIT: Now that I'm on a PC I've added the link here for you. Copy and paste of PDF's is a b on my mobile. ;)

https://en.wikipedia.org/wiki/Intel_i960

http://bitsavers.org/pdf/biin/BiiN_CPU_Architecture_Referenc...

Oh, brilliant, thanks. I suspect this evaded my searches because it doesn't say '960mx' in any machine-readable way!

There's some fascinating stuff in here. For example:

> 8.4 Object Lifetime

> To support the implicit deallocation of certain objects while preventing dangling references, the object lifetime concept is supported. The lifetime of an object can be local or global. "Local" objects have a lifetime that is tied to a particular program execution environment [...]. "Global" objects are not associated with a particular execution environment.

> Each job has a distinct set of local objects. No two jobs can have ADs [access descriptors] that reference the same local object. The processor does not allow an AD for a local object to be stored in a global object. Thus, when a job terminates, all the local objects associated with a job can be safely deallocated, and there cannot be any dangling pointers.

The machine was designed, to run Ada programs. Does this line up with how memory management works in Ada? It certainly resembles how it works in Rust!

Ada was designed for environments where dynamic allocation wasn't allowed. So, it doesn't have safe scheme for that. It offers regions, GC, or fast/unsafe deallocation. This is one area where Rust has dramatic improvement. I agree i960 is reminiscent of schemes like Rust. Very forward thinkjng.

Btw, since Im on mobile w/out links, type these into Google: capability computer systems book Levy; Army Secure Operatimg System ASOS. First is great book with many capability architectures like i432. Second is another HW and OS combo designed as secure foundation for embedded, Ada apps. It was interesting.

FWIW Firefox manages to use W^X in their JIT (the experimental patch back in 2011 had a very interesting idea: one process w writing out to memory mapped RW, another process with the same mapped executable): http://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in-...

Further, XOR is an exclusive OR. In boolean logic, this means that the two values MUST be different. So 0 ^ 0 would 0, and 1 ^ 1 would also be 0. However, 1 ^ 0 would be 1.

> XOR

> eXclusive OR

Who would've thought.

I was just trying to illustrate for the people that read HN that don't have CS backgrounds. Didn't mean to patronize you.

Good point. It should probably be NAND: ~(W&X). Assuming that R is also a valid option, at least.

Reply on news.ycombinator.com