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

ChkTag: x86 Memory Safety

community.intel.com

Post reply on HN
Print view View original

81–90 of 147 posts

Re: ChkTag: x86 Memory Safety

#81

Post by zdw »

eigenform wrote: post #63
cogman10 wrote: post #51

Earlier quoted context omitted.

But wait, how do you know that's what this is? The reason I'm negative is the entire article has zero detail on WTF this instruction set is or does. The best you can do is guess from the name of the instruction set. Compare the linked iPhone article to this blog and you'll quickly see the difference. There's very real discussion in the MTE article of how the instructions work and what they do. This article just says…

Probably because it's very likely that both AMD and Intel have had engineers working on this sort of thing for a long time, and they're now deciding to collectively hash out whatever the solution is going to be for both of them.

Better to have this than two sets of instruction, as is currently the case for virtualization entry/exit points on amd64 platforms.

Re: ChkTag: x86 Memory Safety

#82

Post by thayne »

sparkie wrote: post #2

Sparse on details. Presumably will be based on the existing Linear Address Masking/Upper Address Ignore specs, which are equivalent, and will be similar to CHERI. If so it needs to be opt-in or at least opt-out per process, because many language runtimes use these pointers bits to optimize dynamic types, and would suffer a big performance hit if they were unable to use them.

Doesn't CHERI use additional bits to store the capabilities rather than masking existing bits in the pointer?

But that can be problematic for any code that assumes that the size of pointers is the same as size_t/usize.

I don't see how this could not be opt in for backwards compatibility though, since existing code wouldn't use the new instructions.

Re: ChkTag: x86 Memory Safety

#83

Post by thayne »

musicale wrote: post #80
gpm wrote: post #67

It seems very strange to me to finally get around to this right as we are finally getting low level software that no longer needs it (and we've had high level software that doesn't need it for ages). At this point I think I'd prefer the transistor budget and bits of memory were spent on other things.

> we are finally getting low level software that no longer needs it Ada has had memory safety for decades – not to mention Lisp, Java, etc. if you can live with garbage collection. Even PL/I was better than C for memory safety, which is why Multics didn't suffer from buffer overflows and Unix did. But the Linux kernel (along with lots of other software which we would like to be reliable) is still mostly written in C,…

AFAIK, most of windows and OSX (and iOS) are in memory unsafe languages as well (c, c++, and objective c)

Re: ChkTag: x86 Memory Safety

#85

Post by musicale »

thayne wrote: post #83
musicale wrote: post #80

Earlier quoted context omitted.

> we are finally getting low level software that no longer needs it Ada has had memory safety for decades – not to mention Lisp, Java, etc. if you can live with garbage collection. Even PL/I was better than C for memory safety, which is why Multics didn't suffer from buffer overflows and Unix did. But the Linux kernel (along with lots of other software which we would like to be reliable) is still mostly written in C,…

AFAIK, most of windows and OSX (and iOS) are in memory unsafe languages as well (c, c++, and objective c)

macOS is (a) Unix (officially even!) and inherits many of its features and issues.

To Apple's credit though they seem to be using a memory-safe language (Swift) for new code and libraries (at least at user level) and may be rewriting old code as well, and they have also added MIE/EMTE to Apple Silicon. They also ship clang/clang++ with support for -fbounds-safety and -fsanitize=address.

Objective-C also supports Automatic Reference Counting, which helps with memory management. (Apple also implemented a garbage collector for Objective-C 2.0, but abandoned it in favor of ARC. I am aware that reference counting is technically a form of garbage collection.)

Re: ChkTag: x86 Memory Safety

#86

Post by vlovich123 »

gpm wrote: post #75
hedora wrote: post #71

Earlier quoted context omitted.

Rust code that uses unsafe still needs this sort of protection.

