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

71–80 of 84 posts

Re: Arm releases experimental CHERI-enabled Morello board

#71

Post by saagarjha »

jrtc27 wrote: post #30
bluejekyll wrote: post #25

Earlier quoted context omitted.

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,…

It's important to note that this is "just" a recompile, but it's the kind of recompile that you need to port 32-bit software to 64-bit. Pointers on CHERI are 128+1 bits, and software that treats long longs as a good place to put pointers are common. There's a lot of code that is going to need some sort of rewrite to be able to take advantage of CHERI capabilities. (But the problem is not insurmountable: WebKit already runs to some capacity, so it's reasonable to take even very low-level bit twiddling code and make it work on this platform.)

Re: Arm releases experimental CHERI-enabled Morello board

#72

Post by saagarjha »

pjmlp wrote: post #46
transpute wrote: post #44

Hopefully ARM's MTE (memory tagging extension) will appear in Apple's 2022 SoCs (M2, A16), https://security.googleblog.com/2019/08/adopting-arm-memory-... (2020) CheriBSD port to Morello, https://www.youtube.com/watch?v=7aVygpgkm1 (2021) GCC support for Morello, https://gcc.gnu.org/pipermail/gcc/2021-July/236868.html (2021) OSS desktop software stack, https://www.capabilitieslimited.co.uk/pdfs/20210917-capltd-c... >…

They already have PAC, although not exactly the same.

Right. PAC is largely used for CFI, CHERI/MTE are more general memory corruption mitigations.

Re: Arm releases experimental CHERI-enabled Morello board

#73

Post by saagarjha »

dilippkumar wrote: post #54

If I understand this correctly, we now get 128 bit pointers. The lower 64 bits are the address and the upper 64 bits are permissions. Did I miss anything?

129 bits, there's a "valid" bit at the top. For most software this is invisible but some code will need to care (most notably, anything that copies pointers will need to preserve that bit.)

Re: Arm releases experimental CHERI-enabled Morello board

#74

Post by Findecanor »

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…

> I remember the mill architecture[1] also claims to have that capability, I think they called these calls "Portals".

The Mill's "Portals" are more intended for inter-process calls than for compartmentalisation within a process. The Mill can have fine-grained protection of memory temporarily given to a callee because protection ranges are separate from paging. I believe there have been several research OS:es that did pass full pages back and forth over IPC, but at the cost of setting these up and restricting them to that purpose.

Because Portals are so cheap they could probably be useful for compartmentalising larger complex applications such as a modern-day web browser into smaller chunks than today.

BTW, Goddard has told that the Mill team once considered a capability-oriented architecture but they chose not to because the model they had in mind broke C's pointer semantics in some way. They have chosen to prioritise compliance with the C spec, so as to be able to market the architecture.

Re: Arm releases experimental CHERI-enabled Morello board

#75

Post by jrtc27 »

saagarjha wrote: post #71
jrtc27 wrote: post #30

Earlier quoted context omitted.

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,…

It's important to note that this is "just" a recompile, but it's the kind of recompile that you need to port 32-bit software to 64-bit. Pointers on CHERI are 128+1 bits, and software that treats long longs as a good place to put pointers are common. There's a lot of code that is going to need some sort of rewrite to be able to take advantage of CHERI capabilities. (But the problem is not insurmountable: WebKit alread…

Yes it's non-zero, though https://www.capabilitieslimited.co.uk/pdfs/20210917-capltd-c... is a recent exploration of what it takes to port X11 and KDE to CHERI. Of the around 6 million lines of C and C++ code involved, only about 0.026% needed to be touched, or just under 1.6k. That number will of course vary significantly between the type of code; boring applications code generally doesn't need changes (e.g. htop and sudo built and ran out of the box for me recently, as examples), but language runtimes will need significant changes. Pages 21, 22, 26 and 27 of that report have the per-component breakdown of that number.

Re: Arm releases experimental CHERI-enabled Morello board

#78

Post by fulafel »

phkahler wrote: post #17

How does this compare to testing with address sanitizers?

Testing for security bugs means mostly fuzzing these days. AddressSanitizer is added instrumentation, flagging illegal program states even when the test case wouldn't trigger a crash normally.

Fuzzing helps but it's a probabilistic method with fallible search mechanisms, there's going to be cases left that an intelligent adversary can find by reasoning, a different/better fuzzer, better instrumentation, or alt techniques like symbolic execution etc.

Re: Arm releases experimental CHERI-enabled Morello board

#79

Post by pjmlp »

titzer wrote: post #57

It's really great to see this level of hardware innovation and investment into security! Although it's a bit of a shame that we're down this path because of the inertia of unsafe programming languages and systems that put performance first. In some sense we're starting to pay back a big debt. I try to choose my words carefully (these kinds of conversations can get pretty toxic pretty quick). But honestly I think in t…

The year is 1961 and C is still about 10 years away to become a reality, https://en.wikipedia.org/wiki/Burroughs_large_systems_descri...

Re: Arm releases experimental CHERI-enabled Morello board

#80

Post by jrtc27 »

ProfHewitt wrote: post #77

Great to see further progress on CHERI! See the following for theoretical foundations for the work: Linux 60th Anniversary Keynote https://t.co/IRe3vpMlWn

Your research on actor-based programming models has nothing to do with C/C++ spatial and temporal memory safety.
Post reply on HN