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

121–130 of 147 posts

Re: ChkTag: x86 Memory Safety

#121

Post by IshKebab »

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

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.)

Re: ChkTag: x86 Memory Safety

#122

Post by tdullien »

mshroyer wrote: post #105
pizlonator wrote: post #102

Earlier quoted context omitted.

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.

I don't know tbh, and I gave that talk when I was in terrible shape, so I'm not upset ;).

If people care a lot, I can record a YouTube video on the topic.

Re: ChkTag: x86 Memory Safety

#123

Post by IshKebab »

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 it's anything like CHERI, you need to make sure to follow pointer provenance rules properly (called "strict provenance" in Rust) and then just recompile your program with some extra flags. Only low level memory-related things like allocators and JITs need any significant source code changes.

Re: ChkTag: x86 Memory Safety

#124

Post by tdullien »

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…

So there's a long intellectual history behind these technologies, and Intel had multiple chances of taking the leadership on this around 2018 - they failed to do so, some of the talent went to Apple, and now Intel has to play catch-up.

I'm pretty certain it'll be the x86 variant of either MTE or MIE.

Re: ChkTag: x86 Memory Safety

#125

Post by pjmlp »

linksnapzz wrote: post #76
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…

This is how, amongst other things, IBM POWER cpus do memory tagging for capability-based security on iSeries/OS400. IIRC, later SPARC64 chips also had a version of this.

ADI, since 2015, still shipping.

Re: ChkTag: x86 Memory Safety

#126

Post by fweimer »

linksnapzz wrote: post #76
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…

This is how, amongst other things, IBM POWER cpus do memory tagging for capability-based security on iSeries/OS400. IIRC, later SPARC64 chips also had a version of this.

According to this: https://www.devever.net/~hl/ppcas the POWER approach is not a true hardware capability architecture (“nothing about these ISA extensions provides any kind of security invariant against a party which can generate arbitrary machine code”). It's just something that helps software to store one bit per 128 bits of data on the side (plus some other weirdness about load-with-offset instructions).

(SPARC ADI is similar, machine code is still trusted.)

Re: ChkTag: x86 Memory Safety

#127

Post by fweimer »

themafia wrote: post #24
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.

Is it a guarantee that a 16 byte object would be 16 byte aligned?

Dynamic languages usually come with their own memory manager. They can come up with their own alignment constraints. That being said, most contemporary (Linux) architectures require that malloc returns 16 byte alignned pointers. Some mallocs only promise this for allocations larger than 8 bytes, though (and I think the C standard was updated to permit that).

Re: ChkTag: x86 Memory Safety

#128

Post by transpute »

mshroyer wrote: post #105
pizlonator wrote: post #102

Earlier quoted context omitted.

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.

https://vimeo.com/252868605

Re: ChkTag: x86 Memory Safety

#129

Post by fweimer »

ksherlock wrote: post #44
themafia wrote: post #24

Earlier quoted context omitted.

Is it a guarantee that a 16 byte object would be 16 byte aligned?

For memory allocation, POSIX (posix_memalign) has been guaranteeing alignment since 2001. C11 added equivalent functionality (aligned_alloc). C++17 incorporated it (std::aligned_alloc) as well.

More importantly, C++17 no longer ignores alignment in dynamic memory allocation: https://en.cppreference.com/w/cpp/memory/new/operator_new

C++11 already had alignas, but it was not really integrated well.

Re: ChkTag: x86 Memory Safety

#130

Post by wahern »

sparkie wrote: post #114
pansa2 wrote: post #68

Earlier quoted context omitted.

I thought one of Lua’s selling points is that it’s written in highly standard-compliant C code. I wouldn’t expect it to do anything non-portable like bitwise manipulation of pointers?

It's fine to use techniques like this in standard C provided you guard them with the preprocessor and provide a fallback option on unsupported hardware.

PUC Lua doesn't use these tricks; every value in the VM is represented with a POD struct with explicit tag and value members. The OP may have been thinking of LuaJIT, which uses NaN boxing, but not pointer tagging.

PUC Lua does rely on two's complement integer representation, though, as well as long long, while nominally adhering to C90, so not quite strictly conforming.

Post reply on HN