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

51–60 of 84 posts

Re: Arm releases experimental CHERI-enabled Morello board

#51

Post by plutonorm »

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.

Exactly - these formal methods have implicit assumptions in them. Within their axioms/priors they are proven correct. But the devil is in those assumptions. And that is disregarding the rather foggy notion of 'proof'. Is this proof written in a formal proof system that automates the proof? Because if it isn't you have another source of error. Even if it is in a formal proof system, who is to say that there is no error in the formal proof system? I admit that each layer adds more assurance - but appealing to 'formal proof' is a bit like appealing to god, it's an appeal to an unassailable authority. When in fact, once you know the details these things are never so clear cut.

Re: Arm releases experimental CHERI-enabled Morello board

#52

Post by jacquesm »

jrtc27 wrote: post #49
jacquesm wrote: post #48

Earlier quoted context omitted.

Interesting. But: given the amount of server side software that is running on Linux I think a FreeBSD port, while useful is not going to see the kind of adoption that a Linux port would, it will serve as a useful POC but ultimately the challenge will be to get this into the mass market and there it will not really help.

Similarly if you really want mass market adoption then you need a Windows port, otherwise most consumer PCs will remain without it, and for mobile adoption you want an iOS port (though Android does at least contribute a sizeable chunk). Porting FreeBSD does, however, not just serve as a PoC but also let you port all the standard third-party software that runs on all Unix-like OSes (most ports need few if any changes,…

I think this is an extremely important and timely development, I sincerely hope that you succeed and will be following the project closely from now on.

One more question: does the CHERI add on introduce new 'uLimit' like limitations, for instance the number of allocatable blocks or will it scale seamlessly with whatever the various memory management functions and system calls provide?

Re: Arm releases experimental CHERI-enabled Morello board

#53

Post by jrtc27 »

jacquesm wrote: post #52
jrtc27 wrote: post #49

Earlier quoted context omitted.

Similarly if you really want mass market adoption then you need a Windows port, otherwise most consumer PCs will remain without it, and for mobile adoption you want an iOS port (though Android does at least contribute a sizeable chunk). Porting FreeBSD does, however, not just serve as a PoC but also let you port all the standard third-party software that runs on all Unix-like OSes (most ports need few if any changes,…

I think this is an extremely important and timely development, I sincerely hope that you succeed and will be following the project closely from now on. One more question: does the CHERI add on introduce new 'uLimit' like limitations, for instance the number of allocatable blocks or will it scale seamlessly with whatever the various memory management functions and system calls provide?

The only thing that gets weird is the primary thread's stack limit, since we need to construct that capability up-front with the right bounds. This means we have a somewhat arbitrary upper limit (which you could make tunable, though I don't think we do, just a #define'd constant) that should be big enough for any reasonable process and reserve all that virtual address space regardless of what the stack limit is (but it's still unmapped and not backed by anything, just a big region of "don't use this as another capability already overlaps with it"). You can then use rlimit(2) to configure your stack limit and the virtual memory subsystem will do the same as it does on non-CHERI, just you won't be able to exceed that threshold, and the capability's bounds for the stack pointer will always cover the maximum possible mapping, not the mapping you're actually using.

Everything else is the same, just "as much as your system can fit (and system policies will let you)". Which will be slightly less, because pointers are bigger, but we don't have any additional tables that impose arbitrary restrictions on what you can do.

Re: Arm releases experimental CHERI-enabled Morello board

#55

Post by ncmncm »

trasz wrote: post #33
stan_g wrote: post #31

With funding of DARPA how sure can we be that it will not have a backdoor? Is there a way to proof that there is no backdoor to the security features?

The MIPS and RISC-V CHERI implementations are open, you can audit the BlueSpec. The entire software stack is open too. Note however that CHERI is not just an implementation; it’s a design, an idea. You can’t backdoor that.

Anyway, it's harder.

Re: Arm releases experimental CHERI-enabled Morello board

#56

Post by jacquesm »

jrtc27 wrote: post #53
jacquesm wrote: post #52

Earlier quoted context omitted.

I think this is an extremely important and timely development, I sincerely hope that you succeed and will be following the project closely from now on. One more question: does the CHERI add on introduce new 'uLimit' like limitations, for instance the number of allocatable blocks or will it scale seamlessly with whatever the various memory management functions and system calls provide?

The only thing that gets weird is the primary thread's stack limit, since we need to construct that capability up-front with the right bounds. This means we have a somewhat arbitrary upper limit (which you could make tunable, though I don't think we do, just a #define'd constant) that should be big enough for any reasonable process and reserve all that virtual address space regardless of what the stack limit is (but…

Ok. Super cool that you have thought so far ahead in designing this. Looking forward to being able to use it in production!

Re: Arm releases experimental CHERI-enabled Morello board

#57

Post by titzer »

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 the long arc of history, C will be regarded like asbestos: very obviously dangerous in retrospect. I respect the designers of C immensely and the amount of work many thousands of people the world over have put into that entire toolchain and ecosystem, but we can't blamelessly have that conversation yet, so I guess I'll stop here.

Re: Arm releases experimental CHERI-enabled Morello board

#58

Post by jrtc27 »

mwcampbell wrote: post #47
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,…

> Yes, the use of CHERI to protect unsafe code in memory-safe languages like Rust is of interest to us. Have you found that the relative difficulty of bootstrapping Rust on a new architecture, as mentioned in [1], has hindered your team's ability to research this? Or is it not as bad with CHERI on ARM, because aarch64 is already a Rust tier 1 platform? [1]: https://drewdevault.com/2022/01/15/2022-01-15-The-RISC-V-exp…

I've bootstrapped Rust for RISC-V on FreeBSD, it's not that bad, the issues I faced were solely porting issues, not bootstrapping issues. I've certainly not had cross-compiling issues like Drew. The awful part about porting Rust is that you need Rust bindings for every type and function in your system's libc, which is fine if your OS+libc combination is already supported (though even then 32-bit and 64-bit need some separate implementation bits), but a real pain if your OS isn't yet supported. Rust on CHERI has the additional complexity of a poor design decision in the language that defines usize as a pointer-sized integer, conflating integers and pointers, rather than providing both size_t and uintptr_t equivalents like C has; see https://internals.rust-lang.org/t/pre-rfc-usize-is-not-size-... for a discussion of this and ways to resolve it without breaking existing software on non-CHERI which, as you might expect, is to introduce a new uptr type for the rare cases when a usize holds a pointer not an offset/length/machine word-sized integer, allowing a usize to be used in its place on non-CHERI architectures (at least for existing editions) but not for CHERI architectures. Someone needs to do that engineering though and it's not a priority for us.

Re: Arm releases experimental CHERI-enabled Morello board

#59

Post by aseipp »

pjmlp wrote: post #39
mwcampbell wrote: post #12

Earlier quoted context omitted.

I'll leave it to others to go into technical details, but the most obvious answer is that this effort has major industry players behind it, meaning it might actually make it into production.

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.

Re: Arm releases experimental CHERI-enabled Morello board

#60

Post by jrtc27 »

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're relevant because they're technologies relating to memory safety and provide some level of additional protection. However, they rely on secrets and are in general only probabilistic, so they don't deterministically mitigate all memory safety issues (you can deterministically mitigate some with clever allocations of memory "colours", but not all). CHERI and MTE-like schemes also both rely on the use of tagged memory, but in rather different ways.
Post reply on HN