I suspect that the solution to unsafe languages like C/C++ will end being a small sanitizer runtime like CFI(https://dslab.epfl.ch/research/cpi/), that also supports some form of extended MTE, for memory safety.
This seems much more realistic than e.g. Microsoft rewriting Excel in Rust with bug for bug compatibility. It would also benefit Rust code, that has sections marked as unsafe.
Microsoft just announced 10 million dollar effort to make Rust their default systems language for their infrastructure, plus an additional million to the Rust foundation.
Yes, stuff like MTE will help, and what you mention is already being used on Android, see HWSAN, and there is now some movement regarding C++ security profiles, however there is still a very long way to go.
This is how Microsoft sees improving safety on C++ codebases,
That site still lists 2x CPU overhead. I am fuzzy on details but I believe some variant is in the works that has low enough overhead to enable in the wild. That site also just says it uses TBI so possibly the performant version I am thinking of is just a version that uses full MTE?
Thank you! Technical writing 101 stuff, especially when MTE as an acronym has a lot of common definitions.
Took me multiple queries to locate the definition for myself. There's the communications company, the finance definition, the adjacency to the term LTE, the common slang use....etc.
Despite the value this offers I'm not keen to be a guinea pig, especially as the Pixel 8 Pro already has some unpredictable lagginess with software already, so I don't want to add to the mix with additional things that could confuse diagnosis.
The most annoying is the PDF viewer gets stuck but it happens with other things intermittently. It's frustrating as these things worked fine on the Pixel 6 Pro under Android 14, so they seem like reversions or maybe something different on a system level/perhaps even hardware related (but I've not looked into it to be able to tell).
What other issues are you having with the Pixel 8? I'm reading reports of overheating, battery drain and bad cellular connectivity on the new Pixel. Have you experienced this?
Haven't had over heating or battery drain issues fortunately (battery is one area it's markedly improved as my previous phone was around 2 years old)
The connectivity could be better but it's hard to be sure this is the phone and not the network where I live/work.
So really it's just the freezes with the software - mainly the built in PDF viewer I mentioned but also the camera at times and the keyboard does odd things where it gets stuck only accepting single key presses (ie no swiping through words). The lag issue seems to appear most when switching back to an app rather than during continuous use.
Ugh, I thought it would be a switch in settings. It is a lot of work at this point to enable it.
What was fascinating to me was that they are already picking up bugs in existing apps, which is a plus in that even having a small number of people running this will provide security for the rest of us that aren't running it by finding buggy and malicious apps.
I had the same question, and it reminded me of a HN submission from roughly a year ago on a similar topic: The Talos II, Blackbird POWER9 systems support tagged memory[0]
>Nowadays, there is increasing interest in adding tagged memory functionality to CPU architectures. Such architectures associate one or more tag bits with each quantum of a system's memory. There are many motivations for this ability to associate “metadata” with individual memory words, but one of the most clear is the potential security benefits and the ability to track the providence of certain kinds of data in memory, such as pointers. This can be used to create capability-based architectures such as CHERI.
Based on that last sentence, one may reason that this MTE feature for ARM could be a basis for implementing CHERI on ARM.
For hot parts of the code that the sanitizer can guarantee is safe, either due to it being trivial or with annotations(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27...), it can safely exclude these checks to limit performance impact.
This seems much more realistic than e.g. Microsoft rewriting Excel in Rust with bug for bug compatibility. It would also benefit Rust code, that has sections marked as unsafe.