"Needs" is a strong word, would benefit from a bit, but in practice I think the number of vulnerabilities rust code typically has is not large enough to justify the expense of compromising the performance of every CPU ever sold (thus requiring more, consuming more energy, etc). There's also been steady progress towards creating systems to prove unsafe rust correct - at which point it wouldn't even benefit from this.…

A good chunk of Rust code often ends up linking in a C/C++ library where it’s still a concern (and this is ignoring that unsafe Rust is actually harder and more unsafe than C currently).

More importantly there’s millions if not billions of existing lines of C/C++ not least of which is the VMs for “memory safe” languages like Java. There’s huge value add in automatically adding security for a fractional CPU cost since the world won’t be rewritten into Rust anytime soon.

Re: ChkTag: x86 Memory Safety

#87

Post by OneDeuxTriSeiGo »

eigenform wrote: post #62
OneDeuxTriSeiGo wrote: post #48

Earlier quoted context omitted.

I wouldn't say that's fair. MPX failed because it was a very problematic solution to this problem. MPX had a large (greater than 15-20%) overhead and was brittle. It didn't play well with other x86 instructions and the developer experience was extremely poor (common C and C++ design patterns would cause memory faults with MPX). Apple MIE (which is essentially ARM MTE v2) and MTE on the other hand have near invisible…

I'm not arguing MPX was a good solution, just that it's silly to assume folks designing x86 machines have been totally ignoring developments in that space for the past ten years.

fair.

Re: ChkTag: x86 Memory Safety

#89

Post by gpm »

musicale wrote: post #80
gpm wrote: post #67

It seems very strange to me to finally get around to this right as we are finally getting low level software that no longer needs it (and we've had high level software that doesn't need it for ages). At this point I think I'd prefer the transistor budget and bits of memory were spent on other things.

> we are finally getting low level software that no longer needs it Ada has had memory safety for decades – not to mention Lisp, Java, etc. if you can live with garbage collection. Even PL/I was better than C for memory safety, which is why Multics didn't suffer from buffer overflows and Unix did. But the Linux kernel (along with lots of other software which we would like to be reliable) is still mostly written in C,…

> Ada has had memory safety for decades

Only with spark (i.e. formal verification). Which similar to other projects of this age (e.g. Rocq/How the compcert C compiler was implemented and proved correct) seems not to be low enough friction to get widescale adoption.

> not to mention Lisp, Java, etc. if you can live with garbage collection.

Like I said, high level languages that won't benefit from this at all have existed for ages... and the majority of software is written in them. This is one of the stronger arguments against it...

> But the Linux kernel (along with lots of other software which we would like to be reliable) is still mostly written in C, for better or worse.

Fil-C shows this can be solved at the software layer for things in this category that can afford the overhead of a GC. Which does mean a larger performance penalty than the hardware proposal, but also more correctly (since hardware changes can never solve unintended compilations resulting from undefined behavior).

The linux kernel is probably an example of an actual long tail project that would benefit from this for a reasonably long time though, since it's not amenable to "use a modified C compiler that eliminates undefined behavior with GC and other clever tricks" and it's unlikely to get rewritten or replaced with a memory safe thing quickly due to the number of companies collaborating on it.

Re: ChkTag: x86 Memory Safety

#90

Post by transpute »

tdullien wrote: post #32

With all the negative comments here: This is existing technology on ARM64 (MTE) and on modern iPhones ( https://security.apple.com/blog/memory-integrity-enforcement... ). For a good intuition why this (coupled with instrumenting all allocators accordingly) is a game-changer for exploitation, check https://docs.google.com/presentation/d/1V_4ZO9fFOO1PZQTNODu2... In general, having this come to x86 is long-overdue and v…

Is there a comparison of memory tagging designs for different architectures (POWER, SPARC, CHERI/Morello, Arm MTE/eMTE, Apple MIE, x86, RISC-V)? e.g. enforcement role of compiler vs. hardware, opt-in vs mandatory, hardware isolation of memory tags, performance impact, level of OS integration?
Post reply on HN