> Looking forward, we're also seeing exciting and promising developments in hardware. Technologies like ARM's Memory Tagging Extension (MTE) and the Capability

> Looking forward, we're also seeing exciting and promising developments in hardware. Technologies like ARM's Memory Tagging Extension (MTE) and the Capability Hardware Enhanced RISC Instructions (CHERI) architecture offer a complementary defense, particularly for existing code. IIRC there's some way that a Python C extension can accidentally disable the NX bit for the whole process.. https://news.ycombinator.com/item?id=40474510#40486181 https://news.ycombinator.com/item?id=40474510#40486181 : >>> IIRC, with CPython the NX bit doesn't work when any imported C extension has nested functions / trampolines >> How should CPython support the mseal() syscall? [which was merged in Linux kernel 6.10] > We are collaborating with industry and academic partners to develop potential standards, and our joint authorship of the recent CACM call-to-action marks an important first step in this process. In addition, as outlined in our Secure by Design whitepaper and in our memory safety strategy, we are deeply committed to building security into the foundation of our products and services. > That's why we're also investing in techniques to improve the safety of our existing C++ codebase by design, such as deploying hardened libc++. Secureblue; https://github.com/secureblue/Trivalent https://github.com/secureblue/Trivalent has hardened_malloc. Memory safety notes and Wikipedia concept URIs: https://news.ycombinator.com/item?id=33563857 https://news.ycombinator.com/item?id=33563857 ... A graded memory safety standard is one aspect of security. > Tailor memory safety requirements based on need: The framework should establish different levels of safety assurance, akin to SLSA levels, recognizing that different applications have different security needs and cost constraints. Similarly, we likely need distinct guidance for developing new systems and improving existing codebases. For instance, we probably do not need every single piece of code to be formally proven. This allows for tailored security, ensuring appropriate levels of memory safety for various contexts. > Enable objective assessment: The framework should define clear criteria and potentially metrics for assessing memory safety and compliance with a given level of assurance. The goal would be to objectively compare the memory safety assurance of different software components or systems, much like we assess energy efficiency today. This will move us beyond subjective claims and towards objective and comparable security properties across products.