Re: Explicit pointer provenance APIs for CHERI

Mark Millard <[email protected]> Wed, 24 Jun 2026 13:34:30 -0700
Newsgroups gmane.os.freebsd.architechture
Message-ID <[email protected]>
On 6/24/26 11:39, Tomoaki AOKI wrote:
> On Wed, 24 Jun 2026 16:34:17 +0000
> "Poul-Henning Kamp" <[email protected]> wrote:
> 
>> --------
>> Alexander Ziaee writes:
>>
>>> Can we massage it into memory(7)? I think that'd be the most obvious place.
>>> The draft is very focused on just memory statistics, but I think it wouldn't hurt
>>> it to tweak that a little bit.
>>>
>>> https://reviews.freebsd.org/D18768
>>
>> As long as there is a cheri(7) manualpage to get people started...
> 
> IIUC, CHERI can be implemented both as software (emulation?) and
> hardware, and this seemingly confusing things.

CHERI stands for: Capability Hardware Enhanced RISC Instructions

> 
> CHERI'fied CPUs could be one of the target archs for FreeBSD.

CheriBSD: a downstream variant of FreeBSD OS
(Note: used as a reference for testing CHERI hardware)

There is also a "CHERI-Enabled Linux 7.0".

> (Actually, ARM-derived for now, but more can inplement, theoretically.)

Also: CVA6-CHERI (RISC-V), not just Arm Morello.

> 
> Of course, implementations in hardware (processor) would be
> the best way. (In other words, "What hardware can do best
> should be done by hardware, not microcodes or upper layers."
> like basically taken in mainframes.) But still requires
> some porting efforts.
> 
> I could find a derived works forking from FreeBSD.
>   https://www.cheribsd.org/
> 
> 
>> -- 
>> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>> [email protected]         | TCP/IP since RFC 956
>> FreeBSD committer       | BSD since 4.3-tahoe    
>> Never attribute to malice what can adequately be explained by incompetence.
>>
>>
> 
> 


-- 
===
Mark Millard
marklmi at yahoo.com