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

11–20 of 147 posts

Re: ChkTag: x86 Memory Safety

#11

Post by xattt »

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…

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

Re: ChkTag: x86 Memory Safety

#12

Post by fweimer »

georgeburdell wrote: post #3

I wonder what happened that Apple/ARM has implemented something similar at nearly the same time. https://security.apple.com/blog/memory-integrity-enforcement...

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.

Re: ChkTag: x86 Memory Safety

#13

Post by cogman10 »

xattt wrote: post #11
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…

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

Re: ChkTag: x86 Memory Safety

#15

Post by preisschild »

fweimer wrote: post #12
georgeburdell wrote: post #3

I wonder what happened that Apple/ARM has implemented something similar at nearly the same time. https://security.apple.com/blog/memory-integrity-enforcement...

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.

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

Re: ChkTag: x86 Memory Safety

#16

Post by jpecar »

astrange wrote: post #7
georgeburdell wrote: post #3

I wonder what happened that Apple/ARM has implemented something similar at nearly the same time. https://security.apple.com/blog/memory-integrity-enforcement...

Intel already tried it once in 2019, failed and had to remove it. https://en.wikipedia.org/wiki/Intel_MPX

Afaik Intel's first foray into this territory was their i960mx which ended up in F-22.

Re: ChkTag: x86 Memory Safety

#17

Post by monocasa »

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.

Re: ChkTag: x86 Memory Safety

#18

Post by monocasa »

astrange wrote: post #7
georgeburdell wrote: post #3

I wonder what happened that Apple/ARM has implemented something similar at nearly the same time. https://security.apple.com/blog/memory-integrity-enforcement...

Intel already tried it once in 2019, failed and had to remove it. https://en.wikipedia.org/wiki/Intel_MPX

I remember playing with it and finding out it was slower than just manual bounds checks in front of every memory access.

Re: ChkTag: x86 Memory Safety

#19

Post by monocasa »

jpecar wrote: post #16
astrange wrote: post #7

Earlier quoted context omitted.

Intel already tried it once in 2019, failed and had to remove it. https://en.wikipedia.org/wiki/Intel_MPX

Afaik Intel's first foray into this territory was their i960mx which ended up in F-22.

Even before then the iAPX432 had object capability security wrt its memory.

Re: ChkTag: x86 Memory Safety

#20

Post by wbl »

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.

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