71–80 of 147 posts
It seems very strange to me to finally get around to this right as we are finally getting low level software that no longer needs it (and we've had high level software that doesn't need it for ages). At this point I think I'd prefer the transistor budget and bits of memory were spent on other things.
Earlier quoted context omitted.
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.
Also, some vendors use a non-optimal hamming code that fails to notice some double bit errors (if I remember right).
Would this imply an architecture similar to what Lisp-Machines once had ? That'd be a great addition IMO, and would speed up a lot of dynamic-ish languages without resorting to unsafe-routes for speed.
It seems very strange to me to finally get around to this right as we are finally getting low level software that no longer needs it (and we've had high level software that doesn't need it for ages). At this point I think I'd prefer the transistor budget and bits of memory were spent on other things.
Rust code that uses unsafe still needs this sort of protection.
There's also been steady progress towards creating systems to prove unsafe rust correct - at which point it wouldn't even benefit from this. For example see the work amazon has been sponsoring to prove the standard library correct: https://github.com/model-checking/verify-rust-std/
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 v…
But wait, how do you know that's what this is? The reason I'm negative is the entire article has zero detail on WTF this instruction set is or does. The best you can do is guess from the name of the instruction set. Compare the linked iPhone article to this blog and you'll quickly see the difference. There's very real discussion in the MTE article of how the instructions work and what they do. This article just says…
IIRC, later SPARC64 chips also had a version of this.
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…
It’s just probabilistic memory safety, at best Still cool, but not a replacement for memory safety language implementations.
It seems very strange to me to finally get around to this right as we are finally getting low level software that no longer needs it (and we've had high level software that doesn't need it for ages). At this point I think I'd prefer the transistor budget and bits of memory were spent on other things.
It seems very strange to me to finally get around to this right as we are finally getting low level software that no longer needs it (and we've had high level software that doesn't need it for ages). At this point I think I'd prefer the transistor budget and bits of memory were spent on other things.
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, for better or worse.