To fit within in the same space, drop the newline before the PXE
prompt to make room for the additional space character.
PR: 281494
(cherry picked from commit 4fa4693dcdd8176f1d12cce5f026eb2052036dfc)
These were reported by `mandoc -T lint ...` as errors.
Signed-off-by: Graham Percival <gperciva@tarsnap.com>
Reviewed by: mhorne, Alexander Ziaee <concussious.bugzilla@runbox.com>
Sponsored by: Tarsnap Backup Inc.
Pull Request: https://github.com/freebsd/freebsd-src/pull/1472
(cherry picked from commit 759ddb4d246f5db5963369a82f1ab165d0dfccce)
These were reported by `mandoc -T lint ...` as errors.
The rendered output (in ascii and html) is not affected by this commit.
Signed-off-by: Graham Percival <gperciva@tarsnap.com>
Reviewed by: mhorne
MFC after: 3 days
Sponsored by: Tarsnap Backup Inc.
Pull Request: https://github.com/freebsd/freebsd-src/pull/1459
(cherry picked from commit 229381deb270e8e240d20b572c63234a61cbd977)
These were reported by `mandoc -T lint ...` as errors.
The rendered output (in ascii and html) is not affected by this commit.
Signed-off-by: Graham Percival <gperciva@tarsnap.com>
Reviewed by: mhorne, Alexander Ziaee <concussious.bugzilla@runbox.com>
MFC after: 3 days
Sponsored by: Tarsnap Backup Inc.
Pull Request: https://github.com/freebsd/freebsd-src/pull/1454
(cherry picked from commit 643fc698203b9b0ed386b0583c2200c428135c9d)
We include too many references to networking things in the
non-networking build for loader.efi. Ifdef out netserver command when we
are disabling network support to resolve.
PR: 277528
MFC After: 2 days
Reviewed by: imp
(cherry picked from commit 47ef2a131091508e049ab10cad7f91a3c1342cd9)
Only the gfx-enabled boot loader supports unicode. Otherwise, we have to
use the old cons25 / ibmpc upper code page drawing characters. Check to
see if we have the gfx.term_drawbox function. If we do, we support the
unicode drawing characters. If we don't, then we have an older loader
that doesn't support it *OR* we have the reduced function, text-only
boot loader. In either of those cases, we need to use the old graphics
characters. Abstract all those details into core.hasUnicode function.
PR: 282465
MFC After: 2 day
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D47403
(cherry picked from commit c2ba66d4d01f23303352bfe3cbd50ff5d9a05947)
So this is a gross hack to fix the 'noclean' build since we changed to
text-only loader. We have to fix it in a better way, but for the moment,
this will fix non-meta no-clean builds. A better hack is to fix this so
we build either vidconsole.c or textvidc.c, but some minor refactoring
and variable renaming is needed.
Fixes: 23dee252daf2
Sponsored by: Netflix
(cherry picked from commit 10c429016a3c5adf2e04cfd1ac97eb24c0e7074c)
After talking with a number of people about the removal of some things
to make the loader fit, readjust things a little.
Add back GZIP and BZIP2 compression support. Many of the downstream MFC
packaging systems depend on this. This adds back 20k to the size of the
loader.
Make the boot loader text-only by default. This saves 40k in size. Net,
we're 20k smaller. The graphics loader for BIOS is less useful than the
zip functionality: You can still boot w/a text only one it and you can
build a custom one if you really want it. It's also the default we use
for dual console.
This should be merged back into stable/14 and stable/13 so it's in the
next release for each of these. That way we have only one release (13.4)
with the other defaults.
MFC After: 3 days
Sponsored by: Netflix
Reviewed by: olce, rgrimes, emaste
Differential Revision: https://reviews.freebsd.org/D47203
(cherry picked from commit 23dee252daf2ff60e521c9c019e64134b63ce90f)
* Add PVR bits for POWER10 and POWER11
* Initialize the `err` outvar, in case it's not touched on success by
the hypervisor, to prevent spurious errors.
(cherry picked from commit f2e62e601304cea927bbeea70c484030b8e9fe45)
fsize is using 2 bytes for cluster number, but with fat32 we
actually do have 4 bytes and with large disks the high bytes will be in use.
illumos issue: https://www.illumos.org/issues/16821
Sponsored by: MNX Cloud, Inc.
(cherry-picked from commit 79a0d14fa05c75038caa52099289effb85732f88)
The upstream fix to make lld output for our EFI loaders reproducible
again was committed in 54521a2ff93a. Bump lld's LINKER_FREEBSD_VERSION
to be able to check this in the EFI loader Makefile.
MFC after: 3 days
(cherry picked from commit f97c7fdc59d252cc8611968ffac541d4b8342b8b)
In 5c73b3e0a3 calls to core.loadEntropy were added to core.boot
and core.autoboot; but neither of those is invoked if we disable
the "beastie" menu. Add a core.loadEntropy call to the no-menu
path.
Reviewed by: imp
MFC after: 1 week
Sponsored by: Amazon
Fixes: 5c73b3e0a3 ("Add support for getting early entropy from UEFI")
Differential Revision: https://reviews.freebsd.org/D46637
(cherry picked from commit 74a28cf6e7f66c7c12fd25ee8231eeedf756bf08)
The EFI RNG on some platforms takes a long time if we request 2048
bytes of entropy, so we would like to request less; but our kernel
Fortuna RNG needs to be fed 2048 bytes in order to consider itself
"fully seeded". If we have between 64 bytes (the size of a single
Fortuna pool and enough to guarantee cryptographic security) and
2048 bytes (what Fortuna wants) then the boot process will hang
waiting for more entropy despite in fact having enough to operate
securely.
Since 64 bytes of entropy is plenty to be cryptographically secure
(an attack of cost ~ 2^128 is infeasible, which implies a mere 16
bytes of entropy), use PBKDF2 (aka pkcs5v2_genkey_raw) to spread
the entropy across 2048 bytes. This is secure since PBKDF2 has
the property that every subset of output bytes has within O(1) of
the maximum possible amount of entropy.
Reviewed by: pjd
MFC after: 1 week
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D46635
(cherry picked from commit c8ebbd28aa91705aea3a67b06018ea6aef5aa6e4)
This was previously only available if GELI support was included, but I
want to use it for processing entropy from EFI
Reviewed by: imp
MFC after: 1 week
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D46634
(cherry picked from commit 925f15731e3480fe80f580a2f7463cb5210a95c8)
Add a new loader variable entropy_efi_seed_size which defaults to 2048;
if not defined (e.g. if the /boot/lua/ is updated but /boot/defaults/
isn't) the same 2048 default will be used.
Reviewed by: Val Packett
MFC after: 1 week
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D46632
(cherry picked from commit f4a69a933cd645e384b337db5ef2ccf41a1ddd5b)
On some systems, the EFI GetRNG is slow. Make it show up in flamecharts.
MFC after: 1 week
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D46631
(cherry picked from commit b58fe4eb29fbd3236df0f7fdfad4393d2536dbb5)
Wrap each call to a built-in command with TSENTER/TSEXIT to make
it easier to see where time is going in the loader.
MFC after: 1 week
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D46630
(cherry picked from commit 58ec2d0d4a3c3bcf741d9694dc7696c7b4e753b9)
For build reproducibility we set PE headers to an arbitrary timestamp.
Nothing in FreeBSD uses this timestamp, but bump it from 2016 to 2024 so
that the timestamp does not seem "too old" in case some third party tool
is used to inspect EFI boot components.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D46527
(cherry picked from commit 1b9cfd6a625dc82611846cb9a53c1886f7af3758)
Fixes: 871911a4ab73 ("loader.efi(8): beef up the updating the ESP")
MFC after: 1 week
(cherry picked from commit 18f7683e0d6ee6858865d8b0c2d7e2c14abf0bc4)
There's a huge variety of situations when booting with UEFI. Document
more of them, hopefully better.
Feedback from: jrtc27
MFC After: 3 days
Sponsored by: Netflix
(cherry picked from commit 871911a4ab738a54a88f3533f553f5eb68c28012)
When the various loaders under stand/efi are built, the resulting
binaries differ over multiple runs, even if WITH_REPRODUCIBLE_BUILD is
used. This is caused by lld multithreading and the custom linker scripts
for the loaders, and affects the following binaries:
* loader_4th.efi
* loader_4th.sym
* loader_4th.sym.full
* loader_lua.efi
* loader_lua.sym
* loader_lua.sym.full
* loader_simp.efi
* loader_simp.sym
* loader_simp.sym.full
Work around this by disabling lld threading for these binaries.
Reviewed by: emaste
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D46271
(cherry picked from commit f5ce3f4ef562ea9fc4d8f9c13c268f48a5bacba7)
Make it possible to disable pxeboot. This loader will fail to build when
it's too large. When /boot/loader needs to be larger like that, this
options will disable a component whose build will fail. It is an explicit
option rather than implicit when things are too large to force the user to
make the explicit tradeoffs rather than wonder why they have a stale pxeboot
or other odd failure mode.
MFC After: 3 days
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D46212
(cherry picked from commit 20d35d5817851df3a6d20e75df2e14a192b94940)
Have a separate PXEBOOTSIZE variable that acts much like LOADERSIZE
variable to limit the size of the loader used for pxeldr. This allows
people to override it independently of LOADERSIZE, which they may need
to set larger for other reasons. Combined with PXEBOOT_DEFAULT_INTERP,
you can build a larger lua loader, while still being able to build pxeldr
with the 4th one, for example.
MFC After: 3 days
Sponsored by: Netflix
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D46214
(cherry picked from commit e1a6d93155cea7fbb038dee671ecf005c4846fd3)
Sometimes you need / want a different boot loader than loader_lua for
pkeldr. Provide an option to get either the 4th one or the simp one.
MFC After: 3 days
Sponsored by: Netflix
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D46213
(cherry picked from commit f4762e9135d181f5d4f2a9d688ff803ee53ad808)
When the boot loader version is too old, add a warning to the boot menu
to maybe catch people's attention.
Use the correct loader code that adds an inactive highlighted menu item
indicating that an update is needed.
Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D45890
(cherry picked from commit 0eac99f76ec31270f902cc2a0ff5ae4b5b606a65)
(cherry picked from commit 7cb65be96d47cbe0b740266bc633d272fc4c5e6b)
If the loader is < 3.0, print a warning that it's too old and needs to
be upgraded.
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D45889
(cherry picked from commit a2fd7ae87991044ca283974ced8f6ed635d1cb0c)
Each incompatible change we make, we bump the major version. We've not
done the bump in a while, so sync everybody to 3.0. Anything older than
3.0 will be given a warning that their boot loader is too old. We check
only the major version, though, so minor versions can still be bumped
for individual loaders (though I honestly doubt we'll ever need to do
that again).
Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D45888
(cherry picked from commit 9f7f90507528aaa9a2f54575c1d4f4010d01c2e5)
This reverts commit 552f3072af54820cf1805f712e2567bc1b7f046d.
loader.command_error was added just after 11.2, but appears to not have
been back ported to 11.x. 11.0 was the first lua loader release, so keep
this compat shim until we sort out what to do.
MFC After: 3 days
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D45883
(cherry picked from commit 809edb3636a5494ad7d3dfff910e0aab89d83442)
This reverts commit ab97d42addae97a389c6f22d6bba62ed954bb8e7.
There's too many people in the field with FreeBSD 12.0 loader.efi that
stubbed their toe on upgrading to 14.1 since they'd not updated
loader.efi. While we sort out that mess, add back this workaround. Can
revisit after 14.2 maybe.
MFC After: 3 days
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D45882
(cherry picked from commit 522a65a8d97a0d6b634266f1b4a89aa8f374279c)
This reverts commit 8b9178cd0d35ff2beafebdd51c8c44ba2b5aeb0f.
Really old loader.efi files persist in the field. Revert this to support
it. We need to support this through at least 14.2 now, alas.
MFC After: 3 days
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D45881
(cherry picked from commit b38a82c77ab90eace53c56151b191efd1f4a8439)
This line is no longer needed as fallback, and should have been deleted
in 7870a52598 instead of commented out, but 26 years later, I have a
high degree of confidence that old change was right and we won't need
this line as a fallback.
Sponsored by: Netflix
Reviewed by: kevans, jhb
Differential Revision: https://reviews.freebsd.org/D45880
(cherry picked from commit 65300ca729452f62c201baedcbb4a67f2afc5ed5)
We long ago changed newvers.sh to make these comments bogus. Remove
them since every single one of them is broken after the $FreeBSD$
removal.
Sponsored by: Netflix
Reviewed by: kevans, jhb
Differential Revision: https://reviews.freebsd.org/D45879
(cherry picked from commit 8165650389ba2d0a68cea6902ac3750055cad9da)
This saves space to allow pxeboot to work again. Users desiring these
features can turn them on for their custom build. While these are useful
for some specialized applications, they aren't needed to boot the
typical system, and we're low on space.
text data bss dec hex filename
Before: 465866 20740 31612 518218 0x7e84a loader_lua.bin
After: 441535 17484 31092 490111 0x77a7f loader_lua.bin
Savings: 28,107 bytes
Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D42416
(cherry picked from commit 195a96f0b303345818e09ad1d79dc80122804de8)
Load a splash screen that vt(4) can use if the "splash" env variable is defined.
For now only png is supported and decoding is done in loader and not in kernel
compared to splash screen support in sc(4).
For using this add:
boot_mute="YES"
splash="/boot/images/freebsd-logo-rev.png"
in loader.conf
Differential Revision: https://reviews.freebsd.org/D45932
Reviewed by: imp, tsoome
Sponsored by: Beckhoff Automation GmbH & Co. KG
(cherry picked from commit 00460cc8c5ad02b628e81eec9e493a1df8393d36)
The alpha wasn't done properly and some white stripes could be seen.
Differential Revision: https://reviews.freebsd.org/D45933
Reviewed by: imp. tsoome
Sponsored by: Beckhoff Automation GmbH & Co. KG
(cherry picked from commit 887062c1da4a4c04a2b3987ec9a4e2a5902122d5)
Assume you have loader configured to load linux64, which has a
dependency on both linux_common and mqueuefs but neither the kernel
nor kernel config in question have the mqueuefs module included.
When the load command for linux64 fails to find mqueuefs, it will
free both linux64 and linux_common as they were loaded first, but only
linux64 gets removed from the module list. As a result, future
traversals hit an easy use-after-free with linux_common.
Fix it so that we unlink the entire tail of the list. Anything after
the initially loaded module is, by definition, a dependency on the
loaded module while we're still in the load command, so we can just
discard the entire tail. If linux_common were loaded before linux64, it
should not move to a position during this load where it would suddenly
be missing from the view presented to the kernel.
Reported by: philip
Reviewed by: imp, philip, tsoome
(cherry picked from commit 3da568710fde08251996c117b87bedb326dedb57)
ld.bfd doesn't understand elf64-aarch64 but does have
elf64-littleaarch64. Switch to this so we can link kboot with it.
While here switch to the single format version. We are unlikely to
support booting from a big-endian Linux.
Reviewed by: imp, emaste
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D45258
(cherry picked from commit 8e82c5e28db6fb19f75d10fd2e7c3db784723f1f)
When linking with ld.bfd it complain with the following:
/usr/local/bin/aarch64-unknown-freebsd14.0-ld: start.o: relocation
R_AARCH64_ABS32 against `__data_size' can not be used when making a
shared object
Fix this by marking the __data_size with ABSOLUTE. This returns a
non-relocatable value which appears to be the same behaviour of lld.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D45257
(cherry picked from commit 9f44638ef2c46861565b89bb01bbeeab17755649)
We need to include bsd.init.mk first when we have man pages in the boot
loader.
Sponsored by: Netflix
(cherry picked from commit cfcf475a669738382ac75ea50eb03a20280f7662)
The dictthreshold in stand/forth/loader.4th is too small
resulting in full dictionary.
Reviewed by: stevek, imp
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D44414
(cherry picked from commit a8eb3b365eb63d2a569b166f2dfc982967d3a7fa)
Set BINDIR before we include bsd.init.mk
so we can override it via local.init.mk
Reviewed by: imp
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D44413
(cherry picked from commit 01f3abbfcd59848e37118e5e2b868a7b3e98cc62)
If we are able to open /sys/firmware/fdt, but aren't able to read it,
fall back to /proc/device-tree. Remove comment that's not really true,
it turns out.
Sponsored by: Netflix
(cherry picked from commit 462af7676b3ee8a8bd9ee9b55a35c0cf815a351f)
Rather than checking against the (incorrect) -511, use the
is_linux_error() function to check to see if host_mmap failed.
Sponsored by: Netflix
(cherry picked from commit d75524b3fe21752b233f66ae8e9d6450d507f75c)
If we can read the UEFI memory map, go ahead and print the memory map.
While the kernel prints this with bootverbose, having it at this stage
is useful for debugging other problems.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44287
(cherry picked from commit a9cd3b675e243648aa681bc6ce1bf3e788be88c8)
The host_* syscalls are all raw Linux system calls, not the POSIX
wrappers that glibc / musl create. So we have to ranage change the
return value of host_llseek correctly to use the negative value hack
that all Linux system calls use.
This fixes a false positive error detection when we do something like
lseek(fd, 0xf1234567, ...); This returns 0xf1234567, which is a negative
value which used to trigger the error path. Instead, we check using the
is_linux_error() and store the return value in a long. Translate that
errno to a host errno and set the global errno to that and return
-1. lseek can't otherwise return a negative number, since it's the
offset after seeking into the file, which by definition is positive.
This kept the 'read the UEFI memory map out of physical memory' from
working on aarch64 (whose boot loader falls back to reading it since
there are restrictive kernel options that can also prevent it), since
the physical address the memory map was at on my platform was like
0xfa008018.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44286
(cherry picked from commit d650c3efb638f1b2742429a5fb8e7c087839868b)
offset is signed. Copy it to the unsigned res before shifting. This
avoids any possible undefined behavior for right shifting signed
numbers. No functional change intended (and the code generated is the
nearly same for aarch64).
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D44285
(cherry picked from commit 8b1925f29c54f5791db3c8dcdf2b67541bb8ab32)
Linux has the convention of returning -ERRNO to flag errors from its
system calls. Sometimes other negative values are returned that are
success... However, only values -1 to -4096 (inclusive) are really
errors. The rest are either truncated values that only look negative (so
use long instead of int), or are things like addresses or legal unsigned
file offsets or similar that are successful returns. Filter out the
latter.
Sponsored by: Netflix
(cherry picked from commit 3ae18fdfbcaad827defdc217386e73c993beeba0)
