Probabilistic Arm MTE memory safety is a stepping stone to deterministic CHERI hardware, https://saaramar.github.io/memory_safety_blogpost_2022/ https://saarama

Probabilistic Arm MTE memory safety is a stepping stone to deterministic CHERI hardware, https://saaramar.github.io/memory_safety_blogpost_2022/ https://saaramar.github.io/memory_safety_blogpost_2022/ & https://news.ycombinator.com/item?id=39668053 https://news.ycombinator.com/item?id=39668053 The right kind of mitigations targets the 1st order primitive; the root cause of the bug. Hardware solutions: CHERI (Morello, CheriIoT), MTE Software mitigations: kalloc_type+dataPAC, AUTOSLAB, Firebloom, GuardedMemcpy, CastGuard, attack surface reduction Safe programming languages: Rust, Swift MTE/CHERI play pretty nicely - they help ensure that whatever bugs we have in these areas are killed at their root cause… MSR, MSRC and Azure Silicon pushed for… scaling CHERI down to RISC-V32E, the smallest core RISC-V specification. Microsoft Research open-sourced a hardware/software stack for CHERI in IoT devices, https://msrc.microsoft.com/blog/2023/02/first-steps-in-cheriot-security-research/ https://msrc.microsoft.com/blog/2023/02/first-steps-in-cheri... CHERI-based microcontroller that aims to… get very strong security guarantees if we are willing to co-design the instruction set architecture (ISA), the application binary interface (ABI), isolation model, and the core parts of the software stack… our microcontroller achieves the following security properties: Deterministic mitigation for spatial safety (using CHERI-ISA capabilities). Deterministic mitigation for heap and cross-compartment stack temporal safety (using a load barrier, zeroing, revocation, and a one-bit information flow control scheme). Fine-grained compartmentalization (using additional CHERI-ISA features and a tiny monitor). David Chisnall, U of Cambridge, https://lobste.rs/s/gnjx2n/c_can_be_memory_safe#c_9ohzku https://lobste.rs/s/gnjx2n/c_can_be_memory_safe#c_9ohzku via https://eclypsium.com/blog/a-faster-path-to-memory-safety-cheri-memory-tagging-and-control-flow-integrity/ https://eclypsium.com/blog/a-faster-path-to-memory-safety-ch... > There are around 13 billion lines of open source C and C++, which end up in various TCBs. This number gets even bigger when you include proprietary code… if we all stopped writing C/C++ code now and every software engineer focused on rewriting legacy code in safe languages (and on the assumption that everything can be written in safe languages) then it would take 5-10 to replace everything and we’d likely see a lot of logic bugs because we’d be replacing old well-tested code with new code that would need different algorithms and data structures to fit with allowable idioms in safe languages. > If we didn’t do the rewriting thing and just stopped writing code in C/C++, then at normal code replacement rates, our TCBs would be entirely safe in around 50 years. If we don’t all agree to stop writing C/C++, it’s at least 100 years. > In contrast, if the major CPU vendors shipped CHERI CPUs in five years, most machines (and all high-value ones) would have memory safety within 15 years of today, without needing programmers to change their behaviour.