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

91–100 of 147 posts

Re: ChkTag: x86 Memory Safety

#91

Post by musicale »

gpm wrote: post #89
musicale wrote: post #80

Earlier quoted context omitted.

> we are finally getting low level software that no longer needs it Ada has had memory safety for decades – not to mention Lisp, Java, etc. if you can live with garbage collection. Even PL/I was better than C for memory safety, which is why Multics didn't suffer from buffer overflows and Unix did. But the Linux kernel (along with lots of other software which we would like to be reliable) is still mostly written in C,…

> Ada has had memory safety for decades Only with spark (i.e. formal verification). Which similar to other projects of this age (e.g. Rocq/How the compcert C compiler was implemented and proved correct) seems not to be low enough friction to get widescale adoption. > not to mention Lisp, Java, etc. if you can live with garbage collection. Like I said, high level languages that won't benefit from this at all have exis…

> Fil-C shows this can be solved at the software layer for things in this category that can afford the overhead of a GC.

Mainline clang and g++ are also getting better with things like -fbounds-safety and -fsanitize=address. As I understand it, they typically have some overhead, but I'm willing to accept that overhead to have a kernel, web browser, etc. without memory errors. The decision that memory safety is too costly seems to have been made when CPUs were orders of magnitude slower than they are today. Hopefully hardware support will reduce the overhead to negligible proportions and enable memory safety as a default rather than an esoteric add-on or proprietary feature.

Re: ChkTag: x86 Memory Safety

#92

Post by tines »

felixfurtak wrote: post #69
monocasa wrote: post #53

Earlier quoted context omitted.

[flagged]

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

Your AI explanation offers nothing in the way of why it's not fine. It just asserts that it's not fine. I agree with the AI, but your summary is wrong.

Re: ChkTag: x86 Memory Safety

#93

Post by wtallis »

hedora wrote: post #72
timschmidt wrote: post #34

Earlier quoted context omitted.

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.

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

> It actually does protect against errors on access, but support is optional.

Can you explain how exactly the on-die ECC capability can help protect data in transit? What is the optional functionality you're referring to, if not the traditional sideband ECC achieved by adding another chip's worth of data lines to every channel?

Re: ChkTag: x86 Memory Safety

#95

Post by pizlonator »

SchemaLoad wrote: post #78
pizlonator wrote: post #6

It’s just probabilistic memory safety, at best Still cool, but not a replacement for memory safety language implementations.

MTE is as much a detection tool as it is a relied on layer of defence. I read that it has a 15 out of 16 chance to catch an error. Which means even if you do find a bug, it's going to be logged back to the OS vendor essentially the first time you use it. Getting patched permanently in the source.

Any real world software has crashes that don’t get fixed.

So you’d really have to use the attack a lot for it to get patched.

Re: ChkTag: x86 Memory Safety

#96

Post by MBCook »

noir_lord wrote: post #9
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...

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.

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

Re: ChkTag: x86 Memory Safety

#97

Post by musicale »

gpm wrote: post #89
musicale wrote: post #80

Earlier quoted context omitted.

> we are finally getting low level software that no longer needs it Ada has had memory safety for decades – not to mention Lisp, Java, etc. if you can live with garbage collection. Even PL/I was better than C for memory safety, which is why Multics didn't suffer from buffer overflows and Unix did. But the Linux kernel (along with lots of other software which we would like to be reliable) is still mostly written in C,…

> Ada has had memory safety for decades Only with spark (i.e. formal verification). Which similar to other projects of this age (e.g. Rocq/How the compcert C compiler was implemented and proved correct) seems not to be low enough friction to get widescale adoption. > not to mention Lisp, Java, etc. if you can live with garbage collection. Like I said, high level languages that won't benefit from this at all have exis…

> Only with spark (i.e. formal verification)

Ada's original memory safety was still a lot better than C's. As noted, PL/I was not 100% memory safe, but it was good enough to prevent buffer overflows in Multics.

Re: ChkTag: x86 Memory Safety

#98

Post by MBCook »

saagarjha wrote: post #70
LoganDark wrote: post #65

Earlier quoted context omitted.

Apple 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 wit…

I don't see the panic. They've been working on it for a while, it's inspired by MTE if anything.

I’m sure it was, Intel has tried this before. It’s a good idea.

But it wouldn’t surprise me if Apple‘s announcement they were shipping it already pushed Intel and AMD to agree on implementation details so they could announce this and get it going.

Re: ChkTag: x86 Memory Safety

#99

Post by jandrewrogers »

afishhh wrote: post #45
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.

There's a technique known as "NaN boxing" which exploits the fact double precision floats allow you to store almost 52 bits of extra data in what would otherwise be NaNs. If you assume the top 16 bits of a pointer are unused[1], you can fit a pointer in there. This lets you store a pointer or a full double by-value (and still have tag bits left for other types!). Last I checked LuaJIT and WebKit both still used this…

If you restrict yourself to all variants of x86 and ARM, the number of high bits for which I could not find conflicting uses is 6 bits (bits 57-62). The other high bits are reserved in some hardware contexts and therefore may create conflicts.

Using 16 bits may be risky on recent x86. For example, IIRC Linux enables 5-level page tables on microarchitectures that support it, which can put valid address data in bits 48-56.

There is no guarantee that those 6 bits are safe either. They are just the only bits for which I could not find existing or roadmap usage across x86 and ARM sources when I last did a search.

Post reply on HN