Do you see such cases in the posted patch?

Overall I think this is a fine idea. I am curious about the manual fixups you applied (or put another way, how significant a subsequent clang-format would be). I tried running it again over rtld.c and see a bunch of things like

        for (ph = obj->phdr;
-           (const char *)ph < (const char *)obj->phdr + obj->phsize; ph++) {
+            (const char *)ph < (const char *)obj->phdr + obj->phsize; ph++) {

i.e., mine added an extra space to line up under the first char inside for's (). This feels like a clang-format bug to me.

This omits -N ${DESTDIR}${DISTBASE}/etc from the original commit. install does not validate the arguments passed to -o or -g (see PR283355) so there's no need to have the passwd db available.

Based on discussion in PR283340, do we need to have a separate option to specify whether we want uname/gname vs uid/gid in METALOG, or is it reasonable to use uname= if a name is specified and uid= if a uid is specified? I think this change is a valuable first step even if we want to add that later on.

It doesn't look like that would work -- we'd have to execute $BASEDIR/freebsd-version as USERLAND_VERSION is baked into the script. I'll take a look at that, but as a subsequent commit.

Uh, why do we need that wrapper instead of just calling memchr itself?

2004 has:

The munmap() function shall fail if:

If there are at least some other implementations in common use that don't support GNU-style my preference is for your change to go in.

This looks reasonable to me but could it be that whatever base64 exists on typical Linux distros allows "incorrect" argument order?

Turn reference into a link: rGdabee6fecc67

also remove generated files

This LGTM

Looks good with one nit noted

rebase

Please add a reference in mitigations.7

How should we keep track of the need for a proper kernel fix?

Eww, OK.

No objection here

Ah, nice.

We lose the tiny a == b optimization but I can't imagine that matters.

It seems reasonable to me to switch to (rather than add) the humanized form for -h which is what's already done for the files in the list. "xMB in y blocks" also gives me the impression that we're presenting two different quantities (e.g. that 1M could be in some arbitrary number of blocks) - it would probably make more sense to show it as "total %s (%lu blocks)" if keeping both.

I agree with @phk that this was probably an oversight. I'm not sure I'd include blocks under -h -- why not just total 268503 without -h and total 131M with -h?

Probably fine to go in