Re: Explicit pointer provenance APIs for CHERI
Mark Millard <[email protected]> Wed, 24 Jun 2026 11:39:35 -0700
| Newsgroups | gmane.os.freebsd.architechture |
|---|---|
| Message-ID | <[email protected]> |
On 6/24/26 09:31, Alexander Ziaee wrote: > On 2026-06-24 10:37 -04:00 EDT, "Konstantin Belousov" <[email protected]> wrote: >> On Wed, Jun 24, 2026 at 10:54:51AM +0000, Poul-Henning Kamp wrote: >>> -------- >>> Brooks Davis writes: >>> >>>> On Mon, Jun 22, 2026 at 10:11:36AM -0700, Adrian Chadd wrote: >>> >>>>> Specifically, I'd like a manpage which defines something top level for these >>>>> terms and link to that manpage from manpages that talk about pointer >>>>> provenance and anything else that leads into CHERI related stuff. >>>> >>>> Lacking an obviously better place I've added a section to arch(7) and >>>> linked it from the various manpages. https://reviews.freebsd.org/D57812 >>> >>> Not bad, but I dont think there's any way around having a proper CHERI(7) >>> manual page too ? >>> >>> It doesn't have to be long, but it has to be there. >> >> The concept of the provenance is not specific to cheri, it is needed and >> used by the compilers on regular architectures. >> >> I think that instead of adding stuff to arch(7), we need a man page >> like memory_model(7). There is already some items that would be more >> natural in memory_model.7 than in atomic.9, for instance. Provenance >> is also the good subject for discussion there. > > Can we massage it into memory(7)? My guess is that the "for a non-developer audience" status for memory(7) may be a big distinction with the proposed memory_model(7), along with memory(7) being very FreeBSD OS specific. Memory model is common terminology in various language standards. Most of what I see in the memory(7) draft would not fit with such material as used in those standards. CHERI is not OS specific of itself: It is a hardware architecture extension. Linux and others have been integrating CHERI support as well, not just one variation on the FreeBSD OS. > 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 > > Best, > Alex > -- === Mark Millard marklmi at yahoo.com