Hi @Matthew.Nygard.Dodd_gmail.com and happy new year :)
I got some more data about the chip IDs:

I suggest to think about adding --libxo foo as an alias to -x oformat=foo to make things more inline with what is actually done for, e.g., netstat(1).

I submitted this patch via GitHub too: #674

I would like this code to be the basis to add support for NCT5585D but this chip is so weird, I'll have to rework things.

Increase verbosity to direct i/o code path (iores != 0)

Get back to using NCT_GPIO_CAPS.

Adjust/Add some man pages

In D32725#746813, @cem wrote:

Your benchmark platform was "a server with 2x24 core xenon gold cpus and 4x50G ixl(4) NICs," which definitely has other good entropy sources.

@jilles I took some time to think about fc -e (sorry for the lag). The only viable approach seems to just never enforce O_VERIFY with edited history entries. Not sure it's worth trying to ensure the shell is interactive. What do you think?

By the way, -i and -z are handled in a very similar fashion. There's probably some room for refactoring while at it.

In D30464#686275, @sjg wrote:

veriexec=/sbin/veriexec
if test -s $veriexec && $veriexec -i active > /dev/null 2>&1; then
_rc_verify() { $veriexec -x $1; }
else
_rc_verify() { : ; }
fi

In D30464#690655, @jilles wrote:

It is not documented, although example functions exist in /usr/src/bin/sh/funcs/. There is more information about this feature at https://www.in-ulm.de/~mascheck/various/ash/functionpathsearch.html .

@imp @jilles @sjg @mw Is there anything that still prevent this patch from landing?

In D30464#685956, @jilles wrote:

Looks reasonable, assuming veriexec itself is reasonable (in many cases, it seems to me that verifying the root filesystem would be a simpler and more reliable approach).

The verify option affects:

[…]

• function autoloading via a DIR%func entry in PATH

In D30464#687944, @sjg wrote:

BTW wrt creating test cases, assuming you have a system which is capable of enforcing veriexec and still operate, a package which contains a manifest with various failures is handy.
I have something like that for testing the verifying loader - it cannot be installed using my package system; since it would fail all the pre-install checks, so a manual install.sh
script is provided.

You can also do simple tests by just copying a verified file such. that it gets a new inode.
Eg /bin/sh may be verified and work just fine, cp /bin/sh /tmp; /tmp/sh - Authentication error same trick applies to any file.

In D30464#686275, @sjg wrote:

Neat, but not going to be portable.
FWIW I use veriexec -x some/file to test whether the file is verified.
Eg. we modify rc.subr to provide a couple of functions is_verified and vdot which does . only after verify file.
This allows shell scripts to be careful about what they consume, while still being portable (not that big. a deal really ;-)