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

51–60 of 147 posts

Re: ChkTag: x86 Memory Safety

#51

Post by cogman10 »

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 "Memory safety is hard and we'll fix it with these new instructions that fix memory safety!"

Re: ChkTag: x86 Memory Safety

#54

Post by monocasa »

erichocean wrote: post #38
monocasa wrote: post #17

Earlier quoted context omitted.

Not a whole lot of language runtimes (if any) really depend on upper address ignore. AFAIK, AMD only added it in Zen4.

The JVM does with the ZGC garbage collector, did a really nice talk on it recently. [0] [0] https://www.youtube.com/watch?v=y_QeST7Axrw

The JVM optionally does it. It does not rely on it.

Re: ChkTag: x86 Memory Safety

#55

Post by cogman10 »

OneDeuxTriSeiGo wrote: post #50
cogman10 wrote: post #43

Earlier quoted context omitted.

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.

ARM has an extension called the "Memory Tagging Extension". It works by borrowing 4 bits per 16 byte block of memory to color the allocation. Pointers are given a color "key" inside the pointer during allocation and if that pointer's key isn't the right color as the underlying memory block's during deref, then the hardware throws an MTE segfault. It's a neat system with pretty much no overhead and it's pretty easy to…

Right, but none of this is in the article. MTE is neat and it'll be interesting if AMD64 brings in a similar technique but none of that is actually described in the article.

Re: ChkTag: x86 Memory Safety

#56

Post by OneDeuxTriSeiGo »

pizlonator wrote: post #6

It’s just probabilistic memory safety, at best Still cool, but not a replacement for memory safety language implementations.

Memory coloring (what is to my knowledge being proposed) is certainly probabilistic however it really does a lot towards memory hardening more than memory safety. It makes successfully pulling off ROPs, etc far harder.

Even if you are using a memory safe language, memory bugs still pop up in various places (cough FFI & ABI cough) so this is a massive step in the right direction towards blocking attacks even when the developers have done "all the right things" short of formally verifying their stack from top to bottom (and even then).

Re: ChkTag: x86 Memory Safety

#58

Post by OneDeuxTriSeiGo »

cogman10 wrote: post #55
OneDeuxTriSeiGo wrote: post #50

Earlier quoted context omitted.

ARM has an extension called the "Memory Tagging Extension". It works by borrowing 4 bits per 16 byte block of memory to color the allocation. Pointers are given a color "key" inside the pointer during allocation and if that pointer's key isn't the right color as the underlying memory block's during deref, then the hardware throws an MTE segfault. It's a neat system with pretty much no overhead and it's pretty easy to…

Right, but none of this is in the article. MTE is neat and it'll be interesting if AMD64 brings in a similar technique but none of that is actually described in the article.

Sure but given the description of ChkTag and given the new exceptions and interrupts model they established with FRED, I don't see ChkTag being anything other than an MTE-style lock-and-key color tagging solution.

The press article is just saying what the EAG is working on next now that they have shipped FRED, ACE, and AVX10. ChkTag is the current top priority item on the EAG's list and the standard for it should be finalised/released some time in the next few months. What they have done publicly so far is to say that ChkTag will be part of the ISA standard, they just haven't also revealed the details past that.

Re: ChkTag: x86 Memory Safety

#59

Post by levodelellis »

pizlonator wrote: post #6

It’s just probabilistic memory safety, at best Still cool, but not a replacement for memory safety language implementations.

I've been meaning to ask you what the motivation of your project is? Why would you want a safe-c? When I saw the headline I was worried that all my runtime code would break (or get slower) because I do some very unsafe things (I have a runtime that I compile with -nostdlib)

I'm also tempted to write a commercial C++ compiler, but it feels like a big ask, paying for a compiler sounds ridiculous even if it reduces your compile time by 50x

Re: ChkTag: x86 Memory Safety

#60

Post by Pannoniae »

tredre3 wrote: post #49
superkuh wrote: post #4

I hope there are OS level (ie kernel build options) to turn this kind of thing off or just ignore the 'tags'. I know it's important for corporate use cases and monetary transactions and all that, but on my personal computer I use for fun I want to be able to peek and poke.

If you're worried that this is going to prevent you from peeking and poking, I think you're mistaken. This is to protect a process against itself, not the outside. It will also likely be a single bit flip away of being unenforced at runtime, as most x86 protections already are to be to make debugging tools feasible. By the way, there are already systems in place to prevent you from accessing certain memory zones. Yes…

"The time to be worried about that was 10 years ago."

And is everyone just expected to (metaphorically) lay down and die? You don't stop fighting for freedom just because you lost a battle... they certainly don't, and you shouldn't either!

Post reply on HN