How Arm popped CHERI architecture into Morello Program hardware

Arm used the Hot Chips conference to talk about its experimental Morello Program and how it implements the CHERI architecture, designed to address some of the memory access vulnerabilities underpinning attacks on computer systems. CHERI stands for Capability Hardware Enhanced RISC Instructions, a research project from the …

[Anonymous Coward]

Hardware is a sitting duck. Obfuscate it, and it's still a sitting duck, but now a slower, inefficient one.

[Chris Gray 1]

KISS

As a compiler writer (long-time hobby), who has recently been doing X86-64 codegen, I hope they don't end up making another class of registers - that can make efficient codegen even more of a pain in the ass. And, harder to get right.

[FBee]

I see what you did there

popped CHERI indeed

[martinusher]

Seen it before somewhere

Software writers tend to think of x86 addressing as a large flat memory space, the bigger the better. Biut starting with the 80286 Intel implemented a descriptor based memory architecture similar to that used (or proposed) by many mainframes from that era. Memory was accessed through a descriptor table which provided physical base, size and properties (execute, data, stack etc) of that memory. The result was a tad clunky, as you'd expect from a processor from the 1980s, but if you took advantage of that architecture you had a processor that was difficult to abuse and would instantly trap out the moment you put a foot wrong. I loved it.

The problem, as it turned out, is this mainframe approach to memory management didn't suit the pragmatic needs of minicomputers and PCs of that era. Their code was written assuming one flat space which worked provided the code always behaved itself. It doesn't of course so there's been kludge after kludge to try to patch this. The protection model is just too complicated, it seems -- the best we offer users is a 'System' ring and a 'User' ring which doesn't scratch the surface of what should be done.

Hopefully this time a decent memory manager will stick. I still think it will fail because programmers have been trained to only think in terms of large, flat, memory but if you silo each user then there's a good chance that at least they can't take out each other.

(One side effect of this memory model is that a NULL pointer is just that. It definitely doesn't resolve to an address and will trap if you try to access it.)

[GloriousVictoryForThePeople]

Re: Seen it before somewhere

"This time it was right, it would work, and no one would have to get nailed to anything."

[An_Old_Dog]

Re: Seen it before somewhere

I think a good hardware system would provide the programmer with the view of a large, flat memory space. The segment+offset addressing of the x86 is ugly. Split instruction and data space is good. Another security-enhancing feature would be stacks accessible only via push and pop (for data stacks), or jsr and rts for call (subroutine address) stacks. No arbitrary writing of memory based on a stack pointer register and offset, or alteration of stack pointer registers by instuctions other than push/pop and jsr/rts for data and address stacks, respectively.