Whilst the kernel can support any number of COMPAT_FOO, world can only
build a single libfoo. Upstream this isn't such an issue, since the only
option is lib32 anyway, but downstreams, such as CheriBSD, may wish to
support multiple at the same time. Thus, adjust the top-level Makefiles
to turn _LIBCOMPAT into a _LIBCOMPATS list that gets iterated over, and
adjust bsd.compat.mk to support this use-case.

For the normal NEED_COMPAT/WANT_COMPAT case, LIBCOMPATFOO remain set and
refer to the requested compat's, preserving the current interface. For
the top-level Makefiles those variables are no longer set (since there
is no longer "the" compat) and only the per-compat ones are available.

Reviewed by:	brooks, jhb, imp
Differential Revision:	https://reviews.freebsd.org/D40571

(cherry picked from commit 91d7edd)

Makefile.libcompat now supports building multiple sets of compat
libraries so this is no longer needed. It is, however, rather academic
for now given CHERI-MIPS was removed (the only CHERI architecture whose
base architecture has LIB32 support in FreeBSD), at least until upstream
gains LIB32 for arm64.aarch64.

get_arm64_tls pokes at the PCB for TPIDR_EL0 so needs the relevant
definitions. Currently we have a downstream diff to sys/systm.h that
pulls in machine/pcb.h, but that was only needed for CHERI-MIPS and so
should go away, which exposes this missing include.

