David,

> This is a good idea, but might be impractical for production code.

Thank you. You are right if you are thinking it is impractical for
general use, but that's not what I intend to suggest.

With financial systems, it would be bad if a hacker finds a way to bring
the system down, to implement a DOS attack. It's much worse if a hacker
can use a buffer overrun to gain password access. It's the latter where
I want to have page protected memory, so even if the programmer makes a
pointer mistake somewhere else, it isn't possible to buffer overrun into
protected memory because it is isolated from all other memory.

A standard library function that returns page protected memory for
special uses buffers that deserve extra protection, that contain highly
sensitive information, such as passwords.

I'm thinking of legacy systems, too, that maybe nobody has the patience
to run an older codebase through a static analyzer, but would care
enough to harden the password checker, if all one needed to do was
replace malloc/calloc/new in one place with a call to memory_safe_alloc().

Thoughts?

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

On 2/27/2024 10:53 AM, David Svoboda wrote:
> Robin:
>
> This is a good idea, but might be impractical for production code. I
> believe that the Electric Fence dynamic analysis tool uses this
> approach...by wrapping guard pages around every memory chunk returned by
> malloc().
>
> https://elinux.org/Electric_Fence <https://elinux.org/Electric_Fence>
>
> I did use it a few times in the 90's to catch memory errors. Officially
> it incurred no time overhead, unofficially there was a decent amount of
> kernel overhead in managing the guard pages. I don't think this solution
> ever wound up in production code. Unless Kernel Electric Fence
> (https://docs.kernel.org/dev-tools/kfence.html#:~:text=Kernel%20Electric%2DFence%20(KFENCE)%20is%20a%20low%2Doverhead,has%20near%20zero%20performance%20overhead <https://docs.kernel.org/dev-tools/kfence.html#:~:text=Kernel%20Electric%2DFence%20(KFENCE)%20is%20a%20low%2Doverhead,has%20near%20zero%20performance%20overhead>) uses the same tech.
>
> --
>
> David Svoboda <svoboda_at_[hidden]>
>
> Software Security Engineer
>
> CERT Secure Coding Initiative
>
> (412) 596-0401
>
> *From: *undefined-behavior-study-group
> <undefined-behavior-study-group-bounces+svoboda=sei.cmu.edu_at_[hidden]>
> on behalf of Robin Rowe <robin.rowe_at_[hidden]>
> *Date: *Tuesday, February 27, 2024 at 12:40 PM
> *To: *undefined-behavior-study-group_at_[hidden]
> <undefined-behavior-study-group_at_[hidden]>, sg14_at_[hidden]
> <sg14_at_[hidden]>
> *Subject: *Memory Safety and Page Protected Memory
>
> https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/ <https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/>
>
> Memory safety concerns seem focused on the undefined behavior of
> pointers on buffer overruns and out-of-bounds memory accesses. However,
> not all memory is equally unsafe. Unintended access to memory that
> contains a password or an exec() command is much more valuable to
> hackers. Hacking of passwords is of particular concern for financial
> systems.
>
> C/C++ programs use stack, heap or static memory to hold data. Any of
> these can be overrun. I am experimenting with code to add a fourth
> category, page memory. That is, allocation creates a memory region that
> cannot be overrun into or out of because it is an isolated protected
> page in memory. The default behavior for an overrun is a segfault.
>
> Is this a good or bad idea? Been done before? Thoughts?
>
> Robin Rowe
> Beverly Hills, California
> *Chairman ISO WG21 SG14 C++ Banking and Financial Systems Subcommittee
>