OZFS is the top of the OpenZFS tree (aka src/sys/contrib/openzfs).
ZFSOSSRC is the path to the OepnZFS sources
ZFSOSINC is the path to the OepnZFS includes
MFC After: 3 days
Move hexdump from stand/common/misc.c to stand/libsa/hexdump.c
(svn cp)
Disable use of pager - causes linking issue for boot1
can be re-enabled by defining HEXDUMP_PAGER.
Reviewed by: stevek, imp
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D26235
Some external code requires a specific set of include paths to work
properly since it emulates the typical environment the code is used
in. Enable this by creating a CFLAGS_EARLY.file variable that can be
used to build this stack. Otherwise the include stack we build for
stand programs may get in the way. Code that uses this feature has to
tolerate the normal stack of inclues being last on the list (and
presumably unused), though.
Generally, it it should only be used for the specific include
directories. Defines and that sort of thing should be done in the
normal CFLAGS variable. There is a global CFLAGS_EARY hook as well for
everything in a Makefile.
Please note that neither zstd nor encryption is
supported by the loader at this instant. This
change makes it safe to use those features in
one's root pool, but not in one's root dataset.
This is a change in preparation for stopping to use lorder.sh (D26044) and
instead assume that we have a linker newer than ~1990. Without lorder.sh
duplicates end up being passed to the linker when building .so files and this
can result in duplicate symbol definition errors.
There is one minor change: libcompiler_rt.a will no longer provide
gcc_personality_v0 and instead we now only have it in libgcc_eh.a/libgcc_s.so.
This matches GCC's behaviour.
Reviewed By: emaste, cem
Differential Revision: https://reviews.freebsd.org/D26042
than command in the loader.conf, the latter needs to be nul terminated,
otherwise garbage trailer left from zfs_nextboot() will be passed to
parse_cmd() together with loader.conf command.
While here, reset cmd to empty string if read() returns error.
Reviewed by: tsoome
It can be useful to know what type of machine we are running on for desktop
related thing.
It also allow us to support all the DMI variable that linux driver can fetch.
MFC after: 1 week
Sponsored by: Sponsored-by: The FreeBSD Foundation
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
When building on macOS with sh==zsh, newvers.sh was producing an
unterminated string literal due to \\n being turned as a newline. Fix this
by using a here document instead.
Reviewed By: imp
Differential Revision: https://reviews.freebsd.org/D26036
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
Fix typo in interp_include() invocation (missing 'p')
Remove setting tftpip, as servip is used by the tftp code in libsa. There
is no separate tftpip global variable any more.
Obtained from: Juniper Networks, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25897
On RISC-V, Clang warns with:
cast to smaller integer type 'unsigned int' from 'void (*)(void *)'
Instead, use %p as the standard format specifier for printing pointers.
Whilst Arm's pointer size is the same as unsigned, it's still cleaner to
use the right thing there too.
Reviewed by: brooks (mentor), emaste
Approved by: brooks (mentor), emaste
Differential Revision: https://reviews.freebsd.org/D25718
I made an attempt to fix this in r362978, but all it really did was
confine the issue to the $MACHINE_CPUARCH == "riscv" case. The real
problem is that LINKER_FEATURES is not defined here, so bsd.linker.mk
needs to be included.
This error with cleandir only occurs when META_MODE is disabled, which
explains why it was missed by both CI and myself.
Note that this effectively reverts r362978.
Reported by: mjg
Reviewed by: imp, kevans (in IRC)
The origin text was: "Syntax for devices is odd."
That is not very helpful.
PR: 199103
Reviewed by: kevans, tsoome
Sponsored by: Klara Inc.
Event: July 2020 Bugathon
Differential Revision: https://reviews.freebsd.org/D25629
Correct a small mistake in r363060's backaout of r362998 by reverse-applying
r362998 by hand to loader.conf.
Differential Revision: https://reviews.freebsd.org/D25606
Because we need to read asize from vdev_tree. We also need to consider
different vdev type difference.
Reviewed by: allanjude
Sponsored by: Netflix, Klara Inc.
Differential Revision: https://reviews.freebsd.org/D25586
The DIOCGMEDIASIZE is calculated md->md_sectorsize * md->md_provsize, and
for boot disk, the md_sectorsize is 4k. However, the md_provsize is already
in units of bytes.
Sponsored by: Netflix, Klara Inc.
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
The zfs reader development did reach to the point where linking boot1,
we will get errors about duplicate symbols Malloc, Free, Calloc.
We can just use libsa version, just as loader.efi does. The only concern is,
libsa zalloc is using fixed size heap region, I did pick 64MB as other
stage instances are using, but this size is likely not optimal. In any case,
with limited memory setups, we should boot loader.efi directly.
Sponsored by: Netflix, Klara Inc.
The vdev_init() does check for "known" vdev types, the [log] device removal will create "hole"
device, but vdev_init() does not allow it.
Obtained from: illumos
MFC after: 1 week
These are picked out by the amd64-gcc6 build; time() is declared in <time.h>
and delay() is declared in <bootstrap.h>. These are the correct places for
these in stand/, so remove the duplicate declarations and make sure the
delay() consumer in libefi that depended on the extra delay() declaration
includes <bootstrap.h>.
MFC after: 1 week
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
fs_summary_info structure. This change was originally done
by the CheriBSD project as they need larger pointers that
do not fit in the existing superblock.
This cleanup of the superblock eases the task of the commit
that immediately follows this one.
Suggested by: brooks
Reviewed by: kib
PR: 246983
Sponsored by: Netflix
Inject \e[J to erase the initial loader screen. We have two options,
find where out cursor is and use BIOS scroll for data from boot2 or erase the
display and start from origin. Erasing the screen is easier and we also
get the screen buffer initialized.
Sponsored by: Netflix, Klara Inc.
Having libzfs.h wrapped in LOADER_ZFS_SUPPORT check does not really make sense,
because we do need function declarations with C99.
Sponsored by: Netflix, Klara Inc.
On some UEFI implementations the ConsOut EFI variable is not a device
path end type so we never move to the next node. Fix this by always
incrementing the device path node pointer, with a sanity check that
the node length is large enough so no two nodes overlap.
While here return failure on malloc failure rather than a NULL pointer
dereference.
Reviewed by: tsoome, imp (previous version)
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D25202
Rework to simplify and impose sane url syntax.
That is we allow for file://[devname[:fstype]]/package
Reviewed by: stevek
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org//D25134
The filename is nearly always wrong since it's /boot/lua/loader.lua, which
is not useful for diagnostics. The actual errmsg will include a lua filename
if this is relevant.
Dropping "LUA" while we're here because that's almost universally
irrelevant to whatever error follows, unless the error states that it's
actually a lua problem.
Both of these are minor nits that just detract from identifying the
pertinent information.
MFC after: 3 days
The u-boot EFI implementation of the ReadBlocks and WriteBlocks methods
requires that the provided buffer meet the IO alignment requirements of
the underlying disk. Unlike loader.efi, gptboot.efi doesn't check this
requirement, and therefore fails to perform a successful read. Adjust
secbuf's alignment to 4K in hopes that we will always meet this
requirement.
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25111
At least one user has landed in a scenario where logo files appear to be
misnamed, and we failed to find them. Our fallback for missing logodefs is
orb/orbbw, based on the color status. In a scenario where we can't locate
the logos, though, this is not ideal. Add in one more layer of fallback
to properly just don't draw any logo if the fan has been jam packed with
foreign material.
PR: 246046
MFC after: 3 days
- Use enc_xform_aes_xts.setkey() directly instead of duplicating the code
now that it no longer calls malloc().
- Rather than bringing back all of xform_userland.h, add a conditional
#include of <stand.h> to xform_enc.h.
- Update calls to encrypt/decrypt callbacks in enc_xform_aes_xts for
separate input/output pointers.
Pointy hat to: jhb
Some time after r338418, I believe with -Os/-Oz -ffunction-sections
-fdata-sections, the bootprog_interp variable that held our "$Interpreter:"
marker started getting strip from all loaders, with exception to userboot
since it used bootprog_interp to determine what flavor of userboot it was.
At some point, it had been brought to my attention that this was no longer
working and I had worked up some potential solutions to use the variable
that involved printing it out. My vague recollection is that this was
rejected, and I forgot to explore the alternatives; I cannot find records of
this discussion anymore.
Fast forward to present day, Andrew reported that it was non-functional and
offered (effectively) this patch (sans comment) to stop the compiler from
optimizing it out by assigning it to a volatile variable. This removes
concerns about user-facing change while retaining the interpreter marker.
Furthermore, it could certainly be uglier.
Reported and tested by: Andrew Gierth <andrew_tao173.riddles.org.uk>
MFC after: 3 days
Assume gcc is at least 6.4, the oldest xtoolchain in the ports tree.
Assume clang is at least 6, which was in 11.2-RELEASE. Drop conditions
for older compilers.
Reviewed by: imp (earlier version), emaste, jhb
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D24802
The same thing can be achieved using the bs=$SIZE and conv=sync options.
Unlike conv=osync, conv=sync is support on both Linux and macOS.
Reviewed By: imp, jhb (earlier version)
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D24788
When reading less than sector size but from sector boundary,
the vdev_read() will read full sector into the provided buffer
and therefore corrupting memory past buffer end.
MFC after: 2 days
We need to ensure the buffers are aligned before passing them to ReadBlocks.
Assume 512 bytes is enough for now.
Reviewed by: imp
MFC after: 1 month
Sponsored by: Innovate UK
Also, dmabuf appears to only be set for sparc64 case, but there was a
comment at its only use that says it was broken for some apple
adapters. #ifdef it all of that out now that nothing sets it.
Due to the way claiming works, we need to ensure on AIM OFW machines that
we don't have overlapping ranges on any step of the load.
Load boot1.elf at 0x38000 so it will not overlap with anything even if the
entire PReP partition gets loaded by OFW.
Tested on an iBook G4, a PowerBook G4, a PowerMac G5, and qemu pseries.
(qemu pseries is broken without this patch due to the high address used
by lld10.)
Reviewed by: adalava
Sponsored by: Tag1 Consulting, Inc.
Differential Revision: https://reviews.freebsd.org/D24623
The previous interface was pretty bad, and required the caller to get some
implementation details correct that it really shouldn't need to (e.g.
loader_conf_files handling) and pass in an empty table for it to use.
The new and much improved interface, readConf, is much less of a hack;
hiding these implementation details and just doing the right thing.
config.lua will now use it to process /boot/defaults/loader.conf and the
subsequent loader_conf_files from there, and read-conf will also use it.
This improvement submitted by Olivier (cited below), loader_conf_files
handling from the original patch was changed to just clobber it before
processing and not bother restoring it after the fact following r360505
where it's now guaranteed to evade the loader environment.
PR: 244640
Submitted by: Olivier Certner (olivier freebsd free fr>
This new table should be used for transient values that don't need to end up
in the loader environment. Generally, these will be things that are internal
details that really aren't needed or interesting outside of the config
module (e.g. if we changed how ${module}_* directives work, they might use
this instead).
To start, populate it with loader_conf_files. Any specific value of
loader_conf_files isn't all that interesting; if we're going to export it,
we should really instead export a loader_conf_files that indicates all of
the configuration files we processed. This will be used to reduce
bookkeeping overhead in a future commit that cleans up readConfFiles.
A future change in lualoader may take some liberties with the
loader_conf_files in the name of efficiency; namely, it may start omitting
it from the loader environment entirely so that it doesn't need to worry
about maintaining any specific value.
This variable has historically been incredibly volatile anyways, as it may
get set to completely different values in any given configuration file to
trigger a load of more files.
Document now that we may not maintain it in the future, but perhaps we'll
reserve the right to change our minds and eventually formally export all of
the loader configuration files that were read using this variable.
MFC after: 3 days
While we're here, let's stylize these as functions instead of just raw text.
A future change may allow arbitrary data arguments to be passed some of
these, and the distinction is useful.
This makes sure that config.readConfFiles doesn't see a stale
loader_conf_files from before, in case the newly loaded file doesn't set it.
MFC after: 3 days
This is a straightforward match to the command used by many in forthloader;
it uses the newly-exported config.readConfFiles() to make sure that any
loader_conf_files gets done as appropriate.
PR: 244640
Submitted by: Olivier Certner <olivier freebsd free fr>
MFC after: 3 days
In the process, change it slightly: readConfFiles will take a string like
loader_conf_files in addition to the loaded_files table that it normally
takes. This is to facilitate the addition of a read-conf CLI command, which
will just pass in the single file to read and an empty table.
MFC after: 3 days
We don't actually need to fetch loader_conf_files as much as we do; we've
already fetched it once at the beginning, we only really need to fetch it
again after each file we've processed. If it changes, then we can stash that
off into our local prefiles.
While here, drop a note about the recursion so that I stop trying to
change it. It may very well make redundant some of the work we're doing, but
that's OK.
MFC after: 3 days
These mappings are never visible to userspace as they get replaced when
the amd64 pmap is bootstrapped, but there is no need to set PG_U in the
first place.
Reviewed by: alc, kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D24547
This stops the compiler from using the x18 register. Some UEFI
implementations assume this will be preserved when calling the Boot
Services.
MFC after: 2 weeks
Sponsored by: Innovate UK
Make menu customizations easier by naming the entries and using the
names to build the table entries.
Reviewed by: kevans
Approved by: mav (mentor)
MFC after: 1 week
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D24527
This code was trying to use a pointer value for st_dev, which is definitely
not a pointer. Instead, cast to uintptr_t so it becomes a non-pointer value
before casting it.
Tested: mips-gcc cross compile, mips32 build
prison0's hostuuid will get set by the hostid rc script, either after
generating it and saving it to /etc/hostid or by simply reading /etc/hostid.
Some things (e.g. arbitrary MAC address generation) may use the hostuuid as
a factor in early boot, so providing a way to read /etc/hostid (if it's
available) and using it before userland starts up is desirable. The code is
written such that the preload doesn't *have* to be /etc/hostid, thus not
assuming that there will be newline at the end of the buffer or even the
exact shape of the newline. White trailing whitespace/non-printables
trimmed, the result will be validated as a valid uuid before it's used for
early boot purposes.
The preload can be turned off with hostuuid_load="NO" in /boot/loader.conf,
just as other preloads; it's worth noting that this is a 37-byte file, the
overhead is believed to be generally minimal.
It doesn't seem necessary at this time to be concerned with kern.hostid.
One does wonder if we should consider validating hostuuids coming in
via jail_set(2); some bits seem to care about uuid form and we bother
validating format of smbios-provided uuid and in-fact whatever uuid comes
from /etc/hostid.
Reviewed by: karels, delphij, jamie
MFC after: 1 week (don't preload by default, probably)
Differential Revision: https://reviews.freebsd.org/D24288
Although PPC OFW loader already had a LOADER_MSDOS_SUPPORT option, a few lines
were missing in conf.c, in order to support FAT filesystems.
This is useful when running FreeBSD under QEMU, to be able to easily change the
kernel and modules when running on hosts without UFS read/write support.
Reviewed by: jhibbits
Sponsored by: Eldorado Research Institute (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D24328
On slow platforms, it helps to spread the hashing load
over time so that tftp does not timeout.
Also, some .4th files are too big to fit in cache of pkgfs,
so increase cache size and ensure fully populated.
Reviewed by: stevek
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D24287
- beriloader: archsw is declared extern and defined elsewhere
- ofwloader: ofw_elf{,64} are defined in elf_freebsd.c and
ppc64_elf_freebsd.c respectively
- ubldr: syscall_ptr is defined in start.S for whichever ubldr platform is
building
-fno-common will become the default in GCC10/LLVM11.
MFC after: 3 days
OpenFirmware (OF) method instantiate-rtas was being called with a wrong
rtas-base-address argument. It must use the memory that is already being
allocated to this end instead. This issue was causing QEMU netboot to hang
when building the FDT from OF DT.
Reviewed by: jhibbits
Sponsored by: Eldorado Research Institute (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D24313
The efi console init is avoided since conin setup was moved to probe.
In case the console is re-initialized, we need to pick up colors
from environment.
This option is intended to aid development, to allow building with user malloc.
The use case would be to build userboot & test with libc (or other) malloc and
use extra malloc debug features.
Now that LLD 10 is out, and required patches have landed, we are now ready
to finally switch away from the ancient in-tree ld.bfd.
Special thanks to Fangrui Song for many hours of work on getting the
32-bit powerpc lld ready for prime-time.
Reviewed by: emaste (earlier revision), jhibbits
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D24111
We need a valid st_dev, st_ino and st_mtime
to correctly track which files have been verified
and to update our notion of time.
ve_utc_set(): ignore utc if it would jump our current time
by more than VE_UTC_MAX_JUMP (20 years).
Allow testing of install command via userboot.
Need to fix its stat implementation too.
bhyveload also needs stat fixed - due to change to userboot.h
Call ve_error_get() from vectx_close() when hash is wrong.
Track the names of files we have hashed into pcr
For the purposes of measured boot, it is important
to be able to reproduce the hash reflected in
loader.ve.pcr
so loader.ve.hashed provides a list of names in the order they
were added.
Reviewed by: imp
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org//D24027
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
armv7 crash due to misligned access of dos_partition dp_start field.
Allocate and make copy of dos_partition array to make sure the data
is aligned.
Reported by: marklmi at yahoo.com
This hook can be useful, for example to run a local function to choose
different modules to load when a user has picked a different kernel
from the menu.
Reviewed by: kevans
Approved by: mav (mentor)
MFC after: 1 week
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D24115
The SCR, scratch register was not present on the 8250 and 8250B UART, so we
can use to test if we actually do have serial port.
We need this test because some systems will get long delays while attempting
to write to non-existing port and this will slow down the console IO
to extreme.
MFC after: 1 week
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
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
Before this change, LLD10 was creating several extra PT_LOAD sections,
which OFW does not understand.
Like we do for the kernel already, specify the program headers manually.
Additionally, to work around a crash in our base ld.bfd, we need to
actually assign something to the output section. LLD does not need this.
One side effect of this change is the removal of the GNU_STACK header.
This is more correct, since we are using a statically-allocated stack and
RWX mappings across the board this early in boot.
Reviewed by: jhibbits, Fangrui Song <i@maskray.me>
Sponsored by: Tag1 Consulting, Inc.
Differential Revision: https://reviews.freebsd.org/D23778
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
We still need to set the hooks to prevent improper manipulations thereafter
at the loader prompt, but as it is we're actively preventing loaddev from
being set correctly in some circumstances (ZFS in particular) and doing more
work than needed with currdev -- that hook in particular validates it as a
correct device, which we can assume isn't needed in this context.
Reviewed by: imp, sigsys@gmail.com
Submitted/Diagnosed by: sigsys@gmail.com
Differential Revision: https://reviews.freebsd.org/D23390
If we hit an error at this level, we are almost certainly not in any kind
of sane state where autoboot can do the right thing. Instead of letting it
try and probably failing, disable autoboot so they immediately get kicked
into a loader prompt for manual remediation/diagnosis.
Reviewed by: tsoome
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D23611
vdev_read_pad2() does read VDEV_PAD_SIZE of data, and will copy size bytes
of it, hence, we need buffer of VDEV_PAD_SIZE bytes.
Issue introduced in r357497.
Reported by: se
CD boot is broken for some systems since bioscd and biosdisk merge. The issue is that we can not use anything else than int 13 ah=0x4b to query cd information.
The patch does restore the same probe as was originally used in bioscd.c. Additionally extra buffer padding is used to avoid memory corruption caused by some systems.
PR: 234031
Reported by: ultramage and others
MFC after: 1 day
stand/i386/gptboot/gptldr.S:141:3: error: value of 36878 is too large for field of 2 bytes.
jmp MEM_JMP # Start BTX
^
Use the same construct as in stand/i386/boot2/boot1.S, which ensures the
jump distance does not become too large.
MFC after: 3 days
This may be used for the local module to hook in and load any additional
modules that it wants, since it can't modify the modules table internal to
config. We may consider adding API to do so at a later time, but I suspect
it will be more complicated to use with little return.
status is captured but ignored for the purpose of loading the hook. status
will be false if *any* module failed to load, but we typically don't let
that halt the boot so there's no reason to let it halt hooks. Some vendors
or setups may have expected fails that would be actively thwarted by
checking it.
We may, at a later date, consider adding an API for letting non-config
modules check which modules have successfully (or not) loaded in case an
unexpected failure *should* halt whatever they are doing.
MFC after: 3 days
The major problem with the current ordering is that loader.conf may contain
all of the magic we need to actually setup the console, so loading local.lua
prior to that can make it excessively difficult and annoying to debug
(whoops, sorry Ravi & Warner).
The new ordering has some implications, but I suspect they are a non-issue.
The first is that it's no longer possible for the local module to inject any
logic prior to loading config -- I suspect no one has relied on this. The
second implication is that the config.loaded hook is now useless, as the
local module will always be included after that hook would have fired.
For config.loaded, I will opt to leave it in, just in case we add an early
point for local lua to get injected or in case one wants to schedule some
deferred logic in a custom loader.lua. The overhead of having it if no hooks
will be invoked is relatively minimal.
Diagnosed by: imp
Reported by: imp, rpokala (most likely)
MFC after: 3 days
As a new x86 CPU vendor, Chengdu Haiguang IC Design Co., Ltd (Hygon)
is a joint venture between AMD and Haiguang Information Technology Co.,
Ltd., aims at providing x86 processors for China server market.
The first generation Hygon processor(Dhyana) shares most architecture
with AMD's family 17h, but with different CPU vendor ID("HygonGenuine")
and PCI vendor ID(0x1d94) and family series number 18h(Hygon negotiated
with AMD to confirm that only Hygon use family 18h).
To enable Hygon Dhyana support in FreeBSD, add new definitions
HYGON_VENDOR_ID("HygonGenuine") and X86_VENDOR_HYGON(0x1d94) to identify
Hygon Dhyana CPU.
Initialize the CPU features(topology, local APIC ext, MSI, TSC, hwpstate,
MCA, DEBUG_CTL, etc) for amd64 and i386 mode by sharing the code path of
AMD family 17h.
The changes have been applied on FreeBSD 13.0-CURRENT and tested
successfully on Hygon Dhyana processor.
References:
[1] Linux kernel patches for Hygon Dhyana, merged in 4.20:
https://git.kernel.org/tip/c9661c1e80b609cd038db7c908e061f0535804ef
[2] MSR and CPUID definition:
https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf
Submitted by: Pu Wen <puwen@hygon.cn>
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D23163
Due to the way u-boot for 32-bit powerpc is compiled, the interrupt code
assumes that the GOT pointer (r30) on u-boot is always intact.
When making syscalls to u-boot, ensure that we have restored r30 like we
found it before we enable interrupts to prevent u-boot from crashing if a
timer interrupt was pending.
This fixes ubldr on e500 qemu (assuming you have recompiled qemu's u-boot
with API support!)
Reviewed by: jhibbits
Sponsored by: Tag1 Consulting, Inc.
Differential Revision: https://reviews.freebsd.org/D23258
Currently, our overlay blob will grow to include the size of the complete
overlay blob we're applying. This doesn't scale very well with a lot of
overlays- they tend to include a lot of overhead, and they will generally
only add a fraction of their total size to the blob they're being applied
to.
To combat this, pack the blob as we apply new overlays and keep track of how
many overlays we've applied. Only ubldr has any fixups to be applied after
overlays, so we only need to re-pad the blob in ubldr. Presumably the
allocation won't fail since we just did a lot worse in trying to apply
overlays and succeeded.
I have no intention of removing the padding in make_dtb.sh. There might be
an argument to be had over whether it should be configurable, since ubldr
*is* the only loader that actually has fixups to be applied and we can do
this at runtime, but I'm not too concerned about this.
This diff has been sitting in Phabricator for a year and a half, but I've
decided to flush it as it does make sure that we're scaling the blob
appropriately and leave room at the end for fixups in case of some freak
circumstance where applying overlays leaves us with a blob of insufficient
size.
Reviewed by: gonzo (a long time ago)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D14133
Since rS330365, there has been no particular reason for libofw to be in a
subdirectory of ofw. Move libofw up a level to make it fit in better with
the other top level libraries.
Also add a LIBOFWSRC to stand/defs.mk to match what all the other
libraries are doing.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D23000
Summary:
This patch is to support ongoing work for replacing "GCC/BFD" by "CLANG/LLD" on
target PowerPC64 [1], by proposing a way to specify and/or locate a secondary
ld.bfd linker.
This is necessary as LLD currently doesn't support PowerPC 32 bits, so we keep
using BFD for the 32 bit stuff on PowePC64(LIB32 compatibility and
STAND/slof/loader.)
- creates LD_BFD variable pointing to ld.bfd
- use LD_BFD as linker for LIB32/compat
- Default behavior for other platforms aren't changed.
[1] https://wiki.freebsd.org/powerpc/llvm-elfv2
Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D20261
partitions can have 128 partitions, so parse contiguous digits and then
validate that the number is between 1-128 inclusive.
I'm not sure 128 is a hard limit in the GPT standard, but it's the common
number in use, and it's a better upper limit than 9.
This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.
Updating the vendor area to match this layout is next.
From UEFI specification 2.8, page 434:
"It should also be noted that certain input devices may not be able to produce
shift or toggle state information, and in those cases the high order bit in
the respective Toggle and Shift state fields should not be active."
But we still need to check for ScanCode and UnicodeChar.
PR: 242660
Reported by: Trond Endrestol
MFC after: 1 week
For all the INT13 calls, use symbolic names instead of magic numbers. This makes
it easier to understand what the code is doing w/o a trip to google to find what
these numbers mean.
In some cases the pool discovery will get stuck in infinite loop while setting
up the vdev children.
To fix, we split the vdev setup into two parts, first we create vdevs based on
configuration we do get from pool label, then, we process pool config from MOS
and update the pool config if needed.
Testing done: confirm previously hung loader is not hung any more.
MFC after: 1 week
Instead of passing NULL to fzap_name_equal and crashing, just return
ENOENT. This happened when higher bits of a hash of the searched key
(its hash prefix) matched a hash prefix of some key in the ZAP, but the
full hash value of the searched key did not match any key in the ZAP.
I observerved this problem when loader tried to look up
"features_for_read" in a particular old pool that predates pool
features.
MFC after: 2 weeks
Sponsored by: Panzura
We do allocate amount of memory (void * or char *), and then assign this
buffer to struct iso_primary_descriptor *vd. Make sure we do
allocate enough bytes.
In fact we do allocate enough, but it is good idea to make sure this really
is so.
MFC after: 1 week
Lua allocates LUAL_BUFFERSIZE buffers on the stack for various string
functions (string.format, string.gsub) -- this works out to be somewhat
significant and not necessary, based on how we use string operations.
Dropping it risks having to allocate per call to format/gsub, but this is
not the case for our usage. This simply stops allocating 8K buffers on the
stack when luaL_Buffer is used.
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22500
Update a bunch of Makefile.depend files as
a result of adding Makefile.depend.options files
Reviewed by: bdrewery
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D22494
Summary:
There's no need to use the fallback fls() and flsl() libkern functions
when the PowerISA includes instructions that already do the bulk of the
work. Take advantage of this through the GCC builtins __builtin_clz()
and __builtin_clzl().
Reviewed by: luporl
Differential Revision: https://reviews.freebsd.org/D22340
o Remove All Rights Reserved from my notices
o imp@FreeBSD.org everywhere
o regularize punctiation, eliminate date ranges
o Make sure that it's clear that I don't claim All Rights reserved by listing
All Rights Reserved on same line as other copyright holders (but not
me). Other such holders are also listed last where it's clear.
r354247 converted try_include to lfs + dofile with the loader.lua_path added
just before. Fortunately, there was a hardcoded /boot/lua fallback in case
loader.lua_path wasn't being set yet- I typo'd it as loader.lua_paths.
Fix the typo.
X-MFC-With: r354247
MFC after: 3 days
Just as disks can have nested partitions, the same happens with cd devices,
so we need to detect device paths and make sure we will not mix the handles.
To address this:
we fetch handle array and create linked list of block devices.
we walk the list and detect parent devices and set children pd_parent.
for {fd, cd, hd}, we walk device list and pick up our devices and store to
corresponding list. We make sure we store parent device first.
For sorting we use 3 steps: We check for floppy, we check for cd and then
everything else must be hd.
In general, it seems the floppy devices have no parent.
CD can have both parents and children (multiple boot entries, partitions
from the hybrid disk image).
Tested by: cross+freebsd@distal.com on Cisco UCS systems, C200 series (C220M5, C240M4).
Also on MBP with UEFI 1.10
Reported by: Chriss Ross
MFC after: 1w
Differential Revision: https://reviews.freebsd.org/D22553
RB_MULTIPLE without RB_SERIAL set is valid, and means 'Video first, then serial'
to the kernel (so kernel messages go to both, but /etc/rc uses video console
(this should be fixed, btw, but another day)). Check for RB_MULTIPLE as well as
RB_SERIAL where we want to to serial things. This means we'll use the old code
for emulation in these situations, which is likely best since we're outputing to
both and the old code is ligher weight allowing both to keep up w/o weird
scrolling things.
With a very large kernel or module the staging area may be too small to
hold it. When this is the case try to allocate more space before failing
in the efi copyin/copyout/readin functions.
Reviewed by: imp, tsoome
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D22569
illumos/illumos-gate@663207adb1663207adb1
10601 Pool allocation classes
https://www.illumos.org/issues/10601
illumos port of ZoL Pool allocation classes. Includes at least these two
commits:
441709695 Pool allocation classes misplacing small file blocks
cc99f275a Pool allocation classes
10757 Add -gLp to zpool subcommands for alt vdev names
https://www.illumos.org/issues/10757
Port from ZoL of
d2f3e292d Add -gLp to zpool subcommands for alt vdev names
Note that a subsequent ZoL commit changed -p to -P
a77f29f93 Change full path subcommand flag from -p to -P
Portions contributed by: Jerry Jelinek <jerry.jelinek@joyent.com>
Portions contributed by: Håkan Johansson <f96hajo@chalmers.se>
Portions contributed by: Richard Yao <ryao@gentoo.org>
Portions contributed by: Chunwei Chen <david.chen@nutanix.com>
Portions contributed by: loli10K <ezomori.nozomu@gmail.com>
Author: Don Brady <don.brady@delphix.com>
11541 allocation_classes feature must be enabled to add log device
illumos/illumos-gate@c1064fd7cec1064fd7cehttps://www.illumos.org/issues/11541
After the allocation_classes feature was integrated, one can no longer add a
log device to a pool unless that feature is enabled. There is an explicit check
for this, but it is unnecessary in the case of log devices, so we should handle
this better instead of forcing the feature to be enabled.
Author: Jerry Jelinek <jerry.jelinek@joyent.com>
FreeBSD notes.
I faithfully added the new -g, -L, -P flags, but only -g does something:
vdev GUIDs are displayed instead of device names. -L, resolve symlinks,
and -P, display full disk paths, do nothing at the moment.
The use of special vdevs is backward compatible for read-only access, so
root pools should be bootable, but exercise caution.
MFC after: 4 weeks
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
Include the server IP address when logging nfs_open(), add a few missing
"\n"s, and correct a typo.
Reviewed by: kevans
MFC after: 2 weeks
Sponsored by: Panasas
Differential Revision: https://reviews.freebsd.org/D22346
In our case the structure is more complex and simple static initializer
will upset compiler diagnostics - using memset is still better than building
more complext initializer.
In the EFI implementation in U-Boot no ConOut efi variable is created,
this cause loader to fallback to TERM_EMU implementation which is very
very very slow (and uses the ConOut device in the system table anyway).
The UEFI spec aren't clear as if this variable needs to exists or not.
Reviewed by: imp, kevans
UEFI 1.10 on macs does not seem to provide devpath to name translation,
provide our own (limited) version, so we can get information about commmon
devices.
MFC after: 1 week
The macos does create Vendor Media devices on top of APFS container
(like partition table inside the partition), so we need to collect such
devices into respective device tree.
MFC after: 1 week
Since physical device asize is calculated from psize and the asize is stored
in pool label, we can use asize to set the value of psize, which is used to
calculate the location of the pool labels.
MFC after: 1 week
Port illumos change: https://www.illumos.org/issues/11667
Move lz4.c out of zfs tree to opensolaris/common/lz4, adjust it to be
usable from kernel/stand/userland builds, so we can use just one single
source. Add lz4.h to declare lz4_compress() and lz4_decompress().
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D22037
In case of efi console having serial backend (video + serial or only serial),
we need to stick with old emulator till we can draw console.
Eventually we would need to get console terminal emulator to be removed
from serial console because the serial link already has the terminal.
However, we need to implement comconsole on all efi platforms first, then
we need the ability to draw console, so we do not have to use SimpleTextOutput
protocol (which will write both on video and serial in case of multiplexed
ComOut).
Differential Revision: https://reviews.freebsd.org/D22161
Actual modules get require()'d in, rather than try_include(). All instances
of try_include should be provided with proper hooks/API in the rest of
loader to do the work they need to do, since we can't rely on them to exist.
Convert this now to lfs + dofile since we won't really be treating them as
modules.
lfs is required because dofile will properly throw an error if the file
doesn't exist, which is not in the spirit of 'optionally included'.
Getting out of the pcall game allows us to provide a loader.exit() style
call that backs out to the common bits of loader (autoboot sequence unless
disabled with a loader.setenv("autoboot_delay", "NO")). The most ideal way
identified so far to implement loader.exit() is to throw a special
abort-style error that indicates to the caller in interp_lua that we've not
actually errored out, just continue execution. Otherwise, we have to hack in
logic to bubble up and return from loader.lua without continuing further,
which gets kind of ugly depending on the context in which we're aborting.
A compat shim is provided temporarily in case the executing loader doesn't
yet have loader.lua_path, which was just added in r354246.
As described previously, loader.lua_path is absolute path where scripts are
installed. A future commit will use this to build paths for dofile in
try_include, rather than the current pcall/require setup that makes it more
difficult to coordinate loader aborts from local.lua -- we do not need the
flexibility of require(), and local.lua is in-fact not a 'module-like' file
as we will not be referencing anything from it.
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
