We have some LOCORE exclusions elsewhere in arm64/include (and even sys/sys) that I think were intended to serve the same purpose, I wonder if those should be made consistent (__ASSEMBLER__ seems more accurate).

Mention what happens to the kernel when SSP is enabled
Enumerate the functions with bounds checking in a fancy table

Stop making stuff up

Document stack protections in security(7), xref from the build knobs

Ping

Address review feedback:

The beinstall specific bits LGTM

Add SPDX tags

Address review feedback

Do signal handling to avoid races, other small fixes (-w to manpage, drop in some assertionsabout fm_fd to make sure it's set / unset when we expect it to be)

Fix some nits
Switch to copound statements to avoid double evaluation

In D32306#1024959, @kib wrote:

So overall this stuff is in principle incompatible with the code like memcmp(*a++, *b++, XXX) ?

In D32308#1024838, @emaste wrote:

do we have user-facing documentation? maybe just expanding WITHOUT_SSP's description?

Amend WITH_SSP/WITHOUT_SSP descriptions with a note about FORTIFY_SOURCE

Ping

In D32307#1023676, @imp wrote:

I think a rebase is in order... this diff is picking up a lot of "noise" that have nothing to do with fortify....

defined(X) && X > 0 -> X

Just undefine gets unconditionally, note with a comment why

Looks sensible to me

Drop read() declaration avoidance; whatever was causing problems before, I
cannot reproduce it today.

• Remove include that was shadily added that doesn't seem to be needed now
• Don't break with __RENAME() use unless it's used

Thanks!

In D32306#833118, @imp wrote:

I think this is fine, modulo notes about its completeness, but I'm OK with that and it's not bad.

I'd add whu@ on these reviews as well, for hvsock in particular

Oh, return () style differs here

In D44200#1010523, @glebius wrote:

So, with D44307 in, you can add this:

static struct if_clone *
tuntap_cloner_from_flags(int tun_flags)
{
 
        for (u_int i = 0; i < NDRV; i++)
                if ((tun_flags & TUN_DRIVER_IDENT_MASK) ==
                    tuntap_drivers[i].ident_flags)
                        return (V_tuntap_driver_cloners[i]);
 
        return (NULL);
}

And then call

if_clone_destroyif(tuntap_cloner_from_flags(flags), ifp);

This of course won't cover the problematic traveling case. To cover that, you'd need to:

CURVNET_SET_QUIET(ifp->if_home_vnet);
cloner = tuntap_cloner_from_flags(flags)
CURVNET_RESTORE();
if_clone_destroyif(cloner, ifp);

Nice, thanks. I think at one point I thought I might have something else worth adding to struct tuntap_driver_cloner, but if it hasn't happened in the intervening 5 years then I think it's safe to say that it's not going to happen.