Upstream doesn't pull it in here; this diff dates back to CHERI-MIPS,
which stored DDC in the PCB and thus __USER_CAP needed its definition.
However, neither Morello nor CHERI-RISC-V get it from the PCB and so do
not need this include (nor is it a generic thing that's needed), so we
should not have this as a downstream diff any more.

This fixes building lib32 libprocstat on amd64. Currently it dies
building zfs_defs.c, since it transitively includes machine/fpu.h via
sys/systm.h and, because it hackily defines _KERNEL, gets kernel
prototypes for things like fpu_save_area_free which reference struct
savefpu, but x86/fpu.h will give the i386 definition, which is a union
not a struct, giving a tag mismatch error. This issue once again
highlights how awful this approach is, and how fragile the whole thing
is when you start modifying system headers. We should probaby invest
efforts in fixing this mess upstream given the continued friction seen
around libprocstat/zfs downstream.

The situation for cleandir is a bit of a mess. The top-level build runs
cleandir normally and re-runs it per-libcompat under LIBCOMPATWMAKE.
This includes all programs, not just libraries, and so we end up in
nonsense situations. As a result, bsd.compat.mk is stubbed out for
cleandir, which in turn means it won't define libcompats, yet the top
level has defined _LIBCOMPATS, and so we end up trying to index it and
error out. Thus, skip this code in that instance, since cleandir isn't
referencing any of these targets. Note that, prior to multi-libcompat
support, we'd just reference the undefined libcompat and it would expand
to the empty string (which isn't an error in the contexts it was done,
other than the one removed in 86ddc08), but now we have to be more
careful.

This should all be reworked upstream so cleandir doesn't do stupid
things and these hacks can go (including reverting the .warn that
otherwise gets hit in bsd.compat.mk back to an .error).

Fixes:	cb783c2 ("Generalise libcompat to be a list rather than a single option")
Fixes:	#1729

Fixes:	c5c2d3d ("c18n: Insert trampolines for PLT function calls")

These add a bit to the build time, but we want to check that we're not
regressing the lib32 build as has happened in the past. We may wish to
flip the default in cheribuild (or remove the option entirely) at some
point in the future once we don't need to support versions where the
build is broken.

The local parts of rc already skip .sample files; we add .pkgsave to the
list, and add logic for base.

Thanks to @RhodiumToad for getting this started.

Differential Revision: https://reviews.freebsd.org/D27962
Reviewed by: imp
Pull Request: freebsd/freebsd-src#662

(cherry picked from commit 3693d91)

It was hard to tell what the if conditions were.

When the parent is GEN1, capdirty pages will also be GEN1, but now the
child will be GEN0 so there will be a mismatch leading to faulted capdirty
pages being revoked when revocation isn't in progress.  If no revocation
is triggered before the fault happens then vm_map.vm_cheri_revoke_test may
be NULL leading to a panic.

This is a potentially expensive check we we might not want to keep it
on by default even under invariants.

When called from exec_new_vmspace() to empty an unshared vmspace prior
to exec, the vm_map will be initialized with a zeroed enqueue and
dequeue epoch in the info page. When the process had previously revoked
and we failed to reset the state and zero the kernel's notion of the
epoch we ended up in an infinite loop were the kernel would see no work
to do (passed start epoch in the past) and thus would not update the
info page resulting in no progress being made.

One could alternatively reset the state in exec_new_vmspace(), but the
extra store seems harmless in the vm_map_free() case.

Verify that the empty vmspace is not revoking and has a zero epoch.

If the epoch is open then vm_cheri_revoke_test has been set and we need
to copy it was that we can test capabilities when we come back to finish
this epoch.

If the epoch is open we may be in the midst of a revocation and thus
rev_entry may be set in old_map.  In that case, set the corresponding
entry in new_map.

Add a somewhat unprincipled set of __has_feature(capabilities) checks to
allow cheri/revoke.h to be included unconditionally by libsysdecode's
implementation.

Support the flags arguments of cheri_revoke(2) and
cheri_revoke_get_shadow(2).  Use compressed names (sysdecode_cr*()) as
otherwise the formatting of the manpage is completely trashed (mandoc
uses too much space between columns).

Add two new modes to cheribsdtest_cheri_revoke_lib_run which start or
end a revocation of the entire array (rather than looping over it to
process a random number of times (average should be)).  Use this to open
an epoch prior to forking and close it in the child process.

It's plausible these could mean something else in the Arm architecture
outside of the Morello architecture fork, so we shouldn't go defining
(and using) them unless we know we're targeting Morello.

Because Morello awkwardly puts the encoding mode in SPSR rather than
CELR, we need to explicitly copy it over to the child's trapframe
otherwise we'll lose the state and end up back in A64. In practice, this
currently doesn't matter, since the success path doesn't have any
mode-dependent instructions and terminates in a ret, which will get the
right mode from c30, and the error path (which does have mode-dependent
instructions behind a direct branch to cerror) can never be reached in
the child, only the parent. However, this is still wrong, and will
matter in the Morello benchmark ABI, where fork will return with an
integer ret x30 and thus stay in A64.

Currently we just use "Child exited abnormally" for when the child
process doesn't exit cleanly, which is unhelpful when debugging, so
print the signal number instead if it was due to a signal.

Note that tests which deliberately provoke signals still exit cleanly,
since the child's test harness will catch the signal, save various parts
of the given siginfo_t and exit. This code is only for more catastrophic
situations (e.g. signal delivery itself is broken or the child received
a fatal signal before even setting up the handler).

This lets you easily run multiple cheribsdtest variants in sequence,
filtering out the verbose logging for each test, printing just the
summary lines at the end, as a useful tool for local testing. It is only
intended for humans and should not be extended for use in automated
environments; those should be using cheribuild or another similar tool
to do things properly.

This at last finishes the multi-year transition from libcheri to lib64c,
now that cheribuild should be able to handle both.

GitHub doesn't give a way to namespace these so they don't show up on
forks as far as I know, so we just have to delete the file for CheriBSD.

If we were in the process of revoking we need to NULL out map->rev_entry
so that vm_map_delete() is allowed to unlink the entry.  Also zero the
stats structure.

I'd put the call to vm_map_entry_end_revocation() at the end of the
initial store-side barrier so it somewhat worked, by accident, but was
missed more or less completely in the load-side case.

(cherry picked from commit f8cabe5)

MFC after:	1 week

(cherry picked from commit bfc4758)

Whilst /bin/echo on macOS and Linux implement -n, as do the builtin
echos in bash and zsh, the builtin echo in dash does not, causing the
first line of the output to be -n foo rather than just foo, and there to
be an extra newline in the output and thus blank line, both of which
result in "Symbol ... is not present in *.kld" warnings appearing in the
build output (once for -n foo and once for the empty string for each
module where EXPORT_SYMS is a list of symbols).

MFC after:	1 week

(cherry picked from commit d1e44bc)

We include paths.h in getlocalbase.c, which defines _PATH_LOCALBASE.
This will override a definition on the command line, meaning it is
impossible to override like how the manpage says you can, and it means
the code to provide a fallback default is dead as the macro is always
defined.

Instead, introduce a new LOCALBASE_PATH macro like LOCALBASE_CTL_LEN
that can be set on the command line and will default to the system's
existing _PATH_LOCALBASE to avoid duplicating the default here.

Reviewed by:	imp
Differential Revision:	https://reviews.freebsd.org/D40975

(cherry picked from commit 3a46fe2)

Fixes:	91d7edd ("Generalise libcompat to be a list rather than a single option")
(cherry picked from commit aa85676)

Under COMPAT_32BIT we are compiling 32-bit code and so __amd64__ is not
defined, __i386__ is, and we use the real i386 headers.

Reviewed by:	brooks, jhb, imp
Differential Revision:	https://reviews.freebsd.org/D40916

(cherry picked from commit 3d96c00)

Under COMPAT_32BIT we are compiling 32-bit code and so __LP64__ is not
defined, __ILP32__ is, and thus the check is completely redundant.

Reviewed by:	brooks, jhb, imp
Differential Revision:	https://reviews.freebsd.org/D40917

(cherry picked from commit c63c4e6)

Currently rtld_paths.h will #undef _PATH_ELF_HINTS in order to override
this to the right value if included afterwards, but the other way round
does not work as elf-hints.h tries to define an already-defined macro to
a potentially different value. Thus, guard the definition here so that
rtld_paths.h's definition continues to take precedence.

Note that, although all in-tree uses of _PATH_ELF_HINTS have included
rtld_paths.h already, pax-utils wants _PATH_ELF_HINTS from elf-hints.h
and so we cannot just drop the define. In-tree uses must just continue
to make sure that they include rtld_paths.h to get the right value for
libcompat builds as is already required.

Reviewed by:	kib, brooks, jhb, imp
Differential Revision:	https://reviews.freebsd.org/D40918

(cherry picked from commit be01082)

Reviewed by:	kib, brooks, jhb
Differential Revision:	https://reviews.freebsd.org/D40919

(cherry picked from commit 5181fe2)

This is just _PATH_RTLD by another name.

We no longer have COMPAT_32BIT hacks for libusb, instead supporting the
normal 32-bit ioctls for freebsd32 processes, so we can enable these for
the lib32 build.

Reviewed by:	emaste, brooks, jhb
Differential Revision:	https://reviews.freebsd.org/D40920

(cherry picked from commit 6adfb81)

Having the symbols exported by libc differ between i386 and amd64 lib32
is questionable. Since these files build just fine today, stop guarding
them with !defined(COMPAT_32BIT). Whether or not they work at run time
is a different matter, but an i386 jail would be similarly affected if
not, so that's not a problem with lib32.

Reviewed by:	kib, jhb, imp
Differential Revision:	https://reviews.freebsd.org/D40937

(cherry picked from commit 0fbb77c)

Currently none of the words in these require quoting, but a future
commit will add words that do, thus we should make sure to quote each
word so the shell doesn't mangle them before calling the sub-make.

(Note that :@var@expr@ is the bmake syntax for map, replacing each word
with expr's evaluation, with var containing the input word)

Reviewed by:	emaste, brooks, jhb
Differential Revision:	https://reviews.freebsd.org/D40921

(cherry picked from commit 537f945)

Currently the only way to detect for a libcompat build is to consult
whether COMPAT_32BIT is defined (or equivalent, for downstreams with
other libcompats or past releases with libsoft as COMPAT_SOFTFP). There
are two issues with this:

1. COMPAT_32BIT is a new naming scheme that doesn't match the libcompat
   name, which is unnecessary deviation.
2. When multiple libcompats exist, everywhere that needs to detect a
   libcompat must check each variable in turn, despite the fact that it
   normally just wants to know if this is a libcompat build and perhaps
   what ${LIBCOMPAT} and/or ${libcompat} are for it.

As a result, far too many places in the tree need to know about the set
of possible libcompats.

Instead, introduce two new CPP and sub-make variables, COMPAT_LIBCOMPAT
and COMPAT_libcompat, which give the values for ${LIBCOMPAT} and
${libcompat} respectively, so that uses can be made parameterised. For
when code really does need to know the specific libcompat, Makefiles can
perform a string comparison, but the C preprocessor cannot, so introduce
an additional CPP-only COMPAT_LIB${LIBCOMPAT} which is intended to
replace the inconsistently-named COMPAT_32BIT (which will be removed in
future). Uses of this new variable should still be kept to a minimum,
however, given the code duplication needed for new libcompats.

Reviewed by:	emaste, brooks, jhb
Differential Revision:	https://reviews.freebsd.org/D40922

(cherry picked from commit 8fad2cd)

See commit 8fad2cd ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.

Reviewed by:	brooks, jhb
Differential Revision:	https://reviews.freebsd.org/D40923

(cherry picked from commit 0ade2f8)

See commit 8fad2cd ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.

Reviewed by:	emaste, brooks, jhb
Differential Revision:	https://reviews.freebsd.org/D40924

(cherry picked from commit d3748fc)

…MPAT

We still have a tiny amount of libcompat-specific code in rtld_paths.h,
but it's been deduplicated as much as possible, and in future we may
wish to just push these variables down to the few consumers of them and
make them use the double-underscore variants with a libcompat argument
rather than give them names here.

See commit 8fad2cd ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.

Reviewed by:	kib, brooks, jhb
Differential Revision:	https://reviews.freebsd.org/D40925

(cherry picked from commit f940929)

See commit 8fad2cd ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.

Reviewed by:	emaste, imp, brooks, jhb
Differential Revision:	https://reviews.freebsd.org/D40926

(cherry picked from commit cb2f2fa)

See commit 8fad2cd ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.

Reviewed by:	imp, brooks, jhb
Differential Revision:	https://reviews.freebsd.org/D40927

(cherry picked from commit daf2519)

See commit 8fad2cd ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.

Reviewed by:	brooks, jhb
Differential Revision:	https://reviews.freebsd.org/D40929

(cherry picked from commit d7be70f)

The use isn't any more generic, just the variable itself, which will
allow COMPAT_32BIT to be removed. The fact we even have to check
COMPAT_LIBCOMPAT here in order to pass the right flags to CPP points at
our libcompat infrastructure not suitably modifying the CPP variable
(which we barely use for world; this and bsd.symver.mk are the two
uses, and the latter could benefit from the right flags too), but this
change doesn't attempt to fix that.

See commit 8fad2cd ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.

Reviewed by:	emaste, imp, brooks, jhb
Differential Revision:	https://reviews.freebsd.org/D40930

(cherry picked from commit 45be501)

In the process, delete a COMPAT_SOFTFP remnant that was missed in
previous sweeps.

See commit 8fad2cd ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.

Reviewed by:	emaste, brooks, jhb
Differential Revision:	https://reviews.freebsd.org/D40931

(cherry picked from commit 3864bd4)

Note that #if defined(...) rather than #ifdef is used here since this
list will be added to in future and this will minimise such diffs.

These defines come from bsd.compat.mk these days; no need to do it
manually here.

…MPAT

See commit 8fad2cd ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.

Reviewed by:	emaste, brooks, jhb
Differential Revision:	https://reviews.freebsd.org/D40932

(cherry picked from commit 1840dc0)

This will allow the latter to be removed, reducing the boilerplate
needed for a new libcompat.

Reviewed by:	kib, brooks, jhb
Differential Revision:	https://reviews.freebsd.org/D40933

(cherry picked from commit 1e635e8)

This will allow the latter to be removed, reducing the boilerplate
needed for a new libcompat.

Reviewed by:	kib, brooks, jhb
Differential Revision:	https://reviews.freebsd.org/D40934

(cherry picked from commit e17dd92)

These are no longer referenced, with the one user of each now using the
double-underscore version with "32" as an argument instead.

Reviewed by:	kib, brooks, jhb
Differential Revision:	https://reviews.freebsd.org/D40935

(cherry picked from commit 076a4dc)

When loading hybrid position-dependent binaries, we do not care about the
representability of the ELF sections. The reservation creation will skip the
representability alignment enforcement as well, so avoid complaining about
alignment when creating the imgact_capability.

We're only planning to merge load-side revocation to dev at this time so
put it at the top.

It's been required for all versions, not just purecap for quite some
time.

We recycled the LIBCHERI make variable long ago.

- Load a capability pointer from the stack for purecap.

- Store capability registers to the results structure.  Even though
  the current firmware only returns integer registers, storing the
  full capability is ok as the values will just be null-derived.
  However, this approach matches the current structure's layout and
  will work with any future firmware that may return capabilities.

Add a somewhat unprincipled set of __has_feature(capabilities) checks to
allow cheri/revoke.h to be included unconditionally by libsysdecode's
implementation.

Support the flags arguments of cheri_revoke(2) and
cheri_revoke_get_shadow(2).  Use compressed names (sysdecode_cr*()) as
otherwise the formatting of the manpage is completely trashed (mandoc
uses too much space between columns).

PR:		271063
Reported by:	[email protected]

Approved by: tcberner (mentor)
Differential Revision: https://reviews.freebsd.org/D39859

Add records about new ports committer (vvd).
Update Mentor and Mentee Information to follow step 5 of the Committers
Guide.

Other virtual interface drivers (e.g. if_gif, if_stf, if_ovpn) all start
with if_. The wireguard file is also named if_wg, but the module name
was 'wg'.

Fix this inconsistency.

Reported by:	Christian McDonald <[email protected]>
Reviewed by:	zlei, kevans
Sponsored by:	Rubicon Communications, LLC ("Netgate")
Differential Revision:	https://reviews.freebsd.org/D39853

Provide an additional line of output for the superblock giving the
computed size of the cylinder group (CGSIZE macro) along with the
details needed to calculate it.

MFC after:   1 week

…ock.

Check for an uninitialed (zero valued) fs_maxbsize and set it
to its minimum valid size (fs_bsize). Uninitialed fs_maxbsize
were left by older versions of makefs(8) and the superblock
integrity checks fail when they are found.

No legitimate superblocks should fail as a result of these changes.

MFC after:    1 week
Sponsored by: The FreeBSD Foundation

A check in the superblock validity code verifies that the computed
size of the filesystem cylinder groups (CGSIZE macro) does not
exceed the filesystem block size (fs_bsize).

A report was received that a filesystem had been flagged as failing
this check. We were unable to determine how the reported filesystem
could have been created. This commit adds a check at the end of the
newfs(8) command to verify that the the cylinder group size is valid.
If an oversize cylinder group is found newfs(8) prints a diagnostic
output and rebuilds the filesystem to make it compiliant.

MFC after:   1 week

MFC after:   1 week

I find it very annoying that there is no FreeBSD infrastructure to
determine failures across architectures other than to check in
changes and then have Jenkins find them.

Suggested by: Jessica Clarke
MFC after:    1 week