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

101–110 of 147 posts

Re: ChkTag: x86 Memory Safety

#101

Post by pizlonator »

levodelellis wrote: post #59
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…

My motivation is that I love to write compilers

Re: ChkTag: x86 Memory Safety

#102

Post by pizlonator »

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…

Wow that weird state machine doc is great! Thanks for sharing.

I’m lukewarm on this.

- It is long overdue and welcome.

- It won’t stop a sufficiently determined attacker because its probabilistic and too easy to only apply partially

Is this good? Yes. Does it solve memory safety? No. But does it change the economics? Yes.

Re: ChkTag: x86 Memory Safety

#103

Post by LoganDark »

saagarjha wrote: post #70
LoganDark wrote: post #65

Earlier quoted context omitted.

Apple announces MIE, then Intel and AMD say they have something similar except they don't actually have something similar, only plans to eventually implement it, but they're advertising it as if they do already have it. That sounds like super blatant "panicking to copy Apple" to me. The submission title goes "Intel and AMD standardize ChkTag ..." but the actual text says "Intel and AMD are working together, along wit…

I don't see the panic. They've been working on it for a while, it's inspired by MTE if anything.

They wouldn't announce it with zero results nor even any actual specification to show unless they were trying to show it off as soon as possible. Otherwise they could just wait until they, you know, actually did something, to announce it.

Re: ChkTag: x86 Memory Safety

#104

Post by levodelellis »

pizlonator wrote: post #101
levodelellis wrote: post #59

Earlier quoted context omitted.

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…

My motivation is that I love to write compilers

That's the best answer. Just wondering because you have a lot of experience and many people disagree with me.

How realistic is a C++ compiler that's 50x faster than clang for debug builds? Assuming 1) there's enough work for each core 2) there's so many files/headers that a unity build takes 1/4th of the time as a rebuild using individual files (this theoretical compiler would be multi-threaded)

Re: ChkTag: x86 Memory Safety

#105

Post by mshroyer »

pizlonator wrote: post #102
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…

Wow that weird state machine doc is great! Thanks for sharing. I’m lukewarm on this. - It is long overdue and welcome. - It won’t stop a sufficiently determined attacker because its probabilistic and too easy to only apply partially Is this good? Yes. Does it solve memory safety? No. But does it change the economics? Yes.

Yeah it's the most succinct explanation I've seen of weird machines and memory tagging. Definitely bookmarking this one. I wonder if video of the talk that presumably presented this is available.

Re: ChkTag: x86 Memory Safety

#106

Post by DannyBee »

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.

A lot of this sort of thing come from AMD/Intel clients, rather than internally.

In this particular case, it definitely does :)

Re: ChkTag: x86 Memory Safety

#107

Post by DannyBee »

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…

>But wait, how do you know that's what this is?

A lot of these extensions come from Intel/AMD/etc clients first, and because of how long it takes a thing to make it into mainstream chips, it was probably conceived of and worked on at least 5 years ago, often longer.

This particular thing has a long history and depending on where they worked, they know about that history.

However, they are often covered by extra layers of NDA's on top of whatever normal corporate employee NDA you have, so most people won't say a ton about it.

Re: ChkTag: x86 Memory Safety

#108

Post by Tuna-Fish »

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.

I would not assume they just use bits in the address word for the tag.

LPDDR6 includes 16 bits of host-defined metadata per 256 bits of data. Systems can use that for ECC, and/or for other purposes, including things like tagging memory. DDR6 will likely include a similar mechanism.

SECDED ECC requires 10 bits, leaving you 6 bits. That's enough for one bit per aligned address word, which is probably used to denote "valid pointer" like CHERI.

Re: ChkTag: x86 Memory Safety

#109

Post by sparkie »

afishhh wrote: post #45
wbl wrote: post #20

Earlier quoted context omitted.

Dynamic types have classically used the lower bits freed by alignment constraints. If I know a cons cell is 16 bytes then I can use the low 4 bits of an address to store enough type info to disambiguate.

There's a technique known as "NaN boxing" which exploits the fact double precision floats allow you to store almost 52 bits of extra data in what would otherwise be NaNs. If you assume the top 16 bits of a pointer are unused[1], you can fit a pointer in there. This lets you store a pointer or a full double by-value (and still have tag bits left for other types!). Last I checked LuaJIT and WebKit both still used this…

> On amd64 they actually need to be sort of "sign extended" so require some fixup once extracted.

Pointers need to be canonical if LAM/UAI is not enabled. The simplest way to do it is to shift left by 16, then shift arithmetic right by 16. (Or 7 if using 5-level paging). Alternatively, you can store the pointer shifted left by 16 bits, and have the tag in the lower 16 bits, then canonicalizing the pointer is just a single shift-arithmetic-right. If combining with NaN-boxing, then you rotate right to recover the double. (Demo: https://godbolt.org/z/MvvPcq9Ej). This is actually more efficient than messing with the high bits directly.

With LAM/UAI, the requirement is that the 63rd bit matches the 47th (or 56th) bit, which gives 15-bits of tag space on LAM48 and 6-bits of tag space on LAM57.

With LAM enabled, care needs to be taken when doing any pointer comparison, as two pointers which point to the same address may not be equal. There have been multiple exploits with LAM, including speculative execution exploits.

Re: ChkTag: x86 Memory Safety

#110

Post by sparkie »

jandrewrogers wrote: post #99
afishhh wrote: post #45

Earlier quoted context omitted.

There's a technique known as "NaN boxing" which exploits the fact double precision floats allow you to store almost 52 bits of extra data in what would otherwise be NaNs. If you assume the top 16 bits of a pointer are unused[1], you can fit a pointer in there. This lets you store a pointer or a full double by-value (and still have tag bits left for other types!). Last I checked LuaJIT and WebKit both still used this…

If you restrict yourself to all variants of x86 and ARM, the number of high bits for which I could not find conflicting uses is 6 bits (bits 57-62). The other high bits are reserved in some hardware contexts and therefore may create conflicts. Using 16 bits may be risky on recent x86. For example, IIRC Linux enables 5-level page tables on microarchitectures that support it, which can put valid address data in bits 48…

> Using 16 bits may be risky on recent x86. For example, IIRC Linux enables 5-level page tables on microarchitectures that support it, which can put valid address data in bits 48-56.

Linux will not allocate past the 47-bit range, even with 5-level paging enabled, unless specifically requested, by providing a pointer hint to `mmap` with a higher address.

https://www.kernel.org/doc/html/v5.14/x86/x86_64/5level-pagi...

Post reply on HN