Cheri is a proposal. If people were advocating "memory safe" languages ( I don't know what I should really call them) on Cheri, I'd have to think about it. All previous efforts in this direction have met with performance problems and unanticipated complexity though.
I'm not even against programming languages that limit end programmers - Go solved a serious problem for Google by removing a big source of errors.
My theory is that we do not do enough static program analysis and that there is a lot to be gained by making programming languages that are more amenable to static analysis and simpler to check
On Tue, Feb 27, 2024 at 2:06 PM Dave Banham <dbanham@blackberry.com> wrote:
What about the CHERI hardware solution that replaces pointers with capabilities?
Best Regards
Dave Banham
From: undefined-behavior-study-group <undefined-behavior-study-group-bounces+dbanham=blackberry.com@sei.cmu.edu> On Behalf Of Victor Yodaiken
Sent: Tuesday, February 27, 2024 2:39 PM
To: Robin Rowe <robin.rowe@heroicrobots.com>
Cc: sg14@lists.isocpp.org; undefined-behavior-study-group@sei.cmu.edu
Subject: Re: Memory Safety and Page Protected Memory
CAUTION - This email is from an external source. Please be cautious with links and attachments. (go/taginfo)
There is no such thing as a memory safe language on a current architecture computer. Some languages allow end programmers to do things that are not memory safe, and some languages require end-programmers to use language features that are implemented in some memory unsafe way.
On Tue, Feb 27, 2024 at 11:40 AM Robin Rowe <robin.rowe@heroicrobots.com> wrote:
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
BlackBerry UK Limited
Registered in England and Wales.
Registered No. 04022422, with registered office at
Ground Floor,
The Pearce Building,
West Street,
Maidenhead,
Berkshire,
SL6 1RL,
United Kingdom
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
CHERI is just "a proposal" ? I guess it's not yet in mass
production, but it's clearly been implemented in actual
hardware, as evidenced by open source projects having directly
benefited from usage of CHERI by having many bugs found and
fixed through its use.