yosh
Re: the C++ committee voting down the adoption of a memory-safe subset.
IMO the choice was not between “memory-safe C++ subset” and “C++ profiles”. It was between “memory-safe C++ subset” and “C++ code must always be isolated in a sandbox” — AKA “C++ goes to jail now”.
yosh
“But Yosh, how would we sandbox C++ code at scale?”
While not a perfect solution — Firefox’s RLBox toolkit (https://rlbox.dev/) provides the template for that. It compiles a C program to Wasm, puts it inside a Wasm sandbox, and provides the same API on the outside of the sandbox.
Now if the sandboxes library exhibits UB, it can no longer be used to exploit the rest of the program. Here’s a full writeup of how this works:
https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/
yosh
Don’t just take my word for it; the Chromium project makes this pretty clear with their “rule of 2”. Pick no more than two of:
- code which processes untrustworthy inputs
- code written in an unsafe language
- code which runs with no sandbox
The inputs and outputs to programs are typically fixed to the domain and cannot be changed. Meaning: if C++ code cannot be replaced with a memory-safe language, and cannot be rewritten to be memory-safe, the only remaining option is to sandbox it.
yosh
The cool thing about this approach is that it can be designed and implemented without any input from the C++ committee.
The way to think about “memory-safe systems languages” is that they provide *static* memory safety, which provide optimal performance.
But if the language chooses not to statically mitigate defects, then yeah sure, as practitioners we can just choose to employ security measures to guard against them at runtime.
yosh
For people looking for more context on why C++ Profiles are not going to work, here is a good analysis:
https://www.circle-lang.org/draft-profiles.html#c-is-under-specified
C++ profiles, as designed, cannot achieve memory safety. The only way I see it “succeed” is if they try and move the goalposts by attempting to redefine the term “memory safety” to fit what they can deliver.
From my perspective that’s a dead-end. The only realistic mid/long-term solution is replacing C++. The only realistic short/mid-term solution is sandboxing C++.
Karl Auerbach
@yosh Way back in the 1970s we worked on machines with true hardware Capability architectures (not that weak thing with that name in Linux).
Those architectures let us get closer to the security rule of giving no module more authority than it needed to get its job done.
(I once got to help design an OS and then to design/build the capability based computer to run it. But it was classified so nobody ever heard about it.)
I wish we would revive the lost technology of capability hardware architectures.
Here's one such effort:
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.