It's ok the C committee will make sure to fumble this up even with HW support
ChkTag: x86 Memory Safety
61–70 of 147 posts
Re: ChkTag: x86 Memory Safety
#62fwiw "knee-jerk reaction to Apple MIE" is not exactly the right characterization of this. MPX existed and faded away, and it's not very surprising that x86-world would wait for someone else to try shipping hardware support for memory safety features before trying again.
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.
Re: ChkTag: x86 Memory Safety
#63With 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…
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.
Re: ChkTag: x86 Memory Safety
#64Earlier quoted context omitted.
> Future CPUs will have a 10ghz clock speed! Glad to see Tejas finally making it to see the light of day! Can’t wait to pair it with my Larrabee GPU in my BTX case.
I'm happy another old hardware nerd got that dated reference :D. I was convinced back in the day that Larrabee would change the world. It seemed like such an amazing technology especially since multi-core CPUs were just starting to take off in consumer hardware.
[dead]
Re: ChkTag: x86 Memory Safety
#65Earlier quoted context omitted.
So they really did see Apple announce MIE and rush to come up with something similar.
No.
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 with their ecosystem partners in the EAG, to address the need for memory safety. They are creating a unified specification ..." (emphasis mine). They don't even have a specification yet, let alone an implementation, but they want to make PR waves about it already. This is so funny (and sad).
Re: ChkTag: x86 Memory Safety
#66With 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…
The x64 Windows Kernel is starting to get support for this. There are a few references to memory tagging appearing in the public symbol files.
Re: ChkTag: x86 Memory Safety
#67It 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.
Re: ChkTag: x86 Memory Safety
#68Earlier 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.
Lua does
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?
Re: ChkTag: x86 Memory Safety
#69Earlier quoted context omitted.
Then write "less that the" if you prefer not to use the contraction.
[flagged]
> The way I've used it is fine
No it's not. Here is the AI summary of why it isn't.
Breakdown of the Error
Less is used for uncountable quantities (e.g., "less water," "less time," "less anger").
Lest is a conjunction that means "for fear that" or "to avoid the possibility of." This is precisely the meaning the writer intends.
Direct Correction (Best for preserving the original tone):
"Had to find some way to use 'AI' in a press release, lest the stock gods get angry and vengeful."
Slightly More Formal:
"We had to find some way to use 'AI' in a press release for fear that the stock gods would get angry and vengeful."
Using "or" (Common modern alternative):
"Had to find some way to use 'AI' in a press release, or the stock gods will get angry and vengeful."Re: ChkTag: x86 Memory Safety
#70Earlier quoted context omitted.
No.
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.