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
Pull together the nearly identical copies of set_currdev in i386,
userboot and efi. Other boot loaders have variances that might be fine
to use the common routine, or not. Since they are harder to test for me,
and ofw and uboot do handle these setting differently, leave them be for
now.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D38005
Replace 4 identical copies of *_setcurrdev with gen_setcurrdev to avoid
having to create a 5th copy. uboot_setcurrdev is actually different and
needs to remain separate (even though it's quite similar).
Sponsored by: Netflix
Reviewed by: fuz@fuz.su, kevans
Differential Revision: https://reviews.freebsd.org/D38003
Pass in 'true' if you'd like to search this device's partitions or
'false' if you should just search the device. EFI and (in the future)
kboot have discrete partitions that aren't accessed via the full disk
device. Weird things happen if you try to search in these cases.
Sponsored by: Netflix
devinit() marches through all the devices, calling the inint routines if
any exist. Replace all the identical copies of this code.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D37349
Remove support for booting off of firewire, and for having dcons via
firewire in the loader. Kernel support for these things is unchanged.
Discussed on arch@ and the current state is not working (and the build
was wrong to boot).
Sponsored by: Netflix
Discussed: https://lists.freebsd.org/archives/freebsd-arch/2022-November/000267.html
Reviewed by: kevans, melifaro, emaste
Differential Revision: https://reviews.freebsd.org/D37334
The commit message documented it as /etc/src.conf but the comment in the
source mentioned the non-existent /etc/loader.conf.
Fixes: f8a199f28f ("stand: Raise limit to 550,000 bytes for loader")
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
Turns out there's two hidden a.out dependencies. pxeldr.S assumes it has
access to the a.out header from /boot/loader and cdboot.S assumes that
/boot/loader is also a.out and doesn't use boot2.
So, go back to making a.out files for these and adjust the size checks
to use ls, but we only need to check loader.bin. Trim the size we check
against by 2,000. The difference in size between loader and loader.bin
is about 3000 bytes, but clang15 produces binaries that are a smidge
bigger so we need to relax the check just a little and accept some
additional risk for the moment.
Add some comments to loader's Makefile about this.
Sponsored by: Netflix
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D36142
It's sometimes desirable to override the size limit: It's a soft limit
and there are times we exceed the limit by just a little bit and don't
want the build to fail (or we are hitting runtime failures below the
510,000 byte limit).
Sponsored by: Netflix
devformat produces the same output as i386_fmtdev, so just use it to
reduce on the dependencies.
Sponsored by: Netflix
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D35927
Rather than have the magic, hand-crafted fields that have to align with
fields in other structures at the end of i386_devdesc, make it into
anonymous union and adjust the code accordingly. This is safer and
similar to what CAM does.
Sponsored by: Netflix
Reviewed by: kevans, tsoome (prior version)
Differential Revision: https://reviews.freebsd.org/D35965
The BIOS method of booting imposes an absolute limit of 640k for the
size of the program being run due to btx. In practice, this means that
programs larger than about 500kiB will fail in odd ways as the stack /
heap will overflow.
Pick 510,000 as the cutoff line semi-arbitrarily. loader_lua is now
almost too big and we want to break the build when it crosses this
threshold. In my experience, below 500,000 always works, above 520,000
always seems to fail with things getting bad somewhere between 512,000
to 515,000. 510,000 is as close to the line as I think we can go, though
experience may dictate we need to lower this in the future.
This is at-best a stop-breakage until we have a better way to subset the
boot loader for BIOS booting to allow better, more fined-tuned
/boot/loaders for the many different environments they have to run
in. This likely means we'll have a graphical loader than understands a
few filesystmes for installation, and a non-graphical loader that
understands the most filesystems possible for everything else in the
future. Our build infrastructure needs some work before we can do that,
however.
At this late date, it likely isn't worth the efforts to move parts of
the loader into high memory. There's a number of assumptions about where
the stack is, where buffers reside, etc that are fulfilled when it lives
in the first 640k that would need bounce buffers and/or other counter
measures if we were to split it up. All BIOS calls are done in 16-bit
mode with SEG:OFF addresses, requiring them to be in the first 640k of
RAM. And nearly all machines in the last decade can boot with UEFI
(though there's some exceptions, so it isn't worth killing outright
yet).
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D36129
The first level boot blocks have understood how to load ELF code since
1999. Switch /boot/loader and /boot/pxeldr over to being ELF format so
that in-tree tools can examine them more closely. In addition, one
could, in theory, now have a 'lo-mem' and a 'hi-mem' segment (though a
lot of work would need to be done with bounce buffers, btx, code segment
marking, etc for an arrangement like that to work).
As far as I can tell, this is the last a.out binary in the tree. There
are several raw binaries left, but everything else is ELF.
Reviewed by: emaste, kevans
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D36130
We want to keep our root file system open to preserve bcache segment
between file accesses, thus reducing physical disk IO.
Reviewed by: imp, allanjude, kevans (previous version)
Differential Revision: https://reviews.freebsd.org/D30848
MFC after: 1 month
Because lld 13 and higher default to garbage collecting start/stop
symbols when using --gc-sections, the linker sets used in the i386 boot
loaders will disappear. This leads to the loaders not recognizing any
commands, and failure to boot.
Until we have a good set of linker scripts for the loaders, work around
it by disabling the start-stop-gc feature.
MFC after: 1 week
According to comments in the Makefile, to make pxeboot work we need to
have crt0.o first. This is needed because the simplified loader in
pxeboot assumes that the startup code is at offset 0 in this binary. In
normal booting, the start address can be obtained from headers of the
binary, but since pxeboot encodes this as a pure binary, it has no way
of knowing where that is and assumes 0. Added comments to that effect
in the Makefile.
We've done this by adding it to OBJS before all the other .o's are
added. However, there's a problem. This also adds it to the CLEANFILES
variable, which causes it to be removed from multiple places. The
dependencies may also cause it to be re-built at a time that's after
boot2 is built. This causes installs to fail because at install time
boot2 is considered to be out of date and the programs to rebuild it are
no longer in the path.
Cope with this problem by just adding it to LDFLAGS instead.
Glanced at by: kevans ("I thought that went in ages ago")
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D28876
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
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
The checkpoints are another way of keeping the state of ZFS.
During the rewind, the pool has to be exported.
This makes checkpoints unusable when using ZFS as root.
Add the option to rewind the ZFS checkpoint at the boot time.
If checkpoint exists, a new option for rewinding a checkpoint will appear in
the bootloader menu.
We fully support boot environments.
If the rewind option is selected, the boot loader will show a list of
boot environments that existed before the checkpoint.
Reviewed by: tsoome, allanjude, kevans (ok with high-level overview)
Differential Revision: https://reviews.freebsd.org/D24920
Since the make variable STRIP is already used for other purposes, this
uses STRIPBIN (which is also used for the same purpose by install(1).
This allows using LLVM objcopy to strip binaries instead of the in-tree
elftoolchain objcopy. We make use of this in CheriBSD since passing
binaries generated by our toolchain to elftoolchain strip sometimes results
in assertion failures.
This allows working around https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248516
by specifying STRIPBIN=/path/to/llvm-strip
Obtained from: CheriBSD
Reviewed By: emaste, brooks
Differential Revision: https://reviews.freebsd.org/D25988
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
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
LLD 10.0.0 changed the behavior of the -Ttext option, so that using
-Ttext=0x0 now causes linking of the loaders to fail with:
ld: error: output file too large: 18446744073707016908 bytes
I reported this in https://bugs.llvm.org/show_bug.cgi?id=44715, and
initially reverted the upstream change in r357259 to work around it.
However, after some discussion with Fangrui Song in the upstream ticket,
I think we can classify this as an unfortunate interaction between using
-Ttext=0 in combination with --no-rosegment. (We added the latter
in r332090, because btxld does not correctly handle input with more
than 2 PT_LOAD segments.)
Fangrui suggested to use a linker script instead, and Warner was already
attempting this in r305353, but had to revert it due to "crypto-using
boot problems" (not sure what those were :).
This review updates the stand/i386/boot.ldscript to handle more
sections, inserts some symbols like _edata and such that we use in
libsa, and also discards any .interp section.
It uses ORG which is defined on the linker command line using
--defsym ORG=value to set the start of all the sections.
Reviewed by: imp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D23952
smbios used to be an i386 only kinda weird quirk to the x86
architecture. But UEFI picked it up, dusted it off and now it's many
other locations. Make it base technology by moving it to libsa and
fixing up the compliation. The code has issues with unaligned access
still, but that will be addressed in a followup commit.
Differential Revision: https://reviews.freebsd.org/D23660
Create a ptov() function. It's basically the same as the btx PTOV
macro, but works everywhere. smbios needs this to translate addresses,
but the translation differs between BIOS booting and EFI booting. Make
it a function so one smbios.o can be used everywhere. Provide
definitions for it in the two loaders affected.
Differential Revision: https://reviews.freebsd.org/D23660
Add ficl words for isvirtualized
and move ficl inb and outb words to ficl/x86/sysdep.c
so can be shared by i386 and amd64
Reviewed by: imp bdrewery
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D22069
--gc-sections is not really useful unless we generate sections with
-ffunction-sections -fdata-sections
While there, i386/loader would win from --gc-sections too.
The chain command can be used to chain load another binary.
If veriexec is enabled we should verify it first.
Note that on EFI systems the verification was already done
through firmware, assuming that Secure Boot was enabled there.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Reviewed by: sjg
MFC after: 1 week
Obtained from: Semihalf
Differential Revision: https://reviews.freebsd.org/D20952
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
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
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
