cgit

Allocation or I/O failures in fsck_ffs(8) could cause segment
faults because of missing checks or not-yet-initialized data
structures. Correct these issues.

Reported by:  Peter Holm
Sponsored by: The FreeBSD Foundation

cgit

The commit message documented it as /etc/src.conf but the comment in the
source mentioned the non-existent /etc/loader.conf.

Fixes:	f8a199f28f9d ("stand: Raise limit to 550,000 bytes for loader")

cgit

into ffs_sbsearch() to allow use by other parts of the system.

Historically only fsck_ffs(8), the UFS filesystem checker, had code
to track down and use alternate UFS superblocks. Since fsdb(8) used
much of the fsck_ffs(8) implementation it had some ability to track
down alternate superblocks.

This change extracts the code to track down alternate superblocks
from fsck_ffs(8) and puts it into a new function ffs_sbsearch() in
sys/ufs/ffs/ffs_subr.c. Like ffs_sbget() and ffs_sbput() also found
in ffs_subr.c, these functions can be used directly by the kernel
subsystems. Additionally they are exported to the UFS library,
libufs(8) so that they can be used by user-level programs. The new
functions added to libufs(8) are sbfind(3) that is an alternative
to sbread(3) and sbsearch(3) that is an alternative to sbget(3).
See their manual pages for further details.

The utilities that have been changed to search for superblocks are
dumpfs(8), fsdb(8), ffsinfo(8), and fsck_ffs(8). Also, the prtblknos(8)
tool found in tools/diag/prtblknos searches for superblocks.

The UFS specific mount code uses the superblock search interface
when mounting the root filesystem and when the administrator doing
a mount(8) command specifies the force flag (-f). The standalone UFS
boot code (found in stand/libsa/ufs.c) uses the superblock search
code in the hope of being able to get the system up and running so
that fsck_ffs(8) can be used to get the filesystem cleaned up.

The following utilities have not been changed to search for
superblocks: clri(8), tunefs(8), snapinfo(8), fstyp(8), quot(8),
dump(8), fsirand(8), growfs(8), quotacheck(8), gjournal(8), and
glabel(8). When these utilities fail, they do report the cause of
the failure. The one exception is the tasting code used to try and
figure what a given disk contains. The tasting code will remain
silent so as not to put out a slew of messages as it trying to taste
every new mass storage device that shows up.

Reviewed by: kib
Reviewed by: Warner Losh
Tested by:   Peter Holm
Differential Revision: https://reviews.freebsd.org/D36053
Sponsored by: The FreeBSD Foundation

cgit

cgit

TARGET_ARCH is always wrong when not used at the toplevel Makefile*, or
in something that has to be included from there. Switch to using
MACHINE_ARCH exclusively here since there's no benefit from assigning
TARGET_ARCH the value of MACHINE_ARCH and then using TARGET_ARCH (and
make TARGET_ARCH=xxx won't work).

Sponsored by:		Netflix

cgit

cgit

We don't need the compress rotuines, nor zstd_opt.c. Remove them.
Expand the number of places we omit code for IN_LIBSA (which are FreeBSD
specific). Due to the agressive optimization, though, this doesn't
reduce the size of the loader. It does reduce the number of 'false
positives' for places to omit to reduce the size as well as reducing the
build time slightly.

Sponsored by:		Netflix
Reviewed by:		tsoome, delphij
Differential Revision:	https://reviews.freebsd.org/D36145

cgit

The BIOS loader operates in a very constrained environment. The messages
for the super block integrity tests take up about 12k of space. Compile
them out for the BIOS loader, while leaving it intact for all other
loaders that aren't space constrained. These aren't used in the 'super
tiny' *boot* programs, so no adjustment is needed there.

We reply on the fact that (a) i386 doesn't support 32-bit UEFI booting
and (b) LIBSA_CPUARCH is "i386" when building on both i386 and when
we're building the 32-bit libsa32 library.

This saves about 12k of space for this constrained envrionment and will
take a bit of the pressure off some machines where the loader has grown
too big for their BIOS (see comments in i386/loader/Makefile for
details).

Sponsored by:		Netflix
Reviewed by:		mckusick
Differential Revision:	https://reviews.freebsd.org/D36175

cgit

Raise the limit for /boot/loader to be 550k. The IBM PC imposes a limit
of 640k of RAM below 1MB, which is needed for real mode calls. BTX takes
40k of that. The BIOS takes some amount (25k seems a good "99% take less
than or equal to this" estimate for that, though some systems consume
more). Most typical setups need 25k of stack.  This leaves 550k for
code. We set the limit to 550,000 which gives about an extra 13,000
bytes of buffer for machines that whose setups use a little more stack
or whose BIOS reserves a bit more...

Add this derivation in the Makefile. Also recommend setting LOADERSIZE
lower in /etc/src.conf when the loader has to run on a system whose BIOS
takes up more space, or for a complex setup. Add a recipe for how to
find how much RAM your BIOS uses as well (thanks to jhb@ for the
trick). Network cards that boot via PXE and HBAs with their BIOS enabled
are known to be large consumers of lomem space.

Sponsored by:		Netflix
Reviewed by:		jhb
Differential Revision:	https://reviews.freebsd.org/D36152

cgit

The functions pbuf_init, kva_alloc, and keg_alloc_slab are significant
contributors to the kernel boot time when FreeBSD boots inside the
Firecracker VMM.  Instrument them so they show up on flamecharts.

cgit

This is supposed to fix syzcaller report.

Reported by:	syzbot+1e08b5f9f7f00383ddea@syzkaller.appspotmail.com
Fixes:		ea7be1293b48385f27b97c5f112e4cad93cbd33b

cgit

For some reason protosw.h is used during world complation and userland
is not aware of caddr_t, a relic from the first version of C.  Broken
buildworld is good reason to get rid of yet another caddr_t in kernel.

Fixes:	886fc1e80490fb03e72e306774766cbb2c733ac6

cgit

The validator always returned true due to an incorrect check.

Reviewed by:	mhorne, imp
Sponsored by:	DARPA
Differential Revision:	https://reviews.freebsd.org/D36125

cgit