This patch adds a general mechanism for providing encryption keys to the
kernel from the boot loader. This is intended to enable GELI support at
boot time, providing a better mechanism for passing keys to the kernel
than environment variables. It is designed to be extensible to other
applications, and can easily handle multiple encrypted volumes with
different keys.
This mechanism is currently used by the pending GELI EFI work.
Additionally, this mechanism can potentially be used to interface with
GRUB, opening up options for coreboot+GRUB configurations with completely
encrypted disks.
Another benefit over the existing system is that it does not require
re-deriving the user key from the password at each boot stage.
Most of this patch was written by Eric McCorkle. It was extended by
Allan Jude with a number of minor enhancements and extending the keybuf
feature into boot2.
GELI user keys are now derived once, in boot2, then passed to the loader,
which reuses the key, then passes it to the kernel, where the GELI module
destroys the keybuf after decrypting the volumes.
Submitted by: Eric McCorkle <eric@metricspace.net> (Original Version)
Reviewed by: oshogbo (earlier version), cem (earlier version)
MFC after: 3 weeks
Relnotes: yes
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D9575
Make sure sensitive memory is properly cleared when finished with it
Reviewed by: Eric McCorkle <eric@metricspace.net>
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D9798
We have parallel NFSv2 and NFSv3 reader implementations, only configurable at
build time, defaulting to v3. Remove v2.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D10206
The current efi_zfs_probe() is overcomplicated and can be made
simpler. Still we need to pick up the device handle for our boot
disk first, because the ESP does not have to be the first partition on the
disk.
Once we do have the handle for boot disk, we probe that disk with
pointer for pool GUID.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D10198
While testing 32bit UEFI OVMF (which has bug about how the disk size
is presented), I did witness the errors from blkio->ReadBlocks().
It became apparent we can not entirely trust UEFI interfaces either,
so additional checks are needed.
So we use disk_ioctl(DIOCGMEDIASIZE) for disks, with fallback of
Media->LastBlock for other media.
In addition, we need to check if there is media present.
+ small fixes for error printout, and avoiding multiple blk * 512.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D10197
doesn't help clang, but buys us another 32 bytes for gcc 4.2.1. It
also eliminates a warning from gcc 6.3.0 that says inlining this would
be unhelpful.
This is being done to make it easier to change in the future--this action might be
needed sooner rather than later because of gcc 6.3.0 bailing, stating that there
is negative free space left (deficit) in the boot2 bootloader.
MFC after: 2 months
Sponsored by: Dell EMC Isilon
self_reloc.c doesn't initialize `rel` in all cases in the C code, however, the value
might be initialized properly on the stack in the assembly code.
For right now (because this doesn't seem to be breaking anything and my initializing
the stack value could break something since it's called from assembly code) disable
the warning for self_reloc.c. More investigation should be done to determine the
appropriate response to this warning (either intialize the value or find a smarter
way to deal with the warning).
A long MFC timeout is being set for this change to allow a better solution for the
issue to be developed in that time period.
MFC after: 2 months
Reported by: Jenkins (FreeBSD-head-amd64-gcc job)
Tested with: amd64-gcc-6.3.0 (devel/amd64-xtoolchain-gcc)
Sponsored by: Dell EMC Isilon
With some file system the ls is unable to display file types.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D10066
Move the time related function into time.c, keep the same logic as libefi.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D10058
`-Wno-missing-variable-declarations` is a clang-specific flag,
so gcc (not 4.2.1, in particular 6.3.0 in my case) dies when
it's passed the flag.
X-MFC with: r304321
Reported by: amd64-gcc-6.3.0 (devel/amd64-xtoolchain-gcc)
Sponsored by: Dell EMC Isilon
This is a better pattern to follow when creating the bootloaders and doing
the relevant space checks to make sure that the sizes aren't exceeded (and
thus, copy-pasting is a bit less error prone).
MFC after: 3 days
Sponsored by: Dell EMC Isilon
This variable has been unused since its inception in r40106.
MFC after: 3 days
Reported by: amd64-gcc-6.3.0 (devel/amd64-xtoolchain-gcc)
Sponsored by: Dell EMC Isilon
zfssubr.c already defines this statically. Besides, zfsimpl.c defined it, but
didn't use it.
This fixes a -Wredundant-decls warning.
MFC after: 3 days
Reported by: amd64-gcc-6.3.0 (devel/amd64-xtoolchain-gcc)
Sponsored by: Dell EMC Isilon
This fixes several -Wshadow warnings introduced in r192194, but now errors
with gcc 6.3.0.
MFC after: 3 days
Reported by: amd64-gcc-6.3.0 (devel/amd64-xtoolchain-gcc)
Sponsored by: Dell EMC Isilon
This fixes a -Wempty-body warning with gcc 6.3.0 when PART_DEBUG is undefined.
MFC after: 3 days
Reported by: Jenkins (FreeBSD-head-amd64-gcc job)
Tested with: amd64-gcc-6.3.0 (devel/amd64-xtoolchain-gcc)
Sponsored by: Dell EMC Isilon
bde enabled -fno-guess-branch-probability in 2003, well before our
current compiler was imported. At the time it produced weirdly orded
code. It no longer does that. It also saves 0-4 bytes depending on
other options.
kan disabled unit-at-a-time in 2004 because it badly mangled boot2 so
it wouldn't work. That too was before the 4.2.1 compiler, where it no
longer does that. This saves 44 bytes.
I had planned to document why they were needed, but when I discovered
their antiquity, I removed them and boot2 still works and is
smaller. In qemu, the old and new boot2's behaved identically.
These are gcc specific hacks, and won't affect clang-built boot2
at all.
Don't compile geliargs into the image and don't pass geliargs to the respective
bootloader code via __exec(..).
This saves a negligible amount of memory/disk space.
X-MFC with: r296963
Obtained from: Isilon OneFS
Sponsored by: Dell EMC Isilon
clang is now inserting .file directives with the entire path in
them. This is fine, except that our sed peephole optimizer removes
them if ${SRCTOP} or ${OBJTOP} contains 'align' or 'nop', leading to
build failures. The sed peephole optimizer removes useful things for
boot2 when used with clang, so restrict its use to gcc. Also, gcc no
longer generates nops to pad things, so there's no point in removing
it. Specialize the optimization to just removing the .align 4 lines to
preclude inadvertant path matching.
Sponsored by: Netflix
Commit brought to you the path: /home/xxx/NCD-3592-logsynopts/FreeBSD
Since the uset can set dhcp.interface-mtu, we need to try to validate the
value. So we verify if the conversion to int is successful and we will not
allow to set value greater than max IPv4 packet size.
Also use snprintf for safety.
Reviewed by: allanjude, bapt
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D8492
In r315408, disk_cleanup was removed, which is called at
sys/boot/userboot/userboot/userboot_disk.c:113.
This causes bhyveload to fail.
PR: 217935
Reported by: Fabian Freyer
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D10060
We should be more verbose about read errors from biosdisk, except filter
out the floppy controller errors, which apparently are resulting from
read attempt from device without the media present.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D10032
As we provide the disk size verification and correction via disk_ioctl
and disk state provided by disk_open(), we can not share the partition
state in disk_devdesc structure. Also the sharing does make a lot of sense
with ufs, as only one partition is open at any given time, but zfs pools
do keep the disk devices open.
To make sure we do get the correct information about the open device,
just remove the cache.
Reviewed by: allanjude, smh
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D9757
The boot1.efi immediate issue from PR216964 is that we are reading into
too small buffer, from UEFI spec 2.6:
The size of the Buffer in bytes. This must be a multiple of the intrinsic block size of the device.
The secondary issue is that LBA calculation does not check reminder from
division.
This fix does check the provided buffer size and if we read less than
media sector size or the read offset is not aligned to sector boundary,
we allocate bounce buffer and perform the read by single sector.
PR: 216964
Reported by: Sergey Kozlov
Reviewed by: allanjude, Sergey Kozlov
Approved by: allanjude (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D9870
Some other hypervisors like Xen can pretend to be Hyper-V but obviously
they can't implement all Hyper-V features. Let's make sure we're genuine
Hyper-V here.
Also fix some minor coding style issues.
PR: 211746
MFC after: 2 weeks
Sponsored by: Microsoft
Do not return error if __local_fixups__ node is missing in DTB overlay
because local fixup data is optional.
Reported by: Manuel Stuhn
MFC after: 1 week
TFTP/MFSRoot booting via PXE. For the TFTP_LOADER case, go ahead and
fire off the old bootp() request to ensure that whatever is missing is
populated.
Sponsored by: Limelight Networks
The 2 files may not exist on other archs like aarch64 and hence we
can have a build failure there.
Reported by: lwhsu
MFC after: 2 weeks
Sponsored by: Microsoft
Doing this on physical hosts turns out to be problematic, e.g. see comment
24 and 28 in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746.
To fix the real underlying issue correctly & thoroughly, IMO we need
a relocatable kernel, but that would require a lot of complicated long
term work: https://reviews.freebsd.org/D9686?id=25414#inline-56969
For now, let's only apply efi_verify_staging_size() to VMs running on
Hyper-V, and restore the old behavior on physical machines since that
has been working for people for a long period of time, though that's
potentially unsafe...
MFC after: 2 weeks
Sponsored by: Microsoft
r314828(loader.efi: fix an off-by-one bug in efi_verify_staging_size())
doesn't really fix the bug and this patch adds the missing part.
It's a shame that I didn't make everything correct at the very beginning...
MFC after: 2 weeks
Sponsored by: Microsoft
Also remove the warning message: it may not be unusual to see
the memory range containing 2MB is not of EfiConventionalMemory.
MFC after: 2 weeks2 weeks
Sponsored by: Microsoft
This patch fixes my recent patch
"loader.efi: reduce the size of the staging area if necessary", which
causes EFI-boot failure on physical machines since Mar 2:
on the host there is a 1MB LoaderData memory range, which splits
the big Conventional Memory range into a small one (15MB) and a
big one: the small one is too small to hold the staging area.
We can actually use the LoaderData range safely, because when
amd64_tramp -> efi_copy_finish() starts to run, we're almost at
the very end of the efi loader code and we're going to "return"
to the kernel entry, so we're pretty sure we won't access any loader
data any more.
For people who are interested in the details: please see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746#c22
PS, some people also reported the regression happened to FreeBSD VM
running on Bhyve in EFI mode. This patch should resolve it too,
though I don't have such a setup to test.
Reviewed by: sephe
Approved by: sephe (mentor)
MFC after: 2 weeks
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D9904
The loader assumes physical memory in [2MB, 2MB + EFI_STAGING_SIZE)
is Conventional Memory, but actually it may not, e.g. in the case
of Hyper-V Generation-2 VM (i.e. UEFI VM) running on Windows
Server 2012 R2 host, there is a BootServiceData memory block at
the address 47.449MB and the memory is not writable.
Without the patch, the loader will crash in efi_copy_finish():
see PR 211746.
The patch verifies the end of the staging area, and reduces its
size if necessary. This way, the loader will not try to write into
the BootServiceData memory any longer.
Thank Marcel Moolenaar for helping me on this issue!
The patch also allocates the staging area in the first 1GB memory.
See the comment in the patch for this.
PR: 211746
Reviewed by: marcel, kib, sephe
Approved by: sephe (mentor)
MFC after: 2 weeks
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D9686
