David,

> In one case, you have legacy code, perhaps without source, where you'd
> like to prevent out-of-bounds reads/writes to all chunks returned by
> malloc(). This is what ElectricFence does.

No, I'm not suggesting a general replacement for malloc().

> At the time, my need for dynamic analysis for memory safety became
> more satisfied with Valgrind, which provided the same safety
> features without using guard pages.

No, I'm not suggesting replacing valgrind.

> In the other, you'd like to protect specific chunks of memory, rather
> than all memory, by replacing malloc() with a (currently non-standard)
> memory_safe_alloc() function.

Yes, that is what I'm suggesting.

> My question to you is: wouldn't Valgrind (or a more modern
> analogue like UBSan) be sufficient to handle this use case?

No, it's not sufficient. I want extra protection for sensitive data. I
don't want to rely on faith that programmers have been careful or have
used valgrind and static code checkers.

> I know of no memory_safe_alloc() function...you would think it
> would have been provided by glibc() or some other platform-specific
> library.

Yes, that is the small hole I'm trying to fill.

Linux and Windows memory safe allocation APIs exist, but nothing
portable. It takes having an interest in how memory protection works in
operating systems to even be aware that page protection is a thing. That
there exists page protected memory, a fourth type of memory programmers
may allocate (besides stack, static and heap) is not taught in any
typcial computer science class.

It's important now because the DoD and other major sponsors of software
development are recommending to stop writing C/C++ code, or to rewrite
C/C++ legacy code, using instead languages that call themselves memory
safe, such as Rust. As often happens, C/C++ is more versatile than
detractors expect, and can be memory safe, at least to the extent of
protecting sensitive data.

I've never seen a memory safe C/C++ pointer in legacy code, nor used one
in the decades I've been programming in C/C++. I became interested in
memory safety when I chaired the Motion Picture Academy Rust committee.
Rust evangelists say we should all want memory safety. But, I didn't
love Rust enough to want to abandon C/C++. I got thinking, does it have
to be Rust? Does having memory safe pointers matter everywhere, or only
for sensitive data?

There's a performance cost allocating memory safe pointers that seems to
make them unsuitable for general use in C/C++, but programmers could
harden C/C++ code where it matters most with memory safe pointers. Much
easier than rewriting everything in Rust.

Robin Rowe
Beverly Hills, California
*Chairman ISO WG21 SG14 C++ Banking and Financial Systems Subcommittee

On 2/28/2024 11:39 PM, David Svoboda wrote:
> Robin:
>
> It sounds like you are suggesting a new use case:
>
> In one case, you have legacy code, perhaps without source, where you'd
> like to prevent out-of-bounds reads/writes to all chunks returned by
> malloc(). This is what ElectricFence does. While it was useful, I did
> not follow whatever became of ElectricFence, or its general technology.
> At the time, my need for dynamic analysis for memory safety became more
> satisfied with Valgrind, which provided the same safety features without
> using guard pages.
>
> In the other, you'd like to protect specific chunks of memory, rather
> than all memory, by replacing malloc() with a (currently non-standard)
> memory_safe_alloc() function. This may be easy enough to do on legacy
> source code. It's a fair enough idea, although I know of no
> memory_safe_alloc() function...you would think it would have been
> provided by glibc() or some other platform-specific library. My
> question to you is: wouldn't Valgrind (or a more modern analogue like
> UBSan) be sufficient to handle this use case?
>
> --
>
> David Svoboda <svoboda_at_[hidden]>
>
> Software Security Engineer
>
> CERT Secure Coding Initiative
>
> (412) 596-0401
>