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

21–30 of 147 posts

Re: ChkTag: x86 Memory Safety

#21

Post by monocasa »

wbl wrote: post #20
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.

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.

Re: ChkTag: x86 Memory Safety

#22

Post by IshKebab »

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.

I highly doubt this is anything like CHERI. More likely it's their version of ARM MTE.

Re: ChkTag: x86 Memory Safety

#24

Post by themafia »

wbl wrote: post #20
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.

Is it a guarantee that a 16 byte object would be 16 byte aligned?

Re: ChkTag: x86 Memory Safety

#27

Post by ComputerGuru »

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?

No. It depends on the object.

Re: ChkTag: x86 Memory Safety

#28

Post by zdw »

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