Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

loader: install help files only once

Every file should be installed exactly once by `make installworld`.
This is especially important for pkgbase.

Loader help files were being installed by each loa

loader: install help files only once

Every file should be installed exactly once by `make installworld`.
This is especially important for pkgbase.

Loader help files were being installed by each loader variant (e.g.,
the simp, lua, and 4th EFI loaders). Add a (slightly hacky) mechanism
to skip installing help files for all but one variant.

PR: 271178
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40021

show more ...

loader: always install help files

Address two issues with current help file logic:

The existing condition prevents the common help file from being
installed when there are no additional help files

loader: always install help files

Address two issues with current help file logic:

The existing condition prevents the common help file from being
installed when there are no additional help files defined. This results
in no loader.help on EFI platforms, for example.

Second, due to the fact that we build and install multiple loader types,
each successive install will clobber the previous loader.help. The
result is that we could lose type-specific commands, or possibly list
them in loaders that do not have such commands.

Instead, give each loader type a uniquely named help file. The EFI
loader will look for /boot/loader.help.efi, userboot will look for
/boot/loader.help.userboot, etc. The interpreter variant has no effect
on which help file is loaded.

This leaves the old /boot/loader.help unused.

Some credit for the final approach goes to Mathieu <sigsys@gmail.com>
for their version of the fix in https://reviews.freebsd.org/D22951.

PR: 267134
Reported by: Daniel O'Connor <darius@dons.net.au>
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D28591

show more ...

stand: Move md_copymodules into modinfo.c and reduce copies

md_copymodules, bi_copymdoules, bi_copymodules32 (x2) and
bi_copymodules64 (x2) are all the same routine... Replace them all with
md_copym

stand: Move md_copymodules into modinfo.c and reduce copies

md_copymodules, bi_copymdoules, bi_copymodules32 (x2) and
bi_copymodules64 (x2) are all the same routine... Replace them all with
md_copymodules. This saves about 800 bytes on i386 BIOS loader, which is
a nice bonus.

Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D36572

show more ...

stand: Fix a common typo in source code comments

- s/independant/independent/

MFC after: 3 days

loader: narrow the scope of gfx frame buffer wrt tg supported kernels

Store whether or not we found a vbefb module (eg, a tg supported kernel)
in the preloaded_file structure. This automatically res

loader: narrow the scope of gfx frame buffer wrt tg supported kernels

Store whether or not we found a vbefb module (eg, a tg supported kernel)
in the preloaded_file structure. This automatically resets on reload and
eliminates load_elf knowing about any gfx_* interface. Restrict this to
i386, which is the only place it's used. Update libi386 to check in the
preloaded_file struct. Eliminate this from the teken_gfx
structure. Rewrite the parsing code to be more inline. Check this from
the same place we check for a relocatable amd64 kernel.

Sponsored by: Netflix
Reviewed by: manu, tsoome
Differential Revision: https://reviews.freebsd.org/D33427

show more ...

stand: remove mips support

As part of decommissioning mips support, remove the boot loader
support. Do this in advance of other boot loader work to limit the
amount of work that will be thrown away.

stand: remove mips support

As part of decommissioning mips support, remove the boot loader
support. Do this in advance of other boot loader work to limit the
amount of work that will be thrown away.

Sponsored by: Netflix
Reviewed by: jrtc27
Differential Revision: https://reviews.freebsd.org/D33377

show more ...

loader.mk: Simplify a little bit

The elf loader needs to know how to reach into the gfx_fb code, so
simplify how we include files to find that stuff.

Sponsored by: Netflix
Reviewed by: manu, tsoo

loader.mk: Simplify a little bit

The elf loader needs to know how to reach into the gfx_fb code, so
simplify how we include files to find that stuff.

Sponsored by: Netflix
Reviewed by: manu, tsoome
Differential Revision: https://reviews.freebsd.org/D33376

show more ...

stand/common: Add support for timestamp logging (tslog)

This adds tslog_init, which allocates a 2MB buffer for recording
timestamped events; and tslog_publish, which takes the buffer and
passes it t

