Why we sponsor memory safety event Tectonics

Erik
Co-owner & Director of Open Source
Hugo
Co-owner & Business director
Why we sponsor memory safety event Tectonics
One of the hot topics in software security is memory safety. This article covers two questions: What is it? And why do we think it is worth investing in?

We'll start at Tectonics, a memory safety event we are sponsoring:

Tectonics is a one-day event around memory safety, happening in San Francisco on 2 November 2023, organised by the Internet Security Research Group's Prossimo. It aims to bring together "practitioners, technical leaders and policy-makers [...] moving beyond the basic issues of [the importance of memory safety] to focus on how we can get to a more memory safe future, faster."

Why is Tectonics relevant?

The event itself will not deal with the issue of what constitutes memory safety, but rather how we can achieve it structurally and practically, in as much existing and future software as possible. However, asking why Tectonics is relevant is asking why memory safety is relevant. And that does require an understanding of what it is.

"Memory safety is a property of some programming languages that prevents programmers from introducing certain types of bugs related to how memory is used." [1]

For most programmers, this is a given, but for the non-technical reader memory safety might feel like an enigma.

An example of memory unsafety

Let's look at an example [1,2] of a very common operation in a program. When a program tries to retrieve item 11 in a list of 10, two things can happen:

  1. In a memory-unsafe language where the programmer did not explicitly or correctly deal with this issue, this call will be executed to the best of the computer's ability; it might result in the return of a seemingly random piece of information, whatever the computer has stored in what would have been 'slot 11', had it existed. It might even return something that was never meant to be used in this instance (by this user, in this program, etc.), or at all. Hence the name 'memory unsafety'.

  2. In a memory-safe language, or a memory-unsafe language where the programmer did explicitly and correctly deal with this issue, this action will result in an error. After all, item 11 does not exist in the list, so the action is invalid and therefore not performed.

While option 2 seems obviously the safest solution, it is important to realise that the majority of systems programming is done in a memory-unsafe language, meaning it does allow for option 1 unless explicitly and correctly instructed otherwise.

The implications of memory unsafety

You might think: "This seems so minor, why should we care?" The problem is that oversights like in the example and similar common mistakes can result in unexpected crashes and vulnerabilities. In fact, together they cause an insane number of vulnerabilities: 50-70% of all software security bugs are caused by these memory-unsafe operations.

Number of memory-safety bugs " ~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues."

Let's say that again: the foundations of our operating systems and digital infrastructure are memory unsafe. Their safety relies entirely on people not making these types of mistakes.

With the existence of memory-safe languages like Rust, we now have the tools to change this.

Why do we sponsor Tectonics?

The Tectonics event has four funders, and we are one of them. The investments range from $5k to $30k. The yearly revenues of the other investing companies (that we know...) are $625M and $279B (yes, billion). And then there is Tweede golf, with a revenue of about $1.5M a year. It's an understatement to say we are a bit smaller than the other funders. (We tried to make a chart of these numbers, but they were, well, off-the-chart.)

So then why did we decide to fund this event? Why not leave it to the big players?

Funders of Tectonics It isn't so we can be the only green logo on the event page, we promise.

The answer is this: getting to a more memory-safe future, faster - is exactly what we have been working towards as well. Rust is our chosen vessel and digital infrastructure is ground zero.

We want to contribute to rebuilding critical components of the software that we as a society rely on. Our conviction is that - while defending against attacks is necessary - improving the inherent robustness of critical software is both essential and feasible. To quote a recent CISA report:

The software industry needs more secure products, not more security products. Software manufacturers should lead that transformation.

That resonates with what we have been saying on our website for years:

An ounce of prevention is worth a pound of cure - even more so in software.

We want to continue to work with partners who share this conviction, and Tectonics is the opportunity to jointly take steps forward.

State of the political arena

Having the tools to make our digital infrastructure memory safe is not enough. It will take time and effort from engineers, and thus money. It will require an incentive and ideally a global one.

The USA is at the forefront in this regard, with memory safety making it into US law in December 2022. The law is advisory rather than restrictive, but still an excellent first step in memory safety's "momentum from being viewed as an unrealistic endeavor to one that is being solved". [3]

Currently in the United States, efforts to make critical infrastructure memory safe are largely funded by the industry itself. For example, The Internet Security Research Group's Prossimo initiative is the original promoter of memory safety. They collect money from large industry stakeholders like Mozilla, Cisco and Google, to name just a few. Prossimo then invests these funds in memory-safe implementations of various parts of the internet. Examples of these projects include Rustls, the Linux kernel and sudo and su.

In Europe, the political arena is a bit more diverse. Internet security, and memory safety as a subset of that, are part of the discussion, though not yet part of any laws.

There is, however, at least one European country that is ahead of the game. The German government is investing community money in strengthening our digital infrastructure. They do this through the Sovereign Tech Fund, not because of any laws, but because the people behind the STF managed to impart the relevance of this cause to the authorities. And they listened. Examples of STF-funded memory safety projects include Pendulum, OpenMLS and Prossimo.

It is safe to say that these initiatives are giant leaps for our digital infrastructure; And at the same time, they are baby steps if you consider the gap between their scope (i.e. the work still to be done) and the current involvement of governments.

Full circle

And that brings us back to Tectonics. It is our hope that by facilitating the discussion, and by carrying it outside the office, to the policy-makers, the gap between industry and governments can eventually be bridged.

In the meantime, we hope to meet like-minded individuals (whether they are practitioners, technical leaders or policy-makers), as well as find sufficient funding, so that we can continue to work on strengthening critical infrastructure.

Sources

[1] https://www.memorysafety.org/docs/memory-safety/

[2] https://alexgaynor.net/2019/aug/12/introduction-to-memory-unsafety-for-vps-of-engineering/

[3] https://tectonics.memorysafety.org/

Erik
Co-owner & Director of Open Source
Hugo
Co-owner & Business director

Stay up-to-date

Stay up-to-date with our work and blog posts?

Related articles

Thanks to funding from NLNet and ISRG, the sudo-rs team was able to request an audit from Radically Open Security (ROS). In this post, we'll share the findings of the audit and our response to those findings.

At Tweede golf we are convinced that if software is written in Rust, it will be more robust (compared to legacy languages such as C, C++ or Java), and more efficient (compared to code written in PHP or Python and again, Java).

In order to get more robust software out there, we have to get Rust code running on computers of people who are not themselves Rust developers.

Recently, we gave a workshop for the folks at iHub about using Rust, specifically looking at integrating Rust with cryptography libraries written in C.