Memory safety and network security
US government has issued documents promoting memory safe languages (MSLs) like Rust, C#, Java, Go and others, while advising to shift away from languages such as C, C++ and Assembly. Notable documents include
These documents emphasize not only software safety but also security concerns. The C++ community has been actively addressing these issues and clarifying the distinction between safety and security, e.g. reference these two talks and the recent CppCon discussion panel:
The safety and security issues are crucial for us because we develop both secure and security-focused Internet server software. By “security-focused”, we refer to software that actively blocks malicious traffic as a core feature – for example, our open source hybrid of web accelerator and application firewall (WAF) Tempesta FW, or the proprietary volumetric DDoS mitigation proprietary module, Tempesta xFW. By “secure”, we mean general-purpose server software, such as an S3 server, which may not implement extensive security logic but must be inherently robust to withstand hacker attacks. These types of software are deployed at the network edge, where reliability is crucial. A failure at this level can render a company’s services completely inaccessible to its clients.
On the other hand, we use C, C++ and Assembly languages for the development of this software. The reason is that edge software has extremely demanding performance requirements – the servers must deliver high throughput and low latency, even under high-percentile load conditions. These stringent requirements significantly limit the choice of MSLs; in particular, only Rust could be a viable alternative. However, as we demonstrate below, many tasks – particularly the most complex ones – cannot be implemented using safe Rust code.
