With CHERI (cheri-cpu.org) this causes a crash as pointers have hardware enforced bounds. This is pretty typical of the sort of long standing bug we're finding. I found a similar one in tcsh a few years ago where hitting <tab> on an empty command line read a byte before the beginning of a string.

I tracked this one back to https://github.com/csrg/original-bsd/commit/45cf24f20d90597daa44422eb7497313e70e244a#diff-29db5f32c6d874dca3dcac24c9c68955R565

One small typo, but otherwise looks good.

Some general comments in no particular order:

• pathseg strikes me as over engineering. While trivial to implement the value is always the same.
• I'm a bit skeptical of the overall interface in particular the cnt argument. It does match setutimes but that interface is odd (and there doesn't appear to be any in-tree consumer of the numtimes > 2).
• A manpage would be required for commit.
• Please either don't include generated files or update to a version of FreeBSD that adds @generated to them so they don't show up in the diff.

• Use "may" to indicate that transition to project member is at core's discretion.

One minor nit (but I'd suggest grepping for "* " to see if I missed any more).

FWIW, it already needs to be updated by hand in sys/conf/files.(amd64,i386).

This seems reasonable.

In D24949#549926, @rmacklem wrote:

Oops, forgot to "make sysent" before testing the last one.
Since the entry on compat/freebsd32/syscalls.master is NOSTD,
I needed to prepend "freebsd_" to the prototype name to
avoid a conflict.

The key things I watch for in syscalls.master changes look fine.

I've added documentation. While the backlist command does support the new flags I've not documented it because I'm not convinced it makes sense and unblacklist doesn't support them.

• certctl: handle METALOG like install(1) does
• Support NO_ROOT when calling certctl.

Given rS361149, I'll convert this review to one of the certctl changes and add docs.

Looks good at a glance. Adding a couple more potential reviewers.

There should likely be a corresponding change to the configure script upstream (probably duplicating the arm64 case).

sigh

Any reason not to land this?

Modulo accepting or rejecting @imp's suggestion this looks good.

Successful CI run https://cirrus-ci.com/task/4829231964225536

In D24407#537717, @pstef wrote:

How does this relate to D16111?