Looks good, thanks!

Thank you for the backport :) !

@markj could it be possible to backport this fix to the FreeBSD 13.1 while there is still time?
My FreeBSD 13.1 VM (virtualbox) freezes randomly during boot and this commit fixes it.

Comments from sjg

Thank you for your input, I believe we will think it over.

In D33926#776097, @sjg wrote:

In D33926#775928, @sebastien.bini_stormshield.eu wrote:

In D33926#775631, @sjg wrote:

Also I'm curious; if you are ok embedding trust anchors in the loader, what is the problem with embedding them in veriexec?

Legacy build system basically :s

It's much more convenient for us to separate the program compilation from its cryptographic configuration. This way the program can be compiled once and be used with various (trusted) CA stores.

When I originally designed the trust model for veriexec's signed manifest, I end up with embedded trust anchors because I could not come up with an alternative that could not be compromised. Of course as an embedded vendor, the set of trust anchors required is quite small and virtually static, so it is an easy choice.
What about a pre-loaded kernel module to hold your initial trust anchor(s)? need only be a sysctl ? not bullet proof, but a bit harder to spoof than kenv?

In D33926#775630, @sjg wrote:

Thanks for clarifying. The problem is; how does the kernel know/trust that the loader really verified anything ? rather than simply a loader.conf putting a hash into kenv?
It is one thing for the loader to verify the kernel before loading it (we also verify the kernel's rootfs) but the kernel cannot really verify the loader - or trust anything in kenv.

In D33926#775631, @sjg wrote:

Also I'm curious; if you are ok embedding trust anchors in the loader, what is the problem with embedding them in veriexec?

In D33926#773586, @sjg wrote:

The basic premise here is incorrect. There is a circular dependency.
veriexec cannot rely on O_VERIFY since veriexec is responsible for seeding mac_veriexec to enable O_VERIFY.
You would need to verify a detached signature of the archive - but then where do you get the trust anchors for that...

In D30464#686471, @imp wrote:

$1 is a local variable to vdot. Who could possibly change it?

$1 does not change :) But it represents a filename and it may not be resolved to the same inode when passed to _rc_verify and to dot :/ I know it's probably hard to exploit, but it remains a race condition nonetheless.

In D30464#686275, @sjg wrote:

vdot()
{
        if test -s $1 && _rc_verify $1 > /dev/null 2>&1; then
                . $1
        fi
}

Besides I believe there is race condition here. The file $1 can be tampered with after the call to _rc_verify and before the source call (.)

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 ;-)

AFAIK mac_veriexec does not block the opening of files with O_VERIFY if inactive. (i.e. the new sh verify option blocks nothing if mac_veriexec is inactive / not loaded).
Could you elaborate more on the portability issue?