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

131–140 of 147 posts

Re: ChkTag: x86 Memory Safety

#131

Post by fooker »

cogman10 wrote: post #43
fooker wrote: post #37

Earlier quoted context omitted.

Given that this technique is used in production for all current gen Iphones should tell you this isn't vaporware.

What technique? There's no technique described in the article. It's just a long article about why this is needed, an announcement of collaboration, and naming the set of instructions.

Yes, the article is not self contained.

Nothing is self contained, you are expected to look up memory tagging if you want the gory details of how other platforms implement it.

If you want technical information about how the x86 ecosystem will implement it, you'll need a time machine (or work at Intel or AMD I guess..)

Re: ChkTag: x86 Memory Safety

#132

Post by lossolo »

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…

> This is existing technology on ARM64 (MTE) and on modern iPhones (https://security.apple.com/blog/memory-integrity-enforcement...).

Previous discussion https://news.ycombinator.com/item?id=45186265

Re: ChkTag: x86 Memory Safety

#133

Post by pjmlp »

musicale wrote: post #91
gpm wrote: post #89

Earlier quoted context omitted.

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

> Fil-C shows this can be solved at the software layer for things in this category that can afford the overhead of a GC. Mainline clang and g++ are also getting better with things like -fbounds-safety and -fsanitize=address. As I understand it, they typically have some overhead, but I'm willing to accept that overhead to have a kernel, web browser, etc. without memory errors. The decision that memory safety is too co…

Nah, it was only a UNIX thing and C, see the world of systems languages and OS written in them outside Bell Labs.

Had UNIX and C a price tag on their source code comparable to the competition, instead of a symbolic price and an annotated source code book, history would have played a different music.

Re: ChkTag: x86 Memory Safety

#134

Post by gpderetta »

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.

There are hundreds of billions of lines of code of critical software[1] written in unsafe languages, that is not going to be rewritten any time soon. Adding memory safety "for free" to such software is a net positive.

Current CPUs are limited by power, transistors are essentially free.

[1] often the VMs of safer higher level languages, in fact.

Re: ChkTag: x86 Memory Safety

#135

Post by pron »

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

We're not, though. There's a little bit of low-level software being written in Rust (and even that requires a non-trivial amount of unsafe code), but most new low-level software is being written in C++ or C. And even if a more popular safe low-level programming language arrived tomorrow and gained a more respectable adoption, that still wouldn't be fast enough because of all the existing software.

Re: ChkTag: x86 Memory Safety

#136

Post by pjmlp »

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)

Still, the keyword is still.

Hence why Objective-C got GC, after its failure to play well with C semantics, got replaced with ARC, and afterwards Swift came to be.

Microsoft now has a new policy in place, via the Secure Future Initiative, that only exiting code bases should be kept in C and C++, all new projects are to either use managed languages or Rust.

Re: ChkTag: x86 Memory Safety

#137

Post by pjmlp »

musicale wrote: post #85
thayne wrote: post #83

Earlier quoted context omitted.

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

The reason being, as can be seen on the archives, the conservative tracing GC had several gotchas to work with existing code, thus segfaults were common.

The way ARC works in Objective-C, by automating retain/release call patterns already required by existing frameworks was much safer to implement, without such crashes.

Similar to all those C++ smart pointers automating COM reference counting.

Re: ChkTag: x86 Memory Safety

#138

Post by fweimer »

cogman10 wrote: post #51
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…

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…

I don't know if it is intended this way, but there's one useful outcome even with the limited amount of detail disclosed:

There are industry partners who work closely with AMD and Intel (with on-site partner engineers etc.), but who are not represented in the x86 ecosystem advisory group, or maybe they have representation, but not at the right level. If these industry partners notice the blog post and they think they have technology in impacted areas, they can approach their contacts, asking how they can get involved.

Re: ChkTag: x86 Memory Safety

#139

Post by pjmlp »

IshKebab wrote: post #121
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,…

Sure but nobody is actually writing foundational software (as we are now calling it) in Lisp, Java or Ada (and it also has no good answer for use-after-free which is a huge class of vulnerabilities). This is the first point in history where it's actually feasible in real non-research life to write an entire system in only memory safe languages. (And no, the existence of `unsafe` doesn't invalidate this point.)

I see plenty of foundational software in the biggest mobile OS, IoT devices and cloud computing infrastructure.

Ada only has use-after-free if unchecked deallocation is used, since we are way beyond Ada83, alternatives do exist in Ada 2022.

If anything we will only get more foundational software in safer languages, when the generation that only accepts C and C++ for specific domains is no longer among us.

Unfortunately to me as well, it isn't something I will be able to witness.

Re: ChkTag: x86 Memory Safety

#140

Post by yvdriess »

Panzerschrek wrote: post #117

It would be nice to know how this memory safety instructions should be used by software developers. Assuming I write C++ code, what should I do? Enable some new compiler flags? Use special runtime library? Use some special variant of the language standard library which uses these new instructions? Completely rewrite my code to make it safe?

If ARM's memory tagging is a guide, not much for the general developer. You will be able to run with address sanitizers enabled at a much lower overhead. Perhaps, use some hardened allocators or library variants that rely on the extension.
Post reply on HN