Arm releases experimental CHERI-enabled Morello board • Hacker News Board

Re: Arm releases experimental CHERI-enabled Morello board

#21

Post by andsanmar » Thu, Jan 20, 2022, 2:53 PM UTC

phkahler wrote: post #17

How does this compare to testing with address sanitizers?

Simple, testing won't prevent you from all the bugs bun only the ones you run over when testing (either fuzzing or unit testing). While enforcing some safety semantics like they do here through capabilities, does. This means, at least for using CHERI you have to go through a custom compilation stack, the CHERI team has already been working on this tooling for long.

Re: Arm releases experimental CHERI-enabled Morello board

#22

Post by jrtc27 » Thu, Jan 20, 2022, 2:53 PM UTC

lacksconfidence wrote: post #6

jrtc27 wrote: post #5

Earlier quoted context omitted.

Nobody's claiming it's "hack-proof", that would be foolish, just that it removes certain classes of vulnerabilities that are the majority of CVEs for code written in memory-unsafe languages, thereby reducing the attack surface. Independent analysis by both Microsoft and Google has shown that's around 70% of vulnerabilities, which still leaves around 30%, but is a big step forward.

Not OP, but that's not how I interpreted their comment. I interepreted it as the 70% they hope to have fixed will end up having edge cases not yet considered, and the protections will end up weaker than desired. No-one designed a processor to be susceptable to spectre and meltdown, once something moves into production there is significantly more incentive to investigate and find these flaws.

We do have formal proofs of various security properties at the architectural level that consider the entire architecture with all its complexities and warts. Speculative execution is of course a concern (and is an active area of research for us), though our belief is that the bounds information now present at the hardware level allows it to be tamed. Another concern is the interaction between undefined behaviour and CHERI; the former needs to be sufficiently constrained in order to not inadvertently turn code that would be memory safe with a naive CHERI compiler into code that is not. We also know there are still memory safety-like issues we can't protect against; we can stop pointer injection, but we can't stop tricking programs into copying the "wrong" pointer somewhere, or type confusion bugs that result in using pointers in an unintended way. Many of those exploit chains today rely on exploiting some other memory safety vulnerability we do protect against, but we cannot predict if people will come up with alternative approaches that avoid those in a world with CHERI.

Re: Arm releases experimental CHERI-enabled Morello board

#23

Post by mwcampbell » Thu, Jan 20, 2022, 2:53 PM UTC

I wonder how hard it will be to retrofit CHERI support into Windows, macOS, and Chromium, so we can have a new defense against browser sandbox escapes, making remote browser isolation products irrelevant.

Re: Arm releases experimental CHERI-enabled Morello board

#24

Post by netr0ute » Thu, Jan 20, 2022, 2:55 PM UTC

jrtc27 wrote: post #20

netr0ute wrote: post #15

What about RISC-V?

