Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Arm releases experimental CHERI-enabled Morello board

lightbluetouchpaper.org

Post reply on HN
Print view View original

61–70 of 84 posts

Re: Arm releases experimental CHERI-enabled Morello board

#61

Post by amelius »

zeotroph wrote: post #42

On most current archs: > Any piece of code running in a process can construct an integer value and, if this integer corresponds to a valid location in the process’ address space, then it can access memory at that location. What this adds: > CHERI changes this. Every load or store instruction and every instruction fetch must be authorized by an architectural capability. So it should be possibly to call into any functi…

> Every load or store instruction and every instruction fetch must be authorized by an architectural capability.

This sounds great. But on the other hand ... Yikes! What if this tech falls into the hands of a big corporation and some manager needs a raise?

Re: Arm releases experimental CHERI-enabled Morello board

#62

Post by als0 »

amelius wrote: post #61
zeotroph wrote: post #42

On most current archs: > Any piece of code running in a process can construct an integer value and, if this integer corresponds to a valid location in the process’ address space, then it can access memory at that location. What this adds: > CHERI changes this. Every load or store instruction and every instruction fetch must be authorized by an architectural capability. So it should be possibly to call into any functi…

> Every load or store instruction and every instruction fetch must be authorized by an architectural capability. This sounds great. But on the other hand ... Yikes! What if this tech falls into the hands of a big corporation and some manager needs a raise?

This isn’t a digital signature or anything like that. Instead, it’s increasing the size of pointers to include bounds and permission rights (R/W/X/etc), plus an extra tag stored somewhere else to prevent forgeries or mitigate corruption. So the only thing big corp gets out of this is software more resilient to memory corruption :-)

Re: Arm releases experimental CHERI-enabled Morello board

#63

Post by jrtc27 »

amelius wrote: post #61
zeotroph wrote: post #42

On most current archs: > Any piece of code running in a process can construct an integer value and, if this integer corresponds to a valid location in the process’ address space, then it can access memory at that location. What this adds: > CHERI changes this. Every load or store instruction and every instruction fetch must be authorized by an architectural capability. So it should be possibly to call into any functi…

> Every load or store instruction and every instruction fetch must be authorized by an architectural capability. This sounds great. But on the other hand ... Yikes! What if this tech falls into the hands of a big corporation and some manager needs a raise?

Then great, they push for the adoption of the technology and the world's computers become more secure. Arm's a big corporation and they're obviously pretty involved, and both Microsoft and Google are invested in the project.

Re: Arm releases experimental CHERI-enabled Morello board

#64

Post by pjmlp »

aseipp wrote: post #59
pjmlp wrote: post #39

Earlier quoted context omitted.

As mentioned in another reply, there are already a couple of tagging approaches in production. Unfortunely x86/x64 don't have any, and MPX was broken from the get go.

This isn't a memory tagging system at all and has capabilities far beyond that (pun intended), so I don't know why whatever other approaches like MTE are out in the wild are relevant.

They are 100% relevant in what concerns taming the native code produced by C derived languages.

Re: Arm releases experimental CHERI-enabled Morello board

#65

Post by dev_tty01 »

netr0ute wrote: post #29
klelatti wrote: post #27

Earlier quoted context omitted.

Are you saying Arm haven't released a CHERI enabled Morello board?

It's technically true, but it makes it look like CHERI is only for ARM.

The HN title is an accurate reflection of the article and the event. When the RISC-V group has a similar event, there will be a similar article. Nothing deceptive or incorrect here.

Re: Arm releases experimental CHERI-enabled Morello board

#66

Post by staticassertion »

This is extremely exciting to me. While at my company we use Rust almost exclusively there's still lots of peripheral software we rely on in C and C++. Getting spatial memory safety nearly "for free" in those projects will make me feel way, way better.

Re: Arm releases experimental CHERI-enabled Morello board

#67

Post by phkahler »

trasz wrote: post #32
phkahler wrote: post #17

How does this compare to testing with address sanitizers?

Apart from some more interesting scenarios enabled by CHERI: you probably don’t want to run all your production software with address sanitizers, because it would be unacceptably slow. Here the performance overhead is negligible.

But maybe we can run sanitizers during testing and catch most of the issues CHERI will find without building it into hardware. OTOH that doesn't do anything to protect against malicious code, but that should be properly sandboxed anyway.

Re: Arm releases experimental CHERI-enabled Morello board

#68

Post by zeotroph »

jrtc27 wrote: post #45
zeotroph wrote: post #42

On most current archs: > Any piece of code running in a process can construct an integer value and, if this integer corresponds to a valid location in the process’ address space, then it can access memory at that location. What this adds: > CHERI changes this. Every load or store instruction and every instruction fetch must be authorized by an architectural capability. So it should be possibly to call into any functi…

The C startup code (for statically-linked binaries) and run-time linker (for dynamically-linked binaries) carve up initial capabilities provided by the kernel into capabilities that cover the various global variables and function pointers needed by the program and libraries, similar to how pointers are initialised for position-independent code (more complex, but same principle, just scan through all the relocations a…

Thanks for the explanation!

So these bounds are set by the software (and are guarded against manipulation). Then each read or write to memory is checked against these bounds by the "fine grained MMU" hardware.

Re: Arm releases experimental CHERI-enabled Morello board

#69

Post by jrtc27 »

phkahler wrote: post #67
trasz wrote: post #32

Earlier quoted context omitted.

Apart from some more interesting scenarios enabled by CHERI: you probably don’t want to run all your production software with address sanitizers, because it would be unacceptably slow. Here the performance overhead is negligible.

But maybe we can run sanitizers during testing and catch most of the issues CHERI will find without building it into hardware. OTOH that doesn't do anything to protect against malicious code, but that should be properly sandboxed anyway.

You should indeed run sanitisers during testing and catch most of the issues; we encourage this! What CHERI provides is twofold:

1. Memory safety issues not found in testing do not lurk as exploitable vulnerabilities; testing is never perfect, often far from it when it comes to edge/unexpected cases where vulnerabilities lurk (though fuzzing can help somewhat)

2. Sandboxing still needs some kind of isolation primitive, which CHERI can provide in place of the heavyweight MMU-based techniques that exist today

Plus let's not kid ourselves that all software is being tested with sanitisers. The vast majority of software running on your system probably is not.

Re: Arm releases experimental CHERI-enabled Morello board

#70

Post by jrtc27 »

zeotroph wrote: post #68
jrtc27 wrote: post #45

Earlier quoted context omitted.

The C startup code (for statically-linked binaries) and run-time linker (for dynamically-linked binaries) carve up initial capabilities provided by the kernel into capabilities that cover the various global variables and function pointers needed by the program and libraries, similar to how pointers are initialised for position-independent code (more complex, but same principle, just scan through all the relocations a…

Thanks for the explanation! So these bounds are set by the software (and are guarded against manipulation). Then each read or write to memory is checked against these bounds by the "fine grained MMU" hardware.

Yes, though "software" is rather broad; where exactly the bounds setting happens is important as if you get it wrong it allows malicious software to not set bounds and be able to access memory outside of its allocations. Pushing it to the same place the actual allocation happens or, in the case of referencing global variables, the same place the loading and relocating happens, ensures that the only thing malicious software can do by not setting bounds is make itself insecure.
Post reply on HN