stand/common: Add support for timestamp logging (tslog)

This adds tslog_init, which allocates a 2MB buffer for recording
timestamped events; and tslog_publish, which takes the buffer and
passes it to the kernel as a "preloaded module". These functions
will be used in a later commit.

Reviewed by: kevans

show more ...

EFI secure boot VECTX related changes

When VECTX is enabled as a kernel option and non-EFI loaders are
built, many reads will fail due to the mis-match of whether
LOADER_VERIEXEC_VECTX or not in rea

EFI secure boot VECTX related changes

When VECTX is enabled as a kernel option and non-EFI loaders are
built, many reads will fail due to the mis-match of whether
LOADER_VERIEXEC_VECTX or not in readin.h. Source that includes
bootstrap.h must ensure the kernel option agrees with the compile
time CFLAGS in the various make related files.

Submitted by: bret_ketchum@dell.com (original revision)
Reviewed by: sjg, bdrewery, dab, bret_ketchum@dell.com
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D29993

show more ...

loader: start kernel in text mode when there is no vbefb vt driver

If kernel is built without VT vbefb driver, make sure
we start kernel in text mode.

loader: fix build on non-x86 platforms

Need to build pnglite with all.

Reported by: Herbert J. Skuhra

loader: implement framebuffer console

Draw console on efi.
Add vbe framebuffer for BIOS loader (vbe off, vbe on, vbe list,
vbe set xxx).
autoload font (/boot/fonts) based on resolution and font size

loader: implement framebuffer console

Draw console on efi.
Add vbe framebuffer for BIOS loader (vbe off, vbe on, vbe list,
vbe set xxx).
autoload font (/boot/fonts) based on resolution and font size.
Add command loadfont (set font by file) and
variable screen.font (set font by size). Pass loaded font to kernel.

Export variables:
screen.height
screen.width
screen.depth

Add gfx primitives to draw the screen and put png image on the screen.
Rework menu draw to iterate list of consoles to enamble device specific
output.

Probably something else I forgot...

Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D27420

show more ...

loader: zfs should support bootonce an nextboot

bootonce feature is temporary, one time boot, activated by
"bectl activate -t BE", "bectl activate -T BE" will reset the bootonce flag.

By default, t

loader: zfs should support bootonce an nextboot

bootonce feature is temporary, one time boot, activated by
"bectl activate -t BE", "bectl activate -T BE" will reset the bootonce flag.

By default, the bootonce setting is reset on attempt to boot and the next
boot will use previously active BE.

By setting zfs_bootonce_activate="YES" in rc.conf, the bootonce BE will
be set permanently active.

bootonce dataset name is recorded in boot pool labels, bootenv area.

in case of nextboot, the nextboot_enable boolean variable is recorded in
freebsd:nvstore nvlist, also stored in boot pool label bootenv area.
On boot, the loader will process /boot/nextboot.conf if nextboot_enable
is "YES", and will set nextboot_enable to "NO", preventing /boot/nextboot.conf
processing on next boot.

bootonce and nextboot features are usable in both UEFI and BIOS boot.

To use bootonce/nextboot features, the boot loader needs to be updated on disk;
if loader.efi is stored on ESP, then ESP needs to be updated and
for BIOS boot, stage2 (zfsboot or gptzfsboot) needs to be updated
(gpart or other tools).

At this time, only lua loader is updated.

Sponsored by: Netflix, Klara Inc.
Differential Revision: https://reviews.freebsd.org/D25512

show more ...

RISC-V boot1.efi and loader.efi support

This implementation doesn't have any major deviations from the other EFI
ports. I've copied the boilerplate from arm and arm64.

I've tested this with the fol

RISC-V boot1.efi and loader.efi support

This implementation doesn't have any major deviations from the other EFI
ports. I've copied the boilerplate from arm and arm64.

I've tested this with the following boot flows:
OpenSBI (M-mode) -> u-boot (S-mode) -> loader.efi -> FreeBSD
OpenSBI (M-mode) -> u-boot (S-mode) -> boot1.efi -> loader.efi -> FreeBSD

