Addressing memory safety with software
In the previous post we looked at the underlying causes of memory unsafety which was using unsafe programming languages. In particular, C and C++ have been widely used for performance but at the same time carry risks of errors that cause unsafe memory accesses. Let’s now look at software approaches to mitigating memory unsafety.
Software mitigations
A variety of software mitigations have been proposed such as those listed by Saar Amar. The methods vary in granularity, determinism and implementation overhead.
Stack canaries
A well-known example of mitigating memory unsafety with software is the stack canary. If a program is executing and calls a subroutine, the address of the next instruction in the program is pushed onto the call stack and used as a return pointer (RP). When the subroutine has finished execution the return address is popped from the call stack.
To read the full article, click here
Related Semiconductor IP
- Over-Voltage Lockout (OVLO) IP
- Verification IP for Universal Chiplet Interconnect Express (UCIe) up to 3.0
- UCIe-S (Gen2) Compatible PHY for Standard Package (x16) in TSMC N3P, North/South Orientation
- DSP-Based 112G SerDes
- XTAL oscillator in TSMC-7nm
Related Blogs
- Software building blocks for faster functional safety certification
- Trillions of Cycles per Day: How SiFive Boosts IP and Software Validation with Synopsys HAPS Prototyping System
- Scaling Out Deep Learning (DL) Inference and Training: Addressing Bottlenecks with Storage, Networking with RISC-V CPUs
- Unlock early software development for custom RISC-V designs with faster simulation
Latest Blogs
- M31 High-Speed and Long-Channel MIPI C/D-PHY Solution on TSMC N3P/N3C
- Understanding security certification and how analog IP can help
- Embedded Security explained: Secure boot for embedded systems
- World's First Standards-Compliant 112G PHY IP for Linear Optics: A Turning Point for AI Interconnects
- One Key for Every Door: How Aliro Extends the UWB Digital Key Beyond the Car