6 ms·
ChkTag: x86 Memory Safety
- sparkie 1y agoSparse 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.
- monocasa 1y agoNot a whole lot of language runtimes (if any) really depend on upper address ignore. AFAIK, AMD only added it in Zen4.
- fooker 1y agoLua does
- pansa2 1y agoI 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?
- sparkie 1y agoIt'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.
- wahern 1y agoPUC 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.
- erichocean 1y agoThe 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 https://www.youtube.com/watch?v=y_QeST7Axrw
- monocasa 1y agoThe JVM optionally does it. It does not rely on it.
- sparkie 1y agoYou don't need the hardware UAI/LAM to make use of the high pointer bits. The most common technique is to use `shl reg, 16; sar reg, 16`, which will shift in ones or zeros from the left depending on the 47th bit. Several runtimes use high bits tagging combined with NaN-boxing, and have been doing so since before LAM/UAI existed.
- wbl 1y agoDynamic 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.
- monocasa 1y agoDepends on the architecture. Top bit usage lets you do what the hardware thinks if as an 'is negative' check for very cheap on a lot of archs for instance.
- themafia 1y agoIs it a guarantee that a 16 byte object would be 16 byte aligned?
- ComputerGuru 1y agoNo. It depends on the object.
- vidarh 1y agoNot in general, but it is a guarantee a runtime where all allocation are 16 byte cons cells can choose to make quite trivially.
- bluGill 1y agoIf you implement malloc you can do that. The os generally gives you 4k (or other number in that range) at a time and malloc subdivides it. language runtimes can call malloc whatever they want.
- secondcoming 1y agoIn C++ you can force that with alignas(), I would imagine other low level languages offer something similar. If you're using a custom allocator you'd have to enfore it yourself which should be fine since you have full control. https://en.cppreference.com/w/cpp/language/alignas.html https://en.cppreference.com/w/cpp/language/alignas.html
- IshKebab 1y agoI highly doubt this is anything like CHERI. More likely it's their version of ARM MTE.
- thayne 1y agoDoesn't CHERI use additional bits to store the capabilities rather than masking existing bits in the pointer? But that can be problematic for any code that assumes that the size of pointers is the same as size_t/usize. I don't see how this could not be opt in for backwards compatibility though, since existing code wouldn't use the new instructions.
- Tuna-Fish 1y agoI 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.
- georgeburdell 1y agoI wonder what happened that Apple/ARM has implemented something similar at nearly the same time. https://security.apple.com/blog/memory-integrity-enforcement/ https://security.apple.com/blog/memory-integrity-enforcement...
- astrange 1y agoIntel already tried it once in 2019, failed and had to remove it. https://en.wikipedia.org/wiki/Intel_MPX https://en.wikipedia.org/wiki/Intel_MPX
- jpecar 1y agoAfaik Intel's first foray into this territory was their i960mx which ended up in F-22.
- monocasa 1y agoEven before then the iAPX432 had object capability security wrt its memory.
- monocasa 1y agoI remember playing with it and finding out it was slower than just manual bounds checks in front of every memory access.
- noir_lord 1y agoDon't think it was any one thing so much as it makes a whole bunch of attacks more difficult - security is a perpetual arms race after all.
- MBCook 1y agoI agree it would’ve happened no matter what, it’s a very useful feature. I do wonder if Apple‘s announcement that they started shipping it may have pushed them to announce this/agree to a standard earlier than they would have otherwise.
- superkuh 1y agoI 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.
- tredre3 1y agoIf 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, even on Linux, it's possible to make memory regions inaccessible even to root or the kernel itself. The time to be worried about that was 10 years ago.
- Pannoniae 1y ago"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!
- superkuh 1y agoI have a patch set to removes virtual memory interprocess blocking for linux 5.6 that I run as kernel on a couple of my machines. I'm just hoping that this is patchable out too.
- muricula 1y agoIs there a whitepaper or ISA manual change describing the feature?
- haunter 1y agoChkTag doesn't exist yet, they are working on it
- LoganDark 1y agoSo they really did see Apple announce MIE and rush to come up with something similar.
- saagarjha 1y agoNo.
- LoganDark 1y agoApple 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).
- saagarjha 1y agoI don't see the panic. They've been working on it for a while, it's inspired by MTE if anything.
- 1y ago
- pizlonator 1y agoIt’s just probabilistic memory safety, at best Still cool, but not a replacement for memory safety language implementations.
- OneDeuxTriSeiGo 1y agoMemory 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).
- levodelellis 1y agoI'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
- pizlonator 1y agoMy motivation is that I love to write compilers
- levodelellis 1y agoThat'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)
- 1y ago
- cogman10 1y agoGarbage article. Like, cool, you guys are starting to talk about a new instruction set that will make C safe somehow. Yet you failed provide an ounce of detail for how you'll accomplish that. This might as well been a "And we'll make our CPUs 10x faster and they'll use 10x less power!". Or "Future CPUs will have a 10ghz clock speed!" Again, who is this article for? The government maybe to assure them that x86 will take cyber security seriously?
- xattt 1y ago> 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.
- cogman10 1y agoI'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.
- timschmidt 1y agoHonestly it could have, if Intel had invested in the platform for more than a few generations and built the software ecosystem around it. It had on package HBM before it was cool with all the modern AI GPUs and APUs. Intel had the opportunity to build the CUDA ecosystem, and chose to shelve it. I'll never understand the obsession that new platforms must be profitable immediately. Seems they take ~10 years to develop, and planning for that should be part of what's expected before the decision is made. Gelsinger seemed to understand at least that much.
- cogman10 1y agoWell, they did half-heartedly try at it. Intel Phi was produced from 2010->2020. I think the problem is that Intel pigeonholed the product, relegating it to just supercomputers. I also think Intel has historically done a bad job of supporting the software needed to power their hardware. The reason CUDA was so successful (IMO) is because it was highly available and the software is a better quality to competitive software. OpenCL was supposed to be the answer to CUDA and ultimately it was just a weird, hard to work with, and minimally supported language. I don't think that's all Intel's fault. Apple's dumb war against Khronos has really undermined a lot of progress for anyone doing GPGPU programming.
- monocasa 1y ago[flagged]
- pixelpoet 1y agolest*: https://en.wiktionary.org/wiki/lest https://en.wiktionary.org/wiki/lest
- monocasa 1y ago[flagged]
- ummonk 1y agoThen write "less that the" if you prefer not to use the contraction.
- monocasa 1y ago[flagged]
- felixfurtak 1y ago> 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. Here are a few ways to write the sentence correctly, depending on the desired level of formality: 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."
- zdw 1y agoNow they just need to agree to implement ECC everywhere instead of using it as a product differentiator, so we can reduce the amount of random issues caused by memory and bus errors.
- packetlost 1y agoThis is already the case in DDR5.
- ploxiln 1y agoNot really. ECC memory will have an extra ram chip, and store an extra bit per byte or so, for that error detection/correction. DDR5 only has error-correction bits added to the bus, regular DDR5 doesn't have extra chips/bits for error correction of the data while it is stored. But also, what you really want is ECC that reports all the way up to the OS the corrected and un-corrected bits. This is how you know if it's on the edge, becoming a real problem. Otherwise, it works fine until it doesn't shrug which is the same as regular normal memory. I think the ECC added to the DDR5 bus is kinda just enough to get the higher data-rate signaling to be as reliable as DDR4. It's nice for marketing to put ECC on the DDR5 box but it's not more robust than DDR4.
- timschmidt 1y agoThis is an oft-repeated misunderstanding. DDR5 memory uses error correcting codes internally to correct on-die errors, but this does not defend against errors on busses between the DIMM and memory controller. For that the old scheme of extra chips to store additional ECC data is still the only way.
- hedora 1y agoIt actually does protect against errors on access, but support is optional. Also, some vendors use a non-optimal hamming code that fails to notice some double bit errors (if I remember right).
- 1y ago
- tdullien 1y agoWith all the negative comments here: This is existing technology on ARM64 (MTE) and on modern iPhones (https://security.apple.com/blog/memory-integrity-enforcement/ 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_4ZO9fFOO1PZQTNODu2XarcXhlZTGaktBwc4EAHjL8/edit?usp=sharing https://docs.google.com/presentation/d/1V_4ZO9fFOO1PZQTNODu2... In general, having this come to x86 is long-overdue and very welcome.
- cogman10 1y agoBut 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!"
- eigenform 1y agoProbably 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.
- 1y ago
- chmorgan_ 1y agoLooks like this is in response to the Apple paper from a couple of weeks ago about memory tagging. Excellent news even if this wasn't pushed along by Apple.
- eigenform 1y agofwiw "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.
- OneDeuxTriSeiGo 1y agoI 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 levels of overhead (~5-10%) with the ability to alternate between synchronous and asynchronous tracing of faults where the latter has a much lower overhead than the former (allowing you to check in production for very little overhead and get better debugging in test). They also work essentially seamlessly with the rest of the ARM ecosystem and it takes very little to integrate the functionality into any language ecosystem or toolchain. If MPX was comparable with MTE, it certainly would have gotten the adoption that MTE is getting but the "tech" just wasn't there to justify it's use.
- eigenform 1y agoI'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.
- OneDeuxTriSeiGo 1y agofair.
- casey2 1y agoMemory Saftey®
- raverbashing 1y agoIt's ok the C committee will make sure to fumble this up even with HW support
- pjmlp 1y agoI don't have any hopes WG14 will ever care to improve C's safety beyond what is possible manually writting Assembly code, it is even worse because Assembly doesn't have time travel with UB.
- gpm 1y agoIt 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.
- hedora 1y agoRust code that uses unsafe still needs this sort of protection.
- gpm 1y ago"Needs" is a strong word, would benefit from a bit, but in practice I think the number of vulnerabilities rust code typically has is not large enough to justify the expense of compromising the performance of every CPU ever sold (thus requiring more, consuming more energy, etc). There's also been steady progress towards creating systems to prove unsafe rust correct - at which point it wouldn't even benefit from this. For example see the work amazon has been sponsoring to prove the standard library correct: https://github.com/model-checking/verify-rust-std/ https://github.com/model-checking/verify-rust-std/
- vlovich123 1y agoA good chunk of Rust code often ends up linking in a C/C++ library where it’s still a concern (and this is ignoring that unsafe Rust is actually harder and more unsafe than C currently). More importantly there’s millions if not billions of existing lines of C/C++ not least of which is the VMs for “memory safe” languages like Java. There’s huge value add in automatically adding security for a fractional CPU cost since the world won’t be rewritten into Rust anytime soon.
- a-dub 1y agoit's like the end scene in fight club. except instead of credit card company office towers it's the borrow checker and associated skyscrapers that symbolize the ascent of rust that are going down in flames as the x86 antiheroes high five and the pixies start crooning "where is my mind" to rolling credits over the burning cityscape.
- akssri 1y agoThe article seems sparse on details. Would this imply an architecture similar to what Lisp-Machines once had ? That'd be a great addition IMO, and would speed up a lot of dynamic-ish languages without resorting to unsafe-routes for speed.
- Uptrenda 1y agoThey should standardize what's going on in Intel ME and AMD PSP (they won't since both are backdoors.)
- userbinator 1y agoTo bring Corporate Authoritarianism to x86... It's scary how much of the population will suddenly shut off their brains whenever "safety and security" or similar phrases are mentioned.
- pjmlp 1y agoLooking forward to this as x86 is the one lagging behind other CPUs on this matter, note that this is the second attempt, MPX did not went that well. https://en.wikipedia.org/wiki/Intel_MPX https://en.wikipedia.org/wiki/Intel_MPX
- Panzerschrek 1y agoIt 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?
- IshKebab 1y agoIf 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.
- yvdriess 1y agoIf 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.