Due to the way that u-boot handles secondary CPUs, OpenSBI >= v0.7 is required,
as the HSM extension is needed to bring them up explicitly. Because of this,
using BBL as the SBI implementation will not be possible. Additionally, there
are a few recent u-boot changes that are required as well, all of which will be
present in the upcoming v2020.07 release.

Looks good: emaste
Differential Revision: https://reviews.freebsd.org/D25135

show more ...

loader: create single zfs nextboot implementation

We should have nextboot feature implemented in libsa zfs code.
To get there, I have created zfs_nextboot() implementation based on
two sources, our

loader: create single zfs nextboot implementation

We should have nextboot feature implemented in libsa zfs code.
To get there, I have created zfs_nextboot() implementation based on
two sources, our current simple textual string based approach with added
structured boot label PAD structure from OpenZFS.

Secondly, all nvlist details are moved to separate source file and
restructured a bit. This is done to provide base support to add nvlist
add/update feature in followup updates.

And finally, the zfsboot/gptzfsboot disk access functions are swapped to use
libi386 and libsa.

Sponsored by: Netflix, Klara Inc.
Differential Revision: https://reviews.freebsd.org/D25324

show more ...

loader: remove libsa/crc32.c and use version from zlib

we have crc32(const void *, size_t) in libsa. Unfortunately zlib has
crc32(long, const unigned char *, unsigned) and we have conflict.

Since w

loader: remove libsa/crc32.c and use version from zlib

we have crc32(const void *, size_t) in libsa. Unfortunately zlib has
crc32(long, const unigned char *, unsigned) and we have conflict.

Since we do build libsa with zlib, we can use zlib version instead.

Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D24068

show more ...

veloader use vectx API for kernel and modules

The vectx API, computes the hash for verifying a file as it is read.
This avoids the overhead of reading files twice - once to verify, then
again to loa

veloader use vectx API for kernel and modules

The vectx API, computes the hash for verifying a file as it is read.
This avoids the overhead of reading files twice - once to verify, then
again to load.

For doing an install via loader, avoiding the need to rewind
large files is critical.

This API is only used for modules, kernel and mdimage as these are the
biggest files read by the loader.
The reduction in boot time depends on how expensive the I/O is
on any given platform. On a fast VM we see 6% improvement.

For install via loader the first file to be verified is likely to be the
kernel, so some of the prep work (finding manifest etc) done by
verify_file() needs to be factored so it can be reused for
vectx_open().

For missing or unrecognized fingerprint entries, we fail
in vectx_open() unless verifying is disabled.

Otherwise fingerprint check happens in vectx_close() and
since this API is only used for files which must be verified
(VE_MUST) we panic if we get an incorrect hash.

Reviewed by: imp,tsoome
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org//D23827

show more ...

Remove sparc64 support from the boot loader.

Remove all the sparc64 specific bits, both files and ifdefs.

Add flua to the base system, install to /usr/libexec

FreeBSDlua ("flua") is a FreeBSD-private lua, flavored with whatever
extensions we need for base system operations. We currently support a subset

Add flua to the base system, install to /usr/libexec

FreeBSDlua ("flua") is a FreeBSD-private lua, flavored with whatever
extensions we need for base system operations. We currently support a subset
of lfs and lposix that are used in the rewrite of makesyscall.sh into lua,
added in r354786.

flua is intentionally written such that one can install standard lua and
some set of lua modules from ports and achieve the same effect.

linit_flua is a copy of linit.c from contrib/lua with lfs and lposix added
in. This is similar to what we do in stand/. linit.c has been renamed to
make it clear that this has flua-specific bits.

luaconf has been slightly obfuscated to make extensions more difficult. Part
of the problem is that flua is already hard enough to use as a bootstrap
tool because it's not in PATH- attempting to do extension loading would
require a special bootstrap version of flua with paths changed to protect
the innocent.

src.lua.mk has been added to make it easy for in-tree stuff to find flua,
whether it's bootstrap-flua or relying on PATH frobbing by Makefile.inc1.