We also have a CHERI-RISC-V specification ( https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-951.pdf ), with support in CHERI LLVM, CHERI QEMU and CheriBSD, plus three open-source FPGA implementations ( https://github.com/CTSRD-CHERI/Piccolo , https://github.com/CTSRD-CHERI/Flute , https://github.com/CTSRD-CHERI/Toooba ) that span various parts of the microarchitecture design space, and it is the platform we use for o…

Then the HN title is inaccurate.

Re: Arm releases experimental CHERI-enabled Morello board

#25

Post by bluejekyll » Thu, Jan 20, 2022, 2:59 PM UTC

DrBazza wrote: post #4

> The CHERI memory-protection features allow historically memory-unsafe programming languages such as C and C++ to be adapted to provide strong, compatible, and efficient protection against many currently widely exploited vulnerabilities. https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

My reading of that linked article on CHERI is two things. First that software needs to adopt the instructions in order to use it. It then raises a question of what is the benefit. What is the experience compared to today, and it should be that embedded software can gain some of the features that are generally reserved for user space. That’s virtual memory protection.

The experience then I would guess is that software will crash rather than, for example, read bad data from the wrong address space. A feature user space apps get from virtual memory (if it’s outside their processes memory space that is).

Did I get this right? Also, it should help Rust just as much, especially in unsafe code regions.

Re: Arm releases experimental CHERI-enabled Morello board

#26

Post by pjmlp » Thu, Jan 20, 2022, 2:59 PM UTC

Trex_Egg wrote: post #14

pjmlp wrote: post #9

Earlier quoted context omitted.

There are no CVEs related to Solaris SPARC Application Data Integrity, or Unisys ClearPath MCP. Either they aren't interesting for hackers, or they actually did a good job with hardware memory tagging.

I might imagine the former over latter

Might be, then again most of their customers are government agencies, not really something that hackers care about.

Re: Arm releases experimental CHERI-enabled Morello board

#27

Post by klelatti » Thu, Jan 20, 2022, 3:04 PM UTC

netr0ute wrote: post #24

jrtc27 wrote: post #20

Earlier quoted context omitted.

We also have a CHERI-RISC-V specification ( https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-951.pdf ), with support in CHERI LLVM, CHERI QEMU and CheriBSD, plus three open-source FPGA implementations ( https://github.com/CTSRD-CHERI/Piccolo , https://github.com/CTSRD-CHERI/Flute , https://github.com/CTSRD-CHERI/Toooba ) that span various parts of the microarchitecture design space, and it is the platform we use for o…

Then the HN title is inaccurate.

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

Re: Arm releases experimental CHERI-enabled Morello board

#28

Post by xenocratus » Thu, Jan 20, 2022, 3:06 PM UTC

netr0ute wrote: post #24

jrtc27 wrote: post #20

Earlier quoted context omitted.

We also have a CHERI-RISC-V specification ( https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-951.pdf ), with support in CHERI LLVM, CHERI QEMU and CheriBSD, plus three open-source FPGA implementations ( https://github.com/CTSRD-CHERI/Piccolo , https://github.com/CTSRD-CHERI/Flute , https://github.com/CTSRD-CHERI/Toooba ) that span various parts of the microarchitecture design space, and it is the platform we use for o…

Then the HN title is inaccurate.

The HN title is literally the title of the post (if you had taken the 2s to actually open the link), since Arm was the one to release the board, and just because RISC-V specifications, models, implementations, etc., exist, doesn't mean that Arm wasn't involved...

Re: Arm releases experimental CHERI-enabled Morello board

#29

Post by netr0ute » Thu, Jan 20, 2022, 3:09 PM UTC

klelatti wrote: post #27

netr0ute wrote: post #24

Earlier quoted context omitted.

Then the HN title is inaccurate.

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.

Re: Arm releases experimental CHERI-enabled Morello board

#30

Post by jrtc27 » Thu, Jan 20, 2022, 3:10 PM UTC

bluejekyll wrote: post #25

DrBazza wrote: post #4

> The CHERI memory-protection features allow historically memory-unsafe programming languages such as C and C++ to be adapted to provide strong, compatible, and efficient protection against many currently widely exploited vulnerabilities. https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

My reading of that linked article on CHERI is two things. First that software needs to adopt the instructions in order to use it. It then raises a question of what is the benefit. What is the experience compared to today, and it should be that embedded software can gain some of the features that are generally reserved for user space. That’s virtual memory protection. The experience then I would guess is that software…

Software doesn't need to "adopt the instructions", it just needs to be recompiled in the same way as you compile it for a new architecture (CHERI is effectively like the 32-to-64-bit transition in that sense). Yes, having capabilities allows you to bring memory protection to the MMU-less embedded space (see for example the now somewhat old paper https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201810...).

Yes, if you attempt to access outside the bounds of a capability you will deterministically crash. This is true even if you do have virtual memory and there is memory there.

Yes, the use of CHERI to protect unsafe code in memory-safe languages like Rust is of interest to us. There is also the possibility of being able to remove some of the compiler-generated bounds checks by using the capability bounds instead, though some care is needed to preserve the precise semantics (but some may also be happy to slightly change the semantics if it means they can all be removed and potentially improve performance).