5c3e4249 0mp July 19, 2022, 2:49 p.m.
MFC after:	1 week
cgit
ef2d0816 0mp July 19, 2022, 2:35 p.m.
MFC after:	2 weeks
cgit
cad64622 0mp July 19, 2022, 2:35 p.m.
MFC after:	2 weeks
cgit
e0bd2ab2 0mp July 19, 2022, 2:35 p.m.
MFC after:	2 weeks
cgit
b38e3722 0mp July 19, 2022, 2:35 p.m.
MFC after:	2 weeks
cgit
cd8401db emaste July 19, 2022, 2:28 p.m.
As in the past Dimitar Zhekov provided a copy of Terminus under a BSD
license for use by our console.

Sponsored by:	The FreeBSD Foundation
MFC after:	1 week
cgit
36f1526a andrew July 19, 2022, 9:57 a.m.
Add initial 16k page support on arm64. It is considered experimental,
with no guarantee of compatibility with a userspace or kernel modules
built with the current a 4k page size as code will likely try to pass
in a too small size when working with APIs that take a multiple of a
page, e.g. mmap.

As this is experimental, and because userspace and the kernel need to
have the PAGE_SIZE macro kept in sync there is no kernel option to
enable this. To test a new image should be built with the
PAGE_{SIZE,SHIFT,MASK} macros changed to the 16k versions.

There are currently known issues with loading modules from an old
loader as it can misalign them to load on a non-16k boundary.

Testing has shown good results in kernel workloads that allocate and
free large amounts of memory as only a quarter of the number of calls
into the VM subsystem are needed in the best case.

Reviewed by:	markj
Tested by:	gallatin
Sponsored by:	The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34793
cgit
54291f7d alc July 19, 2022, 3:35 a.m.
We don't need to hold the object lock while allocating swap space, so
don't.

Reviewed by:	dougm, kib, markj
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D35839
cgit
0361f165 kp July 19, 2022, 3:27 a.m.
This mutex is a significant point of contention in the ipsec code, and
can be relatively trivially replaced by a read-mostly lock.
It does require a separate lock for the replay protection, which we do
here by adding a separate mutex.

This improves throughput (without replay protection) by 10-15%.

MFC after:	3 weeks
Sponsored by:	Orange Business Services
Differential Revision:	https://reviews.freebsd.org/D35763
cgit
4eaaacc7 alc July 19, 2022, 3:23 a.m.
It is safe to test and clear the Invalidation Wait Descriptor
Complete flag before acquiring the DMAR lock in dmar_qi_task(),
rather than waiting until the lock is held.

Reviewed by:	kib
MFC after:	2 weeks
cgit
05350f09 cperciva July 19, 2022, 12:23 a.m.
On SMP systems, cpu_reset broadcasts a message telling the APs to stop
themselves, and then the BSP waits 1 second before actually resetting
itself; this behaviour dates back to 1998-05-17.

I assume that this delay was added in order to allow the APs to stop
themselves before the BSP resets; but we wait until the APs have all
acknowledged entering the "stopped" state, so it no longer seems to
serve any purpose.

Reviewed by:	jhb, kib
Sponsored by:	https://www.patreon.com/cperciva
Differential Revision:	https://reviews.freebsd.org/D35797
cgit
84ec7df0 cperciva July 19, 2022, 12:23 a.m.
Historic FreeBSD behaviour (dating back to 1994-04-02) when rebooting
is to print "Rebooting..." and then
	/* wait 1 sec for printf's to complete and be read */

Prior to April 1994, there was a 100 ms delay (added 1993-11-12).

Since (a) most users will already be aware that the system is rebooting
and do not need to take time to read an additional message to that
effect, and (b) most FreeBSD systems don't have anyone actively looking
at the console anyway, this delay no longer serves much purpose.

This commit adds a kern.reboot_wait_time sysctl which defaults to 0;
historic behaviour can be regained by setting it to 1.

Reviewed by:	imp
Relnotes:	FreeBSD now reboots faster; to restore the traditional
		wait after printing "Rebooting..." to the console, set
		kern.reboot_wait_time=1 (or more).
Sponsored by:	https://www.patreon.com/cperciva
Differential Revision:	https://reviews.freebsd.org/D35796
cgit
4e2121c1 allanjude July 18, 2022, 10:06 p.m.
These global objects are easy to validate, so provide the helper
functions to do so and include these commands in the allow lists.

Reviewed by:	markj
Sponsored by:	Juniper Networks, Inc.
Sponsored by:	Klara, Inc.
Differential Revision:	https://reviews.freebsd.org/D35372
cgit
287d467c allanjude July 18, 2022, 10:06 p.m.
Generally, access to the kernel debugger is considered to be unsafe from
a security perspective since it presents an unrestricted interface to
inspect or modify the system state, including sensitive data such as
signing keys.

However, having some access to debugger functionality on production
systems may be useful in determining the cause of a panic or hang.
Therefore, it is desirable to have an optional policy which allows
limited use of ddb(4) while disabling the functionality which could
reveal system secrets.

This loadable MAC module allows for the use of some ddb(4) commands
while preventing the execution of others. The commands have been broadly
grouped into three categories:
 - Those which are 'safe' and will not emit sensitive data (e.g. trace).
   Generally, these commands are deterministic and don't accept
   arguments.
 - Those which are definitively unsafe (e.g. examine <addr>, search
   <addr> <value>)
 - Commands which may be safe to execute depending on the arguments
   provided (e.g. show thread <addr>).

Safe commands have been flagged as such with the DB_CMD_MEMSAFE flag.

Commands requiring extra validation can provide a function to do so.
For example, 'show thread <addr>' can be used as long as addr can be
checked against the system's list of process structures.

The policy also prevents debugger backends other than ddb(4) from
executing, for example gdb(4).

Reviewed by:	markj, pauamma_gundo.com (manpages)
Sponsored by:	Juniper Networks, Inc.
Sponsored by:	Klara, Inc.
Differential Revision:	https://reviews.freebsd.org/D35371
cgit
2449b9e5 allanjude July 18, 2022, 10:06 p.m.
Add three simple hooks to the debugger allowing for a loaded MAC policy
to intervene if desired:
 1. Before invoking the kdb backend
 2. Before ddb command registration
 3. Before ddb command execution

We extend struct db_command with a private pointer and two flag bits
reserved for policy use.

Reviewed by:	markj
Sponsored by:	Juniper Networks, Inc.
Sponsored by:	Klara, Inc.
Differential Revision:	https://reviews.freebsd.org/D35370
cgit