Reviewed by: brooks, emaste (both earlier version), imp
Differential Revision: https://reviews.freebsd.org/D21893

show more ...

stand: consolidate knowledge of lua path

Multiple places coordinate to 'know' where lua scripts are installed. Knock
this down to being formally defined (and overridable) in exactly one spot,
defs.m

stand: consolidate knowledge of lua path

Multiple places coordinate to 'know' where lua scripts are installed. Knock
this down to being formally defined (and overridable) in exactly one spot,
defs.mk, and spread the knowledge to loaders and liblua alike. A future
commit will expose this to lua as loader.lua_path, so it can build absolute
paths to lua scripts as needed.

MFC after: 1 week

show more ...

Remove NAND and NANDFS support

NANDFS has been broken for years. Remove it. The NAND drivers that
remain are for ancient parts that are no longer relevant. They are
polled, have terrible performance

Remove NAND and NANDFS support

NANDFS has been broken for years. Remove it. The NAND drivers that
remain are for ancient parts that are no longer relevant. They are
polled, have terrible performance and just for ancient arm
hardware. NAND parts have evolved significantly from this early work
and little to none of it would be relevant should someone need to
update to support raw nand. This code has been off by default for
years and has violated the vnode protocol leading to panics since it
was committed.

Numerous posts to arch@ and other locations have found no actual users
for this software.

Relnotes: Yes
No Objection From: arch@
Differential Revision: https://reviews.freebsd.org/D20745

show more ...

loader: implement map-vdisk and unmap-vdisk commands

illumos update: https://www.illumos.org/issues/10598

Add map-vdisk and unmap-vdisk commands to create virtual disk interface on top of file. Thi

loader: implement map-vdisk and unmap-vdisk commands

illumos update: https://www.illumos.org/issues/10598

Add map-vdisk and unmap-vdisk commands to create virtual disk interface on top of file. This will allow to use disk image from file system to load and start the kernel.

By mapping file, we create vdiskX device, the device will be listed by lsdev [-v] and can be accessed directly as ls vdisk0p1:/path or can be used as value for currdev variable.

vdisk strategy function does not use bcache as we have bcache used with backing file. vdisk can be unmapped when all consumers have closed the open files.

In first iteration we do not support the zfs images because zfs pools do keep the device open (there is no "zpool export" mechanism). Adding zfs support is relatively simple, we just need to run zfs disk probe after mapping is done.

Differential Revision: https://reviews.freebsd.org/D19733

show more ...

Create kernel module to parse Veriexec manifest based on envs

The current approach of injecting manifest into mac_veriexec is to
verify the integrity of it in userspace (veriexec (8)) and pass its
e

Create kernel module to parse Veriexec manifest based on envs

The current approach of injecting manifest into mac_veriexec is to
verify the integrity of it in userspace (veriexec (8)) and pass its
entries into kernel using a char device (/dev/veriexec).
This requires verifying root partition integrity in loader,
for example by using memory disk and checking its hash.
Otherwise if rootfs is compromised an attacker could inject their own data.

This patch introduces an option to parse manifest in kernel based on envs.
The loader sets manifest path and digest.
EVENTHANDLER is used to launch the module right after the rootfs is mounted.
It has to be done this way, since one might want to verify integrity of the init file.
This means that manifest is required to be present on the root partition.
Note that the envs have to be set right before boot to make sure that no one can spoof them.

Submitted by: Kornel Duleba <mindal@semihalf.com>
Reviewed by: sjg
Obtained from: Semihalf
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D19281

show more ...

Enable veriexec for loader

This relies on libbearssl and libsecureboot
to verify files read by loader in a maner equivalent
to how mac_veriexec

Note: disabled by default.
Use is initially expected

Enable veriexec for loader

This relies on libbearssl and libsecureboot
to verify files read by loader in a maner equivalent
to how mac_veriexec

Note: disabled by default.
Use is initially expected to be by embeded vendors

Reviewed by: emaste, imp
Sponsored by: Juniper Networks
Differential Revision: D16336

show more ...