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

31–40 of 147 posts

Re: ChkTag: x86 Memory Safety

#31

Post by ploxiln »

packetlost wrote: post #29
zdw wrote: post #28

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.

This is already the case in DDR5.

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.

Re: ChkTag: x86 Memory Safety

#32

Post by tdullien »

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.

Re: ChkTag: x86 Memory Safety

#33

Post by vidarh »

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?

Not in general, but it is a guarantee a runtime where all allocation are 16 byte cons cells can choose to make quite trivially.

Re: ChkTag: x86 Memory Safety

#34

Post by timschmidt »

packetlost wrote: post #29
zdw wrote: post #28

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.

This is already the case in DDR5.

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.

Re: ChkTag: x86 Memory Safety

#35

Post by fooker »

monocasa wrote: post #17
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.

Not a whole lot of language runtimes (if any) really depend on upper address ignore. AFAIK, AMD only added it in Zen4.

Lua does

Re: ChkTag: x86 Memory Safety

#36

Post by bluGill »

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?

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.

Re: ChkTag: x86 Memory Safety

#37

Post by fooker »

cogman10 wrote: post #10

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

Given that this technique is used in production for all current gen Iphones should tell you this isn't vaporware.

Re: ChkTag: x86 Memory Safety

#38

Post by erichocean »

monocasa wrote: post #17
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.

Not a whole lot of language runtimes (if any) really depend on upper address ignore. AFAIK, AMD only added it in Zen4.

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

Re: ChkTag: x86 Memory Safety

#39

Post by timschmidt »

cogman10 wrote: post #13
xattt wrote: post #11

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

Honestly 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.
Post reply on HN