Add helper in libc. Tag categories as user space.

Having just hit submit... I wonder if we want to spend the available bit in EXTERR_CAT_SRC_MASK on in-tree vs out of tree or maybe just make pre-pending sys/ a legacy category source thing.

I think I want to refactor cat_to_filename() to take a buffer and to handle the selective prepending of sys/, perhaps bumping the uexterr_gettext ABI. It's fine for in-tree code, but definitely wrong for out of tree modules.

This addresses an issue I realized during Kirk's talk at BSDCan. In the existing model, it's quite hard to support third-party modules and even in-tree modules for downstreams would require reserving a portion of the identifier space. This approach adds cost to the EXTERROR_VERBOSE reporting path, but significantly decouples the kernel and libc. I'm not sure I'd want to go as far moving entirely to dynamic, but it's probably not a problem in practice.

Address feedback

Expand __uint64ptr_t to spares

The big thing that needs to be dealt with for this to make sense is to have a way to specify the filename that isn't a table embedded in libc. A first cut could be a special index that means no-file and perhaps using -1 as the line, but without that, we can't scale beyond files in the base system. (This also poses a problem for out of tree kernel modules.) We might also want macros like the kernel, but I'm less sure of that.

I ended up pulling the implementations out of the commit I merged because their dependencies (kernel option for sys/conf/files and cheri headers aren't available yet.)

In D33964#1328991, @markj wrote:

In D33964#1328982, @brooks wrote:

In D33964#1328968, @markj wrote:

An old diff. Is ptraddr_t the right type here?

If you used ptraddr_t you'd have to restore the compat32 support since it is in practice size_t. This seems like a good use of kvaddr_t.

kib already pointed out that kvaddr_t seems like the wrong type since the sysctl is exporting user addresses.

In D33964#1328982, @brooks wrote:

In D33964#1328968, @markj wrote:

An old diff. Is ptraddr_t the right type here?

If you used ptraddr_t you'd have to restore the compat32 support since it is in practice size_t. This seems like a good use of kvaddr_t.

In D33964#1328968, @markj wrote:

An old diff. Is ptraddr_t the right type here?

Move _data implementation to libkern/memcpy_data. Move cherification of memmove to D57965.

I'm going to further decompose this review to pull the cherification of memmove into it's own commit.

Clarify which pointers provenance is preserved

Simplify C implementation of mem{cpy,move}.

Use __nodiscard

Fix typo

Use __nodiscard

Fix headers. Mention that one past the end is permitted.

Created by accident. I blame the heat

fix typo

Be clear that sooptcopyoutptr is missing because it makes no sense

Fix some manpage nits

Doc fixes. Add copyinptr_nofault

Address feedback, switch references to memory_model.7

Move contents to a new memory_model.7

Rework intro text.

In D57661#1325572, @ziaee wrote:

Could we also put some sbom tags?

Use title case, rebase on D57820

Clarify alignment requirement somewhat

Fix more typos

Address feedback from @emaste

Link manpages to the description of pointer provenance in arch(7)

Document and link manpages to the description of pointer provenacne in arch(7)

Link manpages to the description of pointer provenacne in arch(7)

Link manpages to the description of pointer provenacne in arch(7)

Sorry about missing the label in i386.

For some reason this failed to auto close. I've manually linked rG2ee2ef607f60.

Discourage use of bcopy