kib [Thu, 7 Mar 2019 13:53:59 +0000 (13:53 +0000)]
MFC r339941 (by mckusick):
In preparation for adding inode check-hashes, change the fsck_ffs
inodirty() function to have a pointer to the inode being dirtied.
No functional change (as for now the parameter is ununsed).
Also for stable/11 UFS_NDADDR was renamed to NDADDR.
dab [Thu, 7 Mar 2019 13:10:48 +0000 (13:10 +0000)]
MFC r344470:
Fix several Coverity-detected issues in newsyslog.
- CID 1394815, CID 1305673: Dereference before null check - memory was
allocated and the allocation checked for NULL with a call to errx()
if it failed. Code below that was guaranteed that the pointer was
non-NULL, but there was another check for NULL at the exit of the
function (after the memory had already been referenced). Eliminate
the useless NULL check.
- CID 1007452: Resource leak - Storage intended to be allocated and
returned to the caller was never freed. This was the result of a
regression in the function signature introduced in r208648 (2010)
(thanks for that find, @cem!). Fixed by altering the function
signature and passing the allocated memory to the caller as
intended. This also fixes PR158794.
- CID 1008620: Logically dead code in newsyslog.c - This was a direct
result of CID 1007452. Since the memory allocated as described there
was not returned to the caller, a subsequent check for the memory
having been allocated was dead code. Returning the memory
re-animates the code that is the subject of this CID.
- CID 1006131: Unused value - in parsing a configuration file, a
pointer to the end of the last field was saved, but not used after
that. Rewrite to use the pointer value. This could have been fixed
by avoiding the assignment altogether, but this solutions more
closely follows the pattern used in the preceding code.
jhb [Wed, 6 Mar 2019 22:13:53 +0000 (22:13 +0000)]
MFC 330882: Simplify error handling in t4_tom.ko module loading.
- Change t4_ddp_mod_load() to return void instead of always returning
success. This avoids having to pretend to have proper support for
unloading when only part of t4_tom_mod_load() has run.
- If t4_register_uld() fails, don't invoke t4_tom_mod_unload() directly.
The module handling code in the kernel invokes MOD_UNLOAD on a module
whose MOD_LOAD fails with an error already.
new_kmem_alloc(9) is a Solaris/illumos malloc(9). FreeBSD and NetBSD
never get here, however a test for SOLARIS, as redundant as this test is,
serves to document that this is the illumos definition. This should help
those who come after me to follow the code more easily.
Kernel module shim sources have no business being in the userland
build directory, especially those for other operating systems.
The kernel module shims for other operating systems are hereby removed.
The kernel module shim for FreeBSD, mlfk_ipl.c, is already in
sys/contrib/ipfilter/netinet. The one here is never used and should
not be in the userland build directory either.
mlfk_rule.c isn't used either however we will keep it in case someone
wishes to use this shim to load rules via a kernel module, handy for
embedded. In that case it should be copied to
sys/contrib/ipfilter/netinet and a Makefile created to employ it.
(Probably a useful documentation project when time permits.)
Remove #ifdefs for ancient and irrelevant operating systems from
ipfilter.
When ipfilter was written the UNIX and UNIX-like systems in use
were diverse and plentiful. IRIX, Tru64 (OSF/1) don't exist any
more. OpenBSD removed ipfilter shortly after the first time the
ipfilter license terms changed in the early 2000's. ipfilter on AIX,
HP/UX, and Linux never really caught on. Removal of code for operating
systems that ipfilter will never run on again will simplify the code
making it easier to fix bugs, complete partially implemented features,
and extend ipfilter.
Unsupported previous version FreeBSD code and some older NetBSD code
has also been removed.
What remains is supported FreeBSD, NetBSD, and illumos. FreeBSD and
NetBSD have collaborated exchanging patches, while illumos has expressed
willingness to have their ipfilter updated to 5.1.2, provided their
zone-specific updates to their ipfilter are merged (which are of interest
to FreeBSD to allow control of ipfilters in jails from the global zone).
emaste [Tue, 5 Mar 2019 18:54:47 +0000 (18:54 +0000)]
freebsd-update: Use BASEDIR when checking for src componentfreebsd-update: Use BMFC r343152: freebsd-update: Use BASEDIR when checking for src component
src could potentially be installed under the based dir
and not under the root or vice versa.
PR: 224048
Submitted by: Gerald Aryeetey <aryeeteygerald_rogers.com>
Reviewed by: delphij
Sponsored by: The FreeBSD Foundation
emaste [Tue, 5 Mar 2019 18:11:36 +0000 (18:11 +0000)]
MFC r343589: freebsd-update: regenerate man page database after update
These are currently not reproducible because they're built by the
makewhatis on the freebsd-update build host, not the one in the tree.
Regenerate after update, and later we can avoid including it in
freebsd-update data.
PR: 214545, 217389
Reviewed by: delphij
Sponsored by: The FreeBSD Foundation
pf: IPv6 fragments with malformed extension headers could be erroneously passed by pf or cause a panic
We mistakenly used the extoff value from the last packet to patch the
next_header field. If a malicious host sends a chain of fragmented packets
where the first packet and the final packet have different lengths or number of
extension headers we'd patch the next_header at the wrong offset.
This can potentially lead to panics or rule bypasses.
Reported by: Corentin Bayet, Nicolas Collignon, Luca Moro at Synacktiv
Approved by: so
Obtained from: OpenBSD
Security: CVE-2019-5597
mm [Thu, 28 Feb 2019 22:56:15 +0000 (22:56 +0000)]
MFC r344063,r344088:
MFC r344063:
Sync libarchive with vendor.
Relevant vendor changes:
PR #1085: Fix a null pointer dereference bug in zip writer
PR #1110: ZIP reader added support for XZ, LZMA, PPMD8 and BZIP2
decopmpression
PR #1116: Add support for 64-bit ar format
PR #1120: Fix a 7zip crash [1] and a ISO9660 infinite loop [2]
PR #1125: RAR5 reader - fix an invalid read and a memory leak
PR #1131: POSIX reader - do not fail when tree_current_lstat() fails
due to ENOENT [3]
PR #1134: Delete unnecessary null pointer checks before calls of free()
OSS-Fuzz 10843: Force intermediate to uint64_t to make UBSAN happy.
OSS-Fuzz 11011: Avoid buffer overflow in rar5 reader
Pull in r353378 from upstream lld trunk (by George Rimar):
[LLD][ELF] - Set DF_STATIC_TLS flag for X64 target
This is the same as D57749, but for x64 target.
"ELF Handling For Thread-Local Storage" p41 says
(https://www.akkadia.org/drepper/tls.pdf):
R_X86_64_GOTTPOFF relocation is used for IE TLS models.
Hence if linker sees this relocation we should add DF_STATIC_TLS flag.
This adds support to lld for the DF_STATIC_TLS flag in shared objects,
which signals to the dynamic linker that the shared object requires
static thread local storage.
mav [Thu, 28 Feb 2019 00:29:15 +0000 (00:29 +0000)]
MFC r344441: Fix few issues in ioat(4) driver.
- Do not explicitly count active descriptors. It allows hardware reset
to happen while device is still referenced, plus simplifies locking.
- Do not stop/start callout each time the queue becomes empty. Let it
run to completion and rearm if needed, that is much cheaper then to touch
it every time, plus also simplifies locking.
- Decouple submit and cleanup locks, making driver reentrant.
- Avoid memory mapped status register read on every interrupt.
- Improve locking during device attach/detach.
- Remove some no longer used variables.
dab [Wed, 27 Feb 2019 22:29:26 +0000 (22:29 +0000)]
MFC r344473:
CID 1332000: Logically dead code in sys/dev/pms/RefTisa/tisa/sassata/sas/ini/itdio.c
A pointer is first tested for NULL. If non-NULL, another pointer is
set equal to the first. The second pointer is then checked for NULL
and an error path taken if so. This second test and the associated
path is dead code as the pointer value, having just been checked for
NULL, cannot be NULL at this point. Remove the dead code.
kevans [Wed, 27 Feb 2019 17:00:27 +0000 (17:00 +0000)]
MFC r344218: mdmfs(8): use -o reserve with malloc-backed md(4)
Mentioned in mdconfig(8), malloc-backed md(4) can be unstable unless
required memory is allocated up front with -o reserve. Furthermore, panics
have been observed with md used in fstab on 12.0-RELEASE. Choose the stable
route and pass -o reserve.
tuexen [Mon, 25 Feb 2019 10:51:21 +0000 (10:51 +0000)]
MFC r343920:
Ensure that when using the TCP CDG congestion control and setting the
sysctl variable net.inet.tcp.cc.cdg.smoothing_factor to 0, the smoothing
is disabled. Without this patch, a division by zero orrurs.
tuexen [Mon, 25 Feb 2019 10:38:37 +0000 (10:38 +0000)]
Backport the new TCP reassembly code from head to stable/11.
In particular:
* Cherry pick the changes in sys/queue.h from r334804.
* MFC r338102 with manually removing changes to file not existent in
stable/11 and resolve conflicts in tcp_var.h.
This change represents a substantial restructure of the way we
reassembly inbound tcp segments. The old algorithm just blindly
dropped in segments without coalescing. This meant that every
segment could take up greater and greater room on the linked list
of segments. This of course is now subject to a tighter limit (100)
of segments which in a high BDP situation will cause us to be a
lot more in-efficent as we drop segments beyond 100 entries that
we receive. What this restructure does is cause the reassembly
buffer to coalesce segments putting an emphasis on the two
common cases (which avoid walking the list of segments) i.e.
where we add to the back of the queue of segments and where we
add to the front. We also have the reassembly buffer supporting
a couple of debug options (black box logging as well as counters
for code coverage). These are compiled out by default but can
be added by uncommenting the defines.
* Manually fix tcp_stacks/fastopen.c, since it does not exist anymore
in head.
* MFC r342280:
Fix a regression in the TCP handling of received segments.
When receiving TCP segments the stack protects itself by limiting
the resources allocated for a TCP connections. This patch adds
an exception to these limitations for the TCP segement which is the next
expected in-sequence segment. Without this patch, TCP connections
may stall and finally fail in some cases of packet loss.
* MFC r343439:
Don't include two header files when not needed.
This allows the part of the rewrite of TCP reassembly in this
files to be MFCed to stable/11 with manual change.
* MFC r344428:
This patch addresses an issue brought up by bz@ in D18968:
When TCP_REASS_LOGGING is defined, a NULL pointer dereference would happen,
if user data was received during the TCP handshake and BB logging is used.
A KASSERT is also added to detect tcp_reass() calls with illegal parameter
combinations.
vmaffione [Mon, 25 Feb 2019 09:13:33 +0000 (09:13 +0000)]
MFC r343579, r344253
netmap: fix lock order reversal related to kqueue usage
When using poll(), select() or kevent() on netmap file descriptors,
netmap executes the equivalent of NIOCTXSYNC and NIOCRXSYNC commands,
before collecting the events that are ready. In other words, the
poll/kevent callback has side effects. This is done to avoid the
overhead of two system call per iteration (e.g., poll() + ioctl(NIOC*XSYNC)).
When the kqueue subsystem invokes the kqueue(9) f_event callback
(netmap_knrw), it holds the lock of the struct knlist object associated
to the netmap port (the lock is provided at initialization, by calling
knlist_init_mtx).
However, netmap_knrw() may need to wake up another netmap port (or even
the same one), which means that it may need to call knote().
Since knote() needs the lock of the struct knlist object associated to
the to-be-wake-up netmap port, it is possible to have a lock order reversal
problem (AB/BA deadlock).
This change prevents the deadlock by executing the knote() call in a
per-selinfo taskqueue, where it is possible to hold a mutex.
The change also adds a counter (kqueue_users) to keep track of how many
kqueue users are referencing a given struct nm_selinfo.
In this way, nm_os_selwakeup() can schedule the kevent notification
task only when kqueue is actually being used.
This is important to avoid wasting CPU in the common case where
kqueue is not used.
dim [Sat, 23 Feb 2019 14:27:09 +0000 (14:27 +0000)]
MFC r344386:
Pull in r354515 from upstream libc++ trunk:
Fix the build with gcc when `-Wredundant-decls` is passed
Summary:
gcc warns that `__throw_runtime_error` is declared both in
`<__locale>` and `<stdexcept>`, if `-Wredundant-decls` is passed on
the command line; this is the case with FreeBSD when ${WARNS} == 6.
Since `<__locale>` gets its first declaration via a transitive
include of `<stdexcept>`, and the second declaration is after the
first invocation of `__throw_runtime_error`, delete that second
declaration.
Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>
Reviewers: kristina, MaskRay, EricWF, ldionne, ngie
kevans [Fri, 22 Feb 2019 03:10:24 +0000 (03:10 +0000)]
Direct commit for some clarification/correction
The notice in UPDATING stated the wrong direction for the link.
Additionally, it's decidedly not a bad idea to throw in a comment mandating
that the ordering of LOADER_DEFAULT_INTERP bits remains the same in this
branch. This makes it even more obvious from diff review (against head) that
this difference is intentional and creates merge conflicts if someone tries
to apply the original commit manually. I suspect this won't be a problem
given the set of people that maintain loader bits in stable/11, but it does
offer a peace of mind.
gjb [Thu, 21 Feb 2019 17:27:37 +0000 (17:27 +0000)]
Update the stable/11 arm SoC IMAGE_SIZE to 3072M as build
failures were encountered due to the target filesystem
running out of space during the installkernel target.
The 3072M size is used as it is consistent with head and
stable/12 image sizes, and build failures due to a full
filesystem have been common enough to justify making the
default size the same across all supported branches in
order to avoid such surprises.
This is a direct commit to stable/11, as there are several
changes between several size bumps that are unrelated or
unnecessary in this branch.
dim [Thu, 21 Feb 2019 07:22:05 +0000 (07:22 +0000)]
MFC r344264:
Add one additional file to libllvmminimal, since in some cases (e.g.
upgrading from stable/10 to stable/11) symbols from it are needed to
link llvm-tblgen and clang-tblgen.
kevans [Thu, 21 Feb 2019 06:02:51 +0000 (06:02 +0000)]
Direct commit to catch pc98 up to recent changes
I have no means of actually testing the new features on pc98, so simply mark
them as BROKEN_OPTIONS on pc98 and interested parties can test/report back
as to the functionality. This is done out of an abundance of caution.
pc98 also needed catching up on the inflate.c -> subr_inflate.c rename.
kevans [Thu, 21 Feb 2019 03:48:39 +0000 (03:48 +0000)]
Direct commit for post-mortem UPDATING update regarding lualoader
Indicate that it's been merged (after some delay since lua came back to this
branch) and how one can test lua, both by swapping build knobs and creating
links in /boot.
r337806:
Create a loader for each interpreter for x86 BIOS and all EFI
Create loader_{4th,lua,simp}{,.efi}. All of these are installed by
default. Create LOADER_DEFAULT_INTERP to specify the default
interpreter when no other is specified. LOADER_INTERP is the current
interpreter language building. Turn building of lua on by default to
match 4th. simploader is a simplified loader build w/o any interpreter
language (but with a simple loader). This is the historic behavir you
got with WITHOUT_FORTH. Make a hard link to the default loader. This
has to be a hard link rather than the more desirable soft link because
older zfsboot blocks don't support symlinks.
r337868:
stand: Use -Oz/-Os for all loader/stand builds.
While we're not super size constrained, the x86 BIOS /boot/loader has
to be less than about 520k-530k to be reliable. The LUA loader is at
this size today. -Oz saves 15-20% on the size, keeping us safely small
enough (comparable to where we were with the 4th loader). This will
also help with sjg's work on bringing in bearssl, though we may again
be looking for space in the LUA loader.
Now that we're using -Os, mips needs these routines.
r337989:
Copy the boot loader from the new location for the co-existing
loaders.
r338052:
libsa: Add lshrdi3.c for powerpc* and mips
r338064:
Turn back the clock just a little: make userboot.so always be 4th
Turns out there was a hidden dependency we hasn't counted upon. The
host load /boot/userboot.so to boot the VMs it runs. This means that
the change to lua meant suddently that nobody could run their older
VMs because LUA wasn't in 10.0, last month's HardenedBSD, 11.2 or
whatever. Even more than for the /boot/loader* binaries, we need a
good coexistance strategy for this. While that's being designed and
implemented, drop back to always 4th for userboot.so. This will fail
safe in all but the most extreme environments (but lua-only hacks
to .lua files won't be processes in VMs until we fix it).
r338407:
lualoader: Print error messages from command failures at the prompt
Previously lualoader would remain silent, rather than printing
command_errmsg or noting that a command had failed or was not found.
r338418:
userboot: handle guest interpreter mismatches more intelligently
The switch to lualoader creates a problem with userboot: the host is
inclined to build userboot with Lua, but the host userboot's interpreter
must match what's available on the guest. For almost all FreeBSD guests in
the wild, Lua is not yet available and a Lua-based userboot will fail.
This revision updates userboot protocol to version 5, which adds a
swap_interpreter callback to request a different interpreter, and tries to
determine the proper interpreter to be used based on how the guest
/boot/loader is compiled. This is still a bit of a guess, but it's likely
the best possible guess we can make in order to get it right. The
interpreter is now embedded in the resulting executable, so we can open
/boot/loader on the guest and hunt that down to derive the interpreter it
was built with.
Using -l with bhyveload will not allow an intepreter swap, even if the
loader specified happens to be a userboot with the wrong interpreter. We'll
simply complain about the mismatch and bail out.
For legacy guests without the interpreter marker, we assume they're 4th.
For new guests with the interpreter marker, we'll read it and swap over
to the proper interpreter if it doesn't match what the userboot we're using
was compiled with.
Both flavors of userboot are installed by default, userboot_4th.so and
userboot_lua.so. This fixes the build WITHOUT_FORTH as a coincidence, which
was broken by userboot being forced to 4th.
r338474:
Be a little conservative about when to force size optimizations.
Reports have come in that there's issue with powerpc and sparc64 since
we've switched to using -Oz / -Os. We don't strictly need them for
!x86, so be conservative about when we enable them.
kevans [Thu, 21 Feb 2019 02:52:27 +0000 (02:52 +0000)]
MFC r336837: Be more conservative about setting hw.uart.console
Note when we've found a 8250 PNP node. Only try to set hw.uart.console
if we see one (otherwise ignore serial hints). The 8250 is the only
one known to have I/O ports, so limit the guessing to when we've
positively seen one. And limit this to x86 since that's the only
platform where we have I/O ports. Otherwise, we'd set the serial port
to something crazy for the platform and fall off the cliff early in
boot.
kevans [Thu, 21 Feb 2019 02:50:45 +0000 (02:50 +0000)]
MFC r336431: stand: Fix UEFI console scrolling
Remove bogus attempt to simulate scrolling. It's not needed and messes
up serial output. Setting the cursor position after every character is
inefficient, and causes all lines to be over-printed in the serial
console for the boot loader. Allow the terminal to do the emulation.
This isn't completely perfect when the size of the terminal attached
to the serial port isn't the same as 80x25 to match the viedoe console
(or whatever the video console is). While imperfect still, these
changes make it much better.
kevans [Thu, 21 Feb 2019 02:46:32 +0000 (02:46 +0000)]
MFC r338337: Fix lualoader on arm64
Lua has a few places where it allocates a large buffer on the stack. This
is normally fine, except there are a few places where there can be multiple
frames with this buffer. This can cause a stack overflow on some arm64 SoCs.
Fix this by allocating our own stack in loader.efi large enough for these
objects. The required size has been found by tracing how the stack pointer
changes in a virtual machine and found to be no larger than 50kB. A
larger stack is allocated to reduce the likelihood of overflow from future
changes.
A small cleanup, fix the argument type and while there, replace (char *)0 with
NULL.
r337038:
libsa: bootp is using pointers with different sign
Just change bp_file to char and same for variable s.
r337039:
libsa: assignment to char * from u_char *
Cast to char * instead of u_char *
r337065:
libsa: dereferencing type-punned pointer in cd9660
The warning is given by gcc build, but it is good to fix anyhow.
use bcopy instead of direct assignment.
r337412:
libsa: dos_checksum() should take unsigned chars
Fix pointers to integers with different sign issue.
r337413:
libsa: gzipfs.c converts pointers to integer types with different sign
Signed versus unsigned char.
r337874:
libsa: zfs_probe() needs to set spa to NULL
Silence the warning about possibly uninitialized use of spa.
r338535:
libsa: memory leak in tftp_open()
tftpfile is allocated just above and needs to be freed.
r338540:
libsa: validate tftp_makereq() after we did reset the read
The name check referred in the comment is not the only possible error source,
we need to validate the result.
r339651:
libsa: re-send ACK for older data packets in tftp
In current tftp code we drop out-of-order packets; however, we should play
nice and re-send ACK for older data packets we are receiving. This will
hopefully stop server repeating those packets we already have received.
Note we do not answer duplicates from "previous" session (that is, session
with different port number), those will eventually time out.
r339992:
libsa: tftp should not read past file end
When we have the file size via tsize option, use it to make sure we
will not attempt to read past file end.
kevans [Thu, 21 Feb 2019 02:37:01 +0000 (02:37 +0000)]
MFC r336651-r336655: stand: libefi: various boot protocol aux impl.
r336651:
Implement efi_devpath_to_media_path
Takes a generic device path as its input. Scans through it to find the
first media_path node in it and returns a pointer to it. If none is
found, NULL is returned.
r336652:
Store the number of handles we get back in efipart_nhandles rather
than the number of bytes. Don't divide by the element size every time
we have to iterate. Eliminate now-unused variables.
r336653:
Implement efi_devpath_match_node
Returns true if the first node pointed to by devpath1 is identical to
the first node pointed to by devpath2, with care taken to not read
past the end of the valid parts of either devpath1 or
devpath2. Otherwise, returns false.
r336654:
Implement efi_devpath_length
Return the total length, in bytes, of the device path (including the
terminating node at the end).
Lookup a block device by it's device path. We use a 'loose' lookup
whereby we scan forward to the first Media Path portion of the device
path, then look at all our handles for one whose first Media Path
matches. This will also work if the device path pointed to has a
following file path (or paths) as that's ignored. It assumes that
there's only one media path node that describes the entire device,
which is true as of the latest UEFI spec (2.7 Errata A) as far as I've
been able to determine.
r336264:
Define ADR subtype of ACPI type for a device path.
r336270:
uefi stand: Guess the console better
For server machines, ComOut is set to the set of devices that the efi
console suppots. Parse it to see if we have serial, video or both.
Make that take precidence over the command line args. boot1.efi parses
them, but loader.efi doesn't. It's not clear where to read boot.conf
from, so we don't do that. The command line args can still be set via
efibootmgr, which is more inline with the UEFI boot manager to replace
that. These args are typically used only to set serial vs video and
the com speed line. We can infer that from ComOut, so do so.
Remember the com speed and hw.uart.console to match.
r336271:
Add reporting of whether or not a keyboard is detected. In addition,
note that r336270's commit message was slightly incorrect. It changed
the default setting of the console to honor the ConOut
variable. Overrides via the command line are still possible, and we
use the devices in ConOut to set the proper console. If, for example,
serial cosnole is specified, we'll set console to "efi" if ConOut has
a serial port list and to either "efi comconsole" or "comconsole efi"
if not depending on whether -D or -D -h was specified.
r336272:
Minor adjustments:
o Fix the parsing of the device path. a last minute change terminated
it too soon.
o Kill setting LINES. We don't need to do it, and even if we did hard
coding it to 24 is wrong.
o Now that the console is working again for the loader, adjust the
printfs to be more in line with other platforms.
r336464:
If the console is already set, don't override it.
If console=X is specified on the command line, it's effectively
overridden by the current code. It shouldn't do that.
r336627:
Fix the attempt to see if we're overriding the console in the command
line args. I had thought console would be NULL, but it's efi. Set it
to efi (as a clue) before we initialize the console, then test it to
see if it changed on the command line to do the automatic
override. This gets my serial console back.
Note that this MFC contains some seemingly unrelated zfsloader bits -- this
was needed in order to pull in some later fixes for GELI hand-off w/ ZFS
bits included.
r336252:
Extend loader(8) geli support to all architectures and all disk-like devices.
This moves the bulk of the geli support from lib386/biosdisk.c into a new
geli/gelidev.c which implements a devsw-type device whose dv_strategy()
function handles geli decryption. Support for all arches comes from moving
the taste-and-attach code to the devopen() function in libsa.
After opening any DEVT_DISK device, devopen() calls the new function
geli_probe_and_attach(), which will "attach" the geli code to the open_file
struct by creating a geli_devdesc instance to replace the disk_devdesc
instance in the open_file. That routes all IO for the device through the
geli code.
A new public geli_add_key() function is added, to allow arch/vendor-specific
code to add keys obtained from custom hardware or other sources.
With these changes, geli support will be compiled into all variations of
loader(8) on all arches because the default is WITH_LOADER_GELI.
r336254:
Use if rather than case for a simple boolean. gcc thinks blks is
undefined sometimes with the case, but enc is always 0 or 1, so
and if / else is better anyway.
r336256:
Fix glitched indentation (and rewrap as needed due to deeper indent).
No functional changes.
r336354:
zfsboot: fix build with WITHOUT_LOADER_GELI
r336532:
Collapse zfsloader functionality back down into loader.
We no longer really need a separate zfsloader. It was useful when we
were first supporting ZFS and had limited ability to properly boot off
of ZFS without the special boot loader. Now that the boot loader has
matured, go the way loader.efi pioneered and just build one
binary. Change the name of the loader to load in the secondary boot
blocks to be just /boot/loader. Provide a symbolic link from zfsloader
to loader so people who have not upgraded their boot blocks are not
affected. This has the happy benefit of making coexistence easier as
well (fewer binaries in the matrix).
r336533:
Eliminate zfsloader man page.
Remove all cross references to zfsloader.8 and /boot/zfsloader.
Move ZFS specific info into loader.8.
r336534:
NM and OBJCOPY are already defined for all builds. There's no need to
conditionally define them here.
r336537:
Mention zfsloader being folded into loader in UPDATING.
r336626:
Older zfs boot blocks don't support symlinks. install the link to
zfsloader as a hard link. While newer ones do, the whole point of the
link was to transition to the new world order smoothly. A hard link is
less flexible, but it works and will result in fewer bumps. Adjust
UPDATING entry to match.
r337326:
loader: biosdisk.c has leftover geli header.
A small cleanup, remove unneeded #include.
r337349:
zfsboot: Fix startup crash
On a FreeNAS mini XL, with geli encrypted drives the loader crashed in
geli_read().
When we iterate over the list of disks and allocate the zfsdsk structures we
don’t zero out the gdev pointer. In one case that resulted in geli_read()
(called on the bogus pointer) dividing by zero.
Use calloc() to ensure the zfsdsk structure is always zeroed, so the pointer is
initialised to NULL. As a side benefit it gets rid of one #ifdef
LOADER_GELI_SUPPORT.
r341071:
Restore the ability to override the disk unit/partition at the boot: prompt
in gptboot.
When arch-independent geli support was added, a new static 'gdsk' struct
was added, but there was still a static 'dsk' struct, and when you typed
in an alternate disk/partition, the string was parsed into that struct,
which was then never used for anything. Now the string gets parsed into
gdsk.dsk, the struct that's actually used.
r341160:
Add comments describing the bootargs handoff between loader(8) and gptboot
or zfsboot, when loader(8) is the BTX loader. No functional changes.
r341420:
Eliminate duplicated code and struct member definitions in the handoff
of args data between gptboot/zfsboot and loader(8).
Despite what seems like a lot of changes here, there are no actual
changes in behavior, or in the data layout in the structures involved.
This is just eliminating identical code pasted into multiple locations.
In detail, the changes are...
- Move struct zfs_boot_args definition from libsa/zfs/libzfs.h to
i386/common/bootargs.h because it is specific to x86 booting and the
handoff between zfsboot and loader, and has no relation to the zfs
library code in general.
- The geli_boot_args and zfs_boot_args structs both contain an identical
set of member variables containing geli information. Extract this out
to a new geli_boot_data struct, and embed it in the arg-passing structs.
- Provide new routines geli_import_boot_data() and geli_export_boot_data()
that can be shared between gptboot, zfsboot, and loader instead of
pasting identical code into several different .c files.
- Remove some checks for a NULL pointer that can never be true because the
pointer being tested was set using pointer math (kargs + 1) and that can
never result in NULL in this code.
r341473:
Fix args cross-threading between gptboot(8) and loader(8) with zfs support.
When loader(8) is built with zfs support enabled, it assumes that any extarg
data present is a zfs_boot_args struct, but if the first-stage loader was
gptboot(8) the extarg data is actually a geli_boot_args struct. Luckily,
zfsboot(8) and gptzfsboot(8) have always passed KARGS_FLAGS_ZFS along with
KARGS_FLAGS_EXTARG, so we can use KARGS_FLAGS_ZFS to decide whether the
extarg data is a zfs_boot_args struct.
To avoid similar problems in the future, gptboot(8) now passes a new
KARGS_FLAGS_GELI to indicate that extarg data is geli_boot_args. In
loader(8), if the neither KARGS_FLAGS_ZFS nor KARGS_FLAGS_GELI is set but
extarg data is present (which will be the case for gptboot compiled before
this change), we now check for the known size of the geli_boot_args struct
passed by the older versions of gptboot as a way of confirming what type of
extarg data is present.
In a semi-related tidying up, since loader's main() has already decided
what type of extarg data is present and set the global 'zargs' var
accordingly, don't repeat the check in extract_currdev, just check whether
zargs is NULL or not.
r341651:
Don't reference zfs-specific variables if LOADER_ZFS_SUPPORT is undefined
because the variables will be undefined too.
r342793:
MK_ZFS -> {MK_ZFS|MK_LOADER_ZFS}, this is so we can diable userland / kernel
ZFS but keep the boot-loaders when using ZoL port.
Relnotes: yes (GELI support extended)
Relnotes: yes (zfsloader has been collapsed into loader and may be
removed after boot blocks have been updated)
r316312:
sys/geom/eli: Switch bzero() to explicit_bzero() for sensitive data
In GELI, anywhere we are zeroing out possibly sensitive data, like
the metadata struct, the metadata sector (both contain the encrypted
master key), the user key, or the master key, use explicit_bzero.
Didn't touch the bzero() used to initialize structs.
r332361:
Introduce dry run option for attaching the device.
This will allow us to verify if passphrase and key is valid without
decrypting whole device.
r333438:
Change option dry-run from 'n' to 'C' in geli attach command.
'n' is used in other commands to define the key index.
We should be consistent with that.
'C' option is used by patch(1) to perform dryrun so lets use that.
r333439:
Introduce the 'n' flag for the geli attach command.
If the 'n' flag is provided the provided key number will be used to
decrypt device. This can be used combined with dryrun to verify if the key
is set correctly. This can be also used to determine which key slot we want to
change on already attached device.
r339804:
Restore backward compatibility for "attach" verb.
In r332361 and r333439, two new parameters were added to geli attach
verb using gctl_get_paraml, which requires the value to be present.
This would prevent old geli(8) binary from attaching geli(4) device
as they have no knowledge about the new parameters.
Restore backward compatibility by treating the absense of these two
values as seeing the default value supplied by userland.
dab [Wed, 20 Feb 2019 22:48:55 +0000 (22:48 +0000)]
MFC r344024:
CID 1009492: Logically dead code in sys/cam/scsi/scsi_xpt.c
In `probedone()`, for the `PROBE_REPORT_LUNS` case, all paths that
fall to the bottom of the case set `lp` to `NULL`, so the test for a
non-NULL value of `lp` and call to `free()` if true is dead code as
the test can never be true. Fix by eliminating the whole if
statement. To guard against a possible future change that accidentally
violates this assumption, use a `KASSERT()` to catch if `lp` is
non-NULL.
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8143
r336249:
Fix sparc64 builds
gcc is complaining about struct infate being defined in a parameter
list. It's inclear how long this has been broken, but the fix is
simple enough.
r336250:
There's two files in the sys tree named inflate.c, in addition
to it being a common name elsewhere. Rename the old kzip one
to subr_inflate.c.
This actually fixes the build issues on sparc64 that my inclusion of
.PATH ${SYSDIR}/kern created in r336244, so also revert the broken
workaround I committed in r336249.
This slipped passed me because apparently, I never did a clean build.
r336244:
Create helper functions for parsing boot args.
boot_parse_arg to parse a single arg
boot_parse_cmdline to parse a command line string
boot_parse_args to parse all the args in a vector
boot_howto_to_env Convert howto bits to env vars
boot_env_to_howto Return howto mask mased on what's set in the environment.
All these routines return an int that's the bitmask of the args
translated to RB_* flags. As a special case, the 'S' flag sets the
comconsole_speed env var. Any arg that looks like a=b will set the env
key 'a' to value 'b'. If =b is omitted, 'a' is set to '1'. This
should help us reduce the number of redundant copies of these routines
in the tree. It should also give a more uniform experience between
platforms.
Also, invent a new flag RB_PROBE that's set when 'P' is parsed. On
x86 + BIOS, this means 'probe for the keyboard, and if it's not there
set both RB_MULTIPLE and RB_SERIAL (which means show the output on
both video and serial consoles, but make serial primary). Others it
may be some similar concept of probing, but it's loader dependent
what, exactly, it means.
These routines are suitable for /boot/loader and/or the kernel,
though they may not be suitable for the tightly hand-rolled-for-space
environments like boot2.
r336246:
Eliminate boot loader copies of boot arg parsing.
Eliminate 4 of the copies of the arg parsing in /boot/laoder
by using boot_parse_cmdline.
r336247:
Transition to boot_env_to_howto and boot_howto_to_env in the boot
loader.
kevans [Wed, 20 Feb 2019 19:13:09 +0000 (19:13 +0000)]
MFC r336084-r336085, r336118: Move zfs impl into libsa
r336084:
Move ZFS files into libsa
Move the libzfs stuff into libsa. There's no need for it to be a
separate library. The separate library adds to the issues of build
ordering that we see from time to time. Move the filesystem support
into libsa, like all the other filesystem support rather than making
zfs the odd-duck out.
Discussed with: allanjude@
r336085:
Stop using ../zfs/libzfs.h but instead use libzfs.h.
While ../zfs/libzfs.h mostly works, there are a few situations where
it does not. Eliminate the problem by using plain libzfs.h, like we do
for ufs support. This fixes the weird cases, and is easier to
understand. It also follows the general style convetion of avoiding
../ in #includes.
r336118:
Remove dirs that git svn should have removed but didn't.
Some of these commits were improperly MFC'd in the sys/boot => stand
mega-MFC, others were simply missed. Correct that mistake now by manually
merging the few that were missed and record-only merge on the others.
r304850:
Unused variables and cstyle fix for loader dosfs
r305480:
Renumber the advertising clause.
r324550:
Add $FreeBSD$ to ancient sources that it's missing from.
r324551:
Move lib/libstand to sys/boot/libsa
Move the sources to sys/boot. Make adjustments related to the
move. Kill LIBSTAND_SRC since it's no longer needed.
r324655:
Remove the libstand directory which is now empty.
r324684:
Remove lib/libstand again, accidentally readded in r324683
r335869:
stand: uboot: Do not panic if we can't find a boot device
It is really anoying to panic when there is no boot device as you
cannot see the availables ones.
r335933:
loader: fdt: Try to load every possible DTB from u-boot
U-Boot setup a few variables :
- fdt_addr which is the board static dtb (most of the time loaded before
u-boot or coming from some hardware like a ROM)
- fdt_addr_r which is a location in RAM that holds the DTB loaded by
u-boot or before u-boot
In the case of u-boot + rpi firmware the DTB is loaded in RAM but the location
still end up in the fdt_addr variable and the fdt_addr_r variable exist.
Change the behavior so we test that a DTB exists for every possible variable :
- fdt_addr_r is checked first as if u-boot needed to modify it the
correct DTB will live there.
- fdt_addr is checked second as if we run on a hardware with DTB in ROM
it means that we what/need to run that
- fdtaddr looks like a FreeBSD-ism but since I'm not sure leave it.
kevans [Wed, 20 Feb 2019 18:46:31 +0000 (18:46 +0000)]
MFC r335773: Revert preference to be an int.
While in base we use it as a boolean (of the wrong spelling), there's
at least one out of tree user that needs it to be int since priorirty
is a small int, not a 0/1. In deference to the time it's wasted me and
my team, push this up into FreeBSD for whatever short life boot1 may
have in the tree.
kevans [Wed, 20 Feb 2019 18:44:09 +0000 (18:44 +0000)]
MFC r335321, r335336: stand: move libgeliboot into libsa
r335321:
stand: move libgeliboot into libsa.
Reduce by 1 the number of crazy libraries we need in stand by moving
geli into libsa (where architecturally it belonged all along). This
just moves things around without any code changes.
r335229:
Provide a more direct interface to tell ZFS what the preferred handle
is. We tell the ZFS code now, and it checks rather than having a
callback to do the checks.
This will allow us to have a more graceful fallback code. In the
future, it's anticipated that we may fallback to a more global search
(or implement a command to do so) when reqeusted by the user, or we
detect a violation of the UEFI Boot Manager protocol severe enough to
warrant this backstop. For now, it just allows us to get rid of img as
a global.
r335230:
Move arg parsing into its own routine for possible later reuse.
r335231:
There's no need to walk through the tables looking for the smbios
table if we're just going to ignore it on arm, so expand, slightly,
the reach of the ifdef. Move the buffer to the inner block so we
don't have a separate #ifdef far away from these lines.
The issue on arm is that smbios_detect does unaligned accesses, which
in the u-boot implementing EFI context causes a crash.
r335272:
Many netboot scenarios don't have /boot/defaults/loader.conf. As
a fallback, also check /boot/kernel/kernel existing as well, since
that's the fallback behavior of the loader.
kevans [Wed, 20 Feb 2019 18:30:54 +0000 (18:30 +0000)]
MFC r334412: userboot: Fix bad type-punning
Pass a struct devdesc to the format commands. Use proper type rather
than doing weird type-punning that happened to work because the size
was right. We copied a zfs devdesc into a disk_devdesc and then after
passing through a NULL pointer reinterpreted it as a
zfs_devdesc. Instead, pass the base devdesc around and 'upcase' when
we know the types are right.
This has the happy side effect of fixing a gcc warning about bad
type punning.
pfg [Wed, 20 Feb 2019 14:12:25 +0000 (14:12 +0000)]
MFC r344042:
UMA: unsign some variables related to allocation in hash_alloc().
As a followup to r343673, unsign some variables related to allocation
since the hashsize cannot be negative. This gives a bit more space to
handle bigger allocations and avoid some implicit casting.
While here also unsign uh_hashmask, it makes little sense to keep it
signed.
r335245:
Correct logic error in biosdisk.c:bd_realstrategy()
The wrong condition is used when evaluating the return of disk_ioctl()
This results in reaching the 'We should not get here' branch in most casts
r335246:
biosdisk.c remove redundant variable
`rdev` and `disk` serve the same purpose, read the partition table without
the `d_offset` or `d_slice` set, so the read is relative to the start of
the disk. Reuse the already initialized `disk` instead of making another
copy later.
r335247:
biosdisk.c: add missing \n to error message
r335248:
biosdisk.c: fix type in debug printf
r335254:
Avoid reading past the end of the disk in zfsboot.c and biosdisk.c
The GELI boot code rounds reads up to 4k, since the encrypted sectors are
4k, and must be decrypted as a unit. With oddball sized disks (almost
always virtual), this can lead to reading past the end of the disk.
r335276:
gptboot, zfsboot, gptzfsboot: Enable the video and serial consoles early
Normally the serial console is not enabled until /boot.config is read and
we know how the serial console should be configured. Initialize the
consoles early in 'dual' mode (serial & keyboard) with a default serial
rate of 115200. Then serial is re-initialized once the disk is decrypted
and the /boot.config file can be read.
This allows the GELIBoot passphrase to be provided via the serial console.
r335298:
stand/common/disk.c: Update debug printf
This was missed in r330809 because it is compiled out by default
r335398:
Revert r335276
This was causing issues for people booting.
I will likely bring this back as an optional feature, similar to
boot0sio, like gptboot-serial or something.
r335868:
stand/common/disk.c: Read partition table relative to the start of the disk
If a disk is of an oddball size, like the 200mb + 512b used in rootgen.sh,
when disk_open() is called on a GELI encrypted partition, attempts to read
the partition table fail, as they pass through the decryption process which
turns the already plaintext data into jibberish.
When reading the partition table, always pass a slice and partition setting
of -1, and an offset of 0. Setting the slice to -1 prevents a false
positive when checking the slice against the cache of GELI encrypted
slices.
r335883:
stand/common/disk.c: dev->d_offset still needs to be set to 0
With r335868, I thought this was no longer necessary. I was wrong.
kevans [Tue, 19 Feb 2019 18:32:05 +0000 (18:32 +0000)]
MFC r332555: loader: provide values in help_getnext()
With r328289 we attempt to make sure we free the resources allocated in
help_getnext(), however, it is possible that we get no resources allocated
and help_getnext() will return early.
Make sure we have pointers set to NULL early in help_getnext().
vmaffione [Tue, 19 Feb 2019 10:07:48 +0000 (10:07 +0000)]
vmx(4): add native netmap support
This change adds native netmap support for the vmx(4) adapter
(vmxnet3). Native support comes for free in 12, since the driver has been
ported to iflib. To make it minimally intrusive, the native support is
only enabled if vmxnet3.netmap_native is set at boot (e.g., in loader.conf).
Tested on stable/11 running inside vmplayer.
Submitted by: Giuseppe Lettieri <g.lettieri@iet.unipi.it>
Reviewed by: vmaffione, bryanv
Sponsored by: Sunny Valley Networks
Differential Revision: https://reviews.freebsd.org/D19104
projects / FreeBSD / FreeBSD.git / log