> As far as C++ standard is concerned, this proposal would only make
sense if you mean protect access to memory assigned within the same
application from another section that has gone rogue.

Yes.

> most operating systems already protect access to memory assigned to
other applications

Yes, page protected memory is implemented using that same mechanism, but
within the same application. Overrunning a page protected buffer will
segfault similarly to accessing memory in a different app.

> Let's say you designate a piece of memory intended to store
passwords. How would you prevent the application from accessing it when
in parts "when the access is illegitimate"

Like this...

void password_check()
{ char username[20];
 char password[20];
 char* page_protected_password = (char*) memory_safe_alloc(20);
 get_user(username);
 get_pass(password);
 do_something_stupid(username);
}

void do_something_stupid(char* username)
{ // not this obvious, but code in this function does:
 char* password = username+20;// uh, oh!
 ...
}

The page_protected_password is in its own bubble. A programmer can't
land in the page_protected_password buffer by overrunning some nearby
pointer like username. Nor can the programmer overrun the
page_protected_password buffer without a segfault or signal triggered.

You are right if thinking that get_pass(page_protected_password), or any
function passed that pointer, may do whatever it likes with
page_protected_password. Being memory safe gives protection from buffer
overruns, doesn't mean error-proof.

Thoughts?

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

On 2/27/2024 3:49 PM, Tiago Freire wrote:
> Protecting sensitive memory (such as it might contain passwords), it is definitely valuable, the problem however is the details.
> As far as I'm aware most operating systems already protect access to memory assigned to other applications, if it isn't than a fix should be done at the OS level.
> As far as C++ standard is concerned, this proposal would only make sense if you mean protect access to memory assigned within the same application from another section that has gone rogue.
>
> Let's say you designate a piece of memory intended to store passwords. How would you prevent the application from accessing it when in parts "when the access is illegitimate" while still allowing access "when the access is legitimate"? And how would you be able to tell between the two when the execution has been hijacked?
>
> There are ways to do hardening at the level of the operating system. But I'm not sure if there's anything that can be done at the application level, and to that extent, if there's anything that can be done at the C++ language level. I suspect that there might be things that you can do to make it harder, but not full proof.
> I would be curious to know if someone has an answer.
>
>