[HN Gopher] Intel and AMD standardise ChkTag to bring Memory Saf...
___________________________________________________________________
Intel and AMD standardise ChkTag to bring Memory Safety to x86
Author : ashvardanian
Score : 73 points
Date : 2025-10-14 18:04 UTC (6 days ago)
(HTM) web link (community.intel.com)
(TXT) w3m dump (community.intel.com)
| sparkie wrote:
| 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.
| monocasa wrote:
| Not a whole lot of language runtimes (if any) really depend on
| upper address ignore.
|
| AFAIK, AMD only added it in Zen4.
| fooker wrote:
| Lua does
| erichocean wrote:
| 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
| wbl wrote:
| 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.
| monocasa wrote:
| Depends 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 wrote:
| Is it a guarantee that a 16 byte object would be 16 byte
| aligned?
| ComputerGuru wrote:
| No. It depends on the object.
| vidarh wrote:
| Not _in general_ , but it is a guarantee a runtime where
| all allocation are 16 byte cons cells can choose to make
| quite trivially.
| bluGill wrote:
| If 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.
| IshKebab wrote:
| I highly doubt this is anything like CHERI. More likely it's
| their version of ARM MTE.
| georgeburdell wrote:
| I wonder what happened that Apple/ARM has implemented something
| similar at nearly the same time.
| https://security.apple.com/blog/memory-integrity-enforcement...
| astrange wrote:
| Intel already tried it once in 2019, failed and had to remove
| it.
|
| https://en.wikipedia.org/wiki/Intel_MPX
| jpecar wrote:
| Afaik Intel's first foray into this territory was their
| i960mx which ended up in F-22.
| monocasa wrote:
| Even before then the iAPX432 had object capability security
| wrt its memory.
| monocasa wrote:
| I remember playing with it and finding out it was slower than
| just manual bounds checks in front of every memory access.
| noir_lord wrote:
| Don'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.
| fweimer wrote:
| Arm MTE is much older. Android already supported it with a
| limited number of devices:
| https://developer.android.com/ndk/guides/arm-mte
|
| There is server hardware out there now that in theory can
| support MTE, but I don't know if there's commercial support for
| it. MTE needs to be set up by the firmware, it's not purely an
| OS/kernel matter.
| preisschild wrote:
| GrapheneOS (hardened Android distribution) also has it
| enabled by default for the base OS and user-installed Apps
| that support it (you can also force it for all apps) on 8th
| Gen Google Pixels and newer
|
| Interesting thread:
|
| https://grapheneos.social/@GrapheneOS/113223437850603601
| superkuh wrote:
| 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.
| muricula wrote:
| Is there a whitepaper or ISA manual change describing the
| feature?
| haunter wrote:
| ChkTag doesn't exist yet, they are working on it
| LoganDark wrote:
| So they really did see Apple announce MIE and rush to come up
| with something similar.
| pizlonator wrote:
| It's just probabilistic memory safety, at best
|
| Still cool, but not a replacement for memory safety language
| implementations.
| cogman10 wrote:
| Garbage 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 wrote:
| _> 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 wrote:
| 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.
| fooker wrote:
| Given that this technique is used in production for all current
| gen Iphones should tell you this isn't vaporware.
| monocasa wrote:
| > This is a general data security concern, including for AI data,
| which governments have urged companies to defend against.
|
| Had to find some way to use "AI" in a press release, less the
| stock gods get angry and vengeful.
| pixelpoet wrote:
| lest*: https://en.wiktionary.org/wiki/lest
| monocasa wrote:
| As your citation says, lest is an Old English contraction of
| 'less [pronoun that starts with th]'.
| ummonk wrote:
| Then write "less that the" if you prefer not to use the
| contraction.
| zdw wrote:
| Now 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 wrote:
| This is already the case in DDR5.
| ploxiln wrote:
| Not 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 wrote:
| This 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.
| tdullien wrote:
| 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 very
| welcome.
___________________________________________________________________
(page generated 2025-10-20 23:00 UTC)