On 2/27/24 23:44, Victor Yodaiken wrote:
> 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_at_[hidden]>
> 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_at_[hidden]>
> *On Behalf Of *Victor Yodaiken
> *Sent:* Tuesday, February 27, 2024 2:39 PM
> *To:* Robin Rowe <robin.rowe_at_[hidden]>
> *Cc:* sg14_at_[hidden];
> undefined-behavior-study-group_at_[hidden]
> *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_at_[hidden]> wrote:
>
> https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/
> <https://urldefense.com/v3/__https:/www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/__;!!JoeW-IhCUkS0Jg!cv7NkC31Nji2UY2Mpi04G_DJimr-X7NJRQNT5JNWgMkISUq8MH_WnNlNJX5uWHnUtMSCMCPcnetoxX0LvIl5RzUE36Ic$>
>
> 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.