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

Early performance results from the prototype CHERI ARM Morello microarchitecture

ctsrd-cheri.github.io

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Early performance results from the prototype CHERI ARM Morello microarchitecture

#11

Post by astrange »

olliej wrote: post #4

The depressing thing is looking at the performance cost of so many of these mitigations that are fundamentally due to the use of unsafe languages. It results in a somewhat pernicious effect: a person can compare their unsafe language to a safe one and say “see it’s faster” because the safe language is being subject to the same hardware costs but they’re unnecessary. The lack of memory safety in many core languages me…

A JIT implementation of safe language 1 would still be dangerous in safe language 2 since it's emitting and running raw assembly. So you need a safe assembly language no matter what, I think.

Unless safe language 2 can provably write safe compilers in it, but I'm not sure I've seen any attempts at that for JITs. There is CompCert for C.

Re: Early performance results from the prototype CHERI ARM Morello microarchitecture

#12

Post by markjdb »

olliej wrote: post #9
speed_spread wrote: post #6

Earlier quoted context omitted.

CHERI enforces safety in hardware. No amount of language safety can prevent exploits from being forged right out of machine code.

CHERI gives you greater granularity over memory access it doesn’t magic away security vulnerabilities. But that doesn’t negate what I stated: there’s a massive amount of complexity, and significant performance costs of all these features. They’re needed because the prevalence of unsafe code means we need a global enforcement mechanism which means hardware. Hence we take a real and permanent cost in hardware that appl…

CHERI does more than help eliminate security vulnerabilities. Consider that today we rely on the MMU to provide memory isolation between Unix processes; CHERI enables isolation without switching page tables, at a smaller hardware cost (though it's not like you can drop unmodified software into such an architecture). So I don't think it's correct to consider this yet another layer of complexity. If anything it has the potential to lead to simpler system designs.

Re: Early performance results from the prototype CHERI ARM Morello microarchitecture

#13

Post by gpderetta »

markjdb wrote: post #12
olliej wrote: post #9

Earlier quoted context omitted.

CHERI gives you greater granularity over memory access it doesn’t magic away security vulnerabilities. But that doesn’t negate what I stated: there’s a massive amount of complexity, and significant performance costs of all these features. They’re needed because the prevalence of unsafe code means we need a global enforcement mechanism which means hardware. Hence we take a real and permanent cost in hardware that appl…

CHERI does more than help eliminate security vulnerabilities. Consider that today we rely on the MMU to provide memory isolation between Unix processes; CHERI enables isolation without switching page tables, at a smaller hardware cost (though it's not like you can drop unmodified software into such an architecture). So I don't think it's correct to consider this yet another layer of complexity. If anything it has the…

It will be nice to see CHERI applied to single address space operating systems!

Re: Early performance results from the prototype CHERI ARM Morello microarchitecture

#14

Post by mort96 »

olliej wrote: post #4

The depressing thing is looking at the performance cost of so many of these mitigations that are fundamentally due to the use of unsafe languages. It results in a somewhat pernicious effect: a person can compare their unsafe language to a safe one and say “see it’s faster” because the safe language is being subject to the same hardware costs but they’re unnecessary. The lack of memory safety in many core languages me…

There are no "safe" languages. Fast managed languages JIT compile your code to the same unsafe machine code as C, and JITs frequently have exploitable bugs. Most (all?) of the techniques which help mitigate safety bugs in "unsafe" languages also help or can be used to help mitigate safety bugs in JITs. And then there's all the standard library functions implemented in "unsafe" languages.

Then there's Rust, which doesn't even claim to be a safe language. It claims to (and does a good job at!) containing the unsafety to certain parts of the code, which is nice but there's still a whole lot of code that's marked unsafe which benefits from these mitigations.

Re: Early performance results from the prototype CHERI ARM Morello microarchitecture

#15

Post by hayley-patton »

mort96 wrote: post #14
olliej wrote: post #4

The depressing thing is looking at the performance cost of so many of these mitigations that are fundamentally due to the use of unsafe languages. It results in a somewhat pernicious effect: a person can compare their unsafe language to a safe one and say “see it’s faster” because the safe language is being subject to the same hardware costs but they’re unnecessary. The lack of memory safety in many core languages me…

There are no "safe" languages. Fast managed languages JIT compile your code to the same unsafe machine code as C, and JITs frequently have exploitable bugs. Most (all?) of the techniques which help mitigate safety bugs in "unsafe" languages also help or can be used to help mitigate safety bugs in JITs. And then there's all the standard library functions implemented in "unsafe" languages. Then there's Rust, which does…

Compile to typed assembly language?

https://www.cs.cornell.edu/talc/

Re: Early performance results from the prototype CHERI ARM Morello microarchitecture

#17

Post by rwmj »

mperham wrote: post #5

Is this an attempt to bring memory safety to C and similar unsafe languages? They really need an executive summary and overview.

This was posted yesterday and has quite a good overview:

https://tratt.net/laurie/blog/2023/two_stories_for_what_is_c...

Re: Early performance results from the prototype CHERI ARM Morello microarchitecture

#18

Post by mort96 »

hayley-patton wrote: post #15
mort96 wrote: post #14

Earlier quoted context omitted.

There are no "safe" languages. Fast managed languages JIT compile your code to the same unsafe machine code as C, and JITs frequently have exploitable bugs. Most (all?) of the techniques which help mitigate safety bugs in "unsafe" languages also help or can be used to help mitigate safety bugs in JITs. And then there's all the standard library functions implemented in "unsafe" languages. Then there's Rust, which does…

Compile to typed assembly language? https://www.cs.cornell.edu/talc/

> These typing rules guarantee the memory safety

Huh, interesting. I'm very curious about how those typing rules ensure memory safety, presumably with neither something like Rust's borrow checker nor garbage collection. I didn't think that was possible.

Re: Early performance results from the prototype CHERI ARM Morello microarchitecture

#19

Post by hayley-patton »

mort96 wrote: post #18
hayley-patton wrote: post #15

Earlier quoted context omitted.

Compile to typed assembly language? https://www.cs.cornell.edu/talc/

> These typing rules guarantee the memory safety Huh, interesting. I'm very curious about how those typing rules ensure memory safety, presumably with neither something like Rust's borrow checker nor garbage collection. I didn't think that was possible.

TAL does use garbage collection; verifying that a GC behaves is another can of worms.

Re: Early performance results from the prototype CHERI ARM Morello microarchitecture

#20

Post by fidotron »

olliej wrote: post #4

The depressing thing is looking at the performance cost of so many of these mitigations that are fundamentally due to the use of unsafe languages. It results in a somewhat pernicious effect: a person can compare their unsafe language to a safe one and say “see it’s faster” because the safe language is being subject to the same hardware costs but they’re unnecessary. The lack of memory safety in many core languages me…

The reality is build time checking for safety isn't as safe as it sounds, as others have mentioned. Not only are malicious devs a problem, but hardware fails too.

Build time safety checking is valid and useful primarily for developer productivity. Runtime checks which reinforce those (and other) constructs are for ensuring things proceed as intended. There is no contradiction. Your problem is many very useful developers prefer not to have all the build time checks, and you're not going to change their minds!

Technology adoption almost always proceeds faster in cases where the existing work can be carried over as much as possible. I often wish this wasn't the case, but pragmatically it is. To get to a safer world we cannot require rebuilding it from scratch.

Post reply on HN