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
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
Cleaned up some spaces where tabs should be.
efipart_ioctl() DIOCGMEDIASIZE needs to use uint64_t, not off_t
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D9562
The efipart rework did break the ARM systems as the new code is
using more exact filters to sort the devices and we need to
add support for MEDIA_FILEPATH_DP device paths.
PR: 216940
Reported by: karl@denninger.net
Reviewed by: allanjude, manu
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D9520
Fix bugs found by Coverity in efipart.c.
The Issue is that efi_devpath_last_node() can return NULL pointer, and
therefore we should check for it. In real life we really do not
expect to see it to happen, so we will just error out from the test.
CID: 1371004
Reported by: Coverity
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D9490
Rewrite EFI part device interface to present disk devices in more
user friendly way.
We keep list of three types of devices: floppy, cd and disk, the
visible names: fdX: cdX: and diskX:
Use common/disk.c and common/part.c interfaces to manage the
partitioning.
The lsdev -l will additionally list the device path.
Reviewed by: imp, allanjude
Approved by: imp (mentor), allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D8581
The arm build has revealed some of the warnings, the fix for CHAR16
warning is to switch the warning off for env.c (same as for efinet.c).
For error code we need to use macro.
Reported by: gjb
Reviewed by: imp
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D9422
Since we have dedicated libefi/env.c file for variable support, the following
changes are done:
Simple cstyle changes in env.c
Moved efi variable related commands from loader/main.c to libefi/env.c
Did create function to set "efi-version" environment variable in env.c.
This function does serve two purposes: for first a small clean up of the
loader main(), and for second, it does replace the otherwise unused
efi_variable_support hack.
A bit of cleanup of ficl backend functions. The TEST_MAIN has no meaning,
and removed few memory leaks.
The forth code is updated to use "efi-version" variable, instead of ficl
environment check.
Reviewed by: imp
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D9165
As the efi_devpath_last_node() and efi_devpath_trim() can return NULL
pointers, the consumers of this API should check the the NULL pointers.
Same for efinet_dev_init() using calloc().
Reported by: Robert Mustacchi <rm@joyent.com>
Reviewed by: jhb, allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D9203
The find_currdev() is using variable "copy" to store the reference to trimmed
devpath pointer, if for some reason the efi_devpath_handle() fails, we will
leak this copy.
Also we can simplify the code there a bit.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D9191
With clang 4.0.0, we are getting the following warnings about struct
boot_module_t in efi's boot_module.h:
In file included from sys/boot/efi/boot1/ufs_module.c:41:
sys/boot/efi/boot1/boot_module.h:67:14: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes]
void (*init)();
^
void
sys/boot/efi/boot1/boot_module.h:92:16: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes]
void (*status)();
^
void
sys/boot/efi/boot1/boot_module.h:95:24: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes]
dev_info_t *(*devices)();
^
void
3 errors generated.
Fix this by adding 'void' to the parameter lists. No functional change.
Reviewed by: emaste, imp, smh
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D9144
With clang 4.0.0, the EFI API header causes the following warning:
In file included from sys/boot/efi/loader/bootinfo.c:43:
In file included from sys/boot/efi/loader/../include/efi.h:52:
sys/boot/efi/include/efiapi.h:534:32: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes]
(EFIAPI *EFI_RESERVED_SERVICE) (
^
Add VOID to make it into a real prototype.
Reviewed by: imp, emaste, tsoome
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D9132
clang 3.9.0 without -fPIC generates absolute jump table for
switch/case statement which trips boot1.efi and loader.efi
on ARM platform.
Reviewed by: andrew
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D9108
Fix section pattern code to exclude .rel.data.* sections from being
merged into .data. Otherwise relocations in those sections are lost
in final binary
Reviewed by: andrew
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D9108
__bss_end should not be included in .bss zeroing code. Otherwise first 4
bytes of the section that follows .bss (in loader's case it's .sdata) are
overwritten by zero.
Reviewed by: andrew
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D9108
Apparently the libstand dosfs optimization is a bit too optimistic
and did introduce possible memory corruption.
This patch is backing out the bad part and since this results in
dosfs reading full blocks now, we can also remove extra offset argument
from dv_strategy callback.
The analysis of the issue and the backout patch is provided by Mikhail Kupchik.
PR: 214423
Submitted by: Mikhail Kupchik
Reported by: Mikhail Kupchik
Reviewed by: bapt, allanjude
Approved by: allanjude (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D8644
The Makefile rule to create vers.c for loader version info was
previously duplicated in each of the various loader Makefiles.
Instead, share a common rule in Makefile.inc.
Reviewed by: bapt
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8841
Instead of repeating "%s, Revision %s" "(%s %s)" in each loader, just
create the full version string in vers.c
Reviewed by: bapt
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8823
being a bootstrap tool. However, for reproducible build output,
FreeBSD added dd status=none because it was otherwise difficult to
suppress the status information, but retain any errors that might
happen. There's no real reason that dd has to be a build tool, other
than we use status=none unconditional. Remove dd from a bootstrap tool
entirely by only using status=none when available. This may also help
efforts to build the system on non-FreeBSD hosts as well.
Differential Revision: https://reviews.freebsd.org/D8605
lsdev command does walk over devsw list, prints list element name and
will use dv_print() callback to print the device list.
Unfortunately this approach will add unneeded noise when there are no
particular devices detected.
To remove "empty" device section headers, the dv_print() callback
should print the header instead.
In addition, fixed dv_print callback for md module.
Reviewed by: imp
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D8551
This change does modify devsw dv_print() to return the int value,
enabling walkers to interrupt the walk on non zero value from dv_print().
This will allow the pager_print actually to stop displaying data on
user input, and additionally pager is used in various *dev_print callbacks,
where it was missing.
For test, lsdev [-v] command should display data by screenfuls and should
stop when the key 'q' is pressed on pager prompt.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D5461
lsdev should display detailed information about net devices only with -v
switch. This will make EFI and BIOS version of the loader to have the
same behavior.
Reviewed by: bapt, imp
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D8415
first EFI device if we can't find the one from which the image was loaded.
Reviewed by: allanjude,imp,jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D6780
FICL definitions not in ficl/ficl32 files broke this generally. This
makes that stuff conditional on BOOT_FORTH. Also, move definitions
related to the architecture (FICL_CPUARCH and friends) into
Makefile.ficl that all parts of the tree that include files with ficl
need to include (but only if MK_FORTH == yes). In addition, had to fix
library ordering issue with LIBSTAND to keep it last. Without boot
forth, there's no references to memset to bring in memset.o from
libstand.a to satisfy libgeliboot.a's use of it. Listing libstand last
solves this issue (and it's the proper place for libstand to boot).
* On arm64 we need to use the ${MACHINE_CPUARCH} subdirectory.
* env.c is only needed when using forth so only build it there.
Sponsored by: ABT Systems Ltd
environment variable to allow conditional compilation based on EFI
being present or not. Provide efi-setenv, efi-getenv, and
efi-unsetenv, though those need improvement. Move the efi definition
to libefi (but include a reference so they get included).
etc. can find out where the SMBIOS entry point is located. In pure
UEFI mode the BIOS is not mapped into the standard address space so the
SMBIOS table might not appear between 0xf0000 and 0xfffff. The
UEFI environment can report this the location of the anchor. If it is
reported then expose it as hint.smbios.0.mem. This can then be used
by other tools. However, we should make smbios(4) useful and have it
take this value and provide accesor function so ipmi(4) etc. don't
have to parse and figure things about the SMBIOS table. I have some
simple patches to smbios(4) to expose this address as sysctl and
for ipmi(4) to get the base address. However, the real fix is to
have ipmi(4) ask smbios(4) for what it wants and have smbios(4)
parse it out and return it. This would make smbios(4) useful and reduce
duplicated code. If this address doesn't point to the anchor then
finding SMBIOS info. will fail as if this didn't exist. So there should
be no harm.
With this change and the following hack, dmidecode works on a bunch of
UEFI machines that I tested:
if kenv hint.smbios.0.mem > /dev/null
then
mkdir -p /sys/firmware/efi
mount -t tmpfs -o size=8k tmpfs /sys/firmware/efi
echo "SMBIOS=`kenv hint.smbios.0.mem`" > /sys/firmware/efi/systab
fi
Linux exposes this information via the /sys/firmware/efi/systab file which
dmidecode looks at. We should update dmidecode to do this the FreeBSD
way when we determine what that is!
Reviewed by: jhb
functions to call at the appropriate time to register new forth
words. In the past we've done this with ifdef soup, but now if the
file is included in the build, we'll get the new forth words.
Use this new functionality to move the pci bios stuff out of loader.c
by moving it to biospci.c.
Move the pnp functionality to common/pnp.c.
Move the inb/outb forth words to the i386 sysdep.c file where their
implementation is defined.
Adjust the efi linker scripts and build machinery to cope.
his should be an invisible change to forth scripts and user
experience.
Differential Revision: https://reviews.freebsd.org/D8145
When tsoome@ added skein support to the ZFS boot code and zfsloader, it
resulted in an explosion in code size, running close to a number of
limits.
The default for the C version of skein is to unroll all loops for
skein-256 and 512
Disabling the loop unrolling saves 20-28kb from each binary
boot1.efi
gptzfsboot
loader.efi
userboot.so
zfsloader
Reviewed by: emaste, tsoome
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D7826
1. Size returned for variable name is in bytes, not CHAR16 (the
UEFI standard is unclear on this, where it is clear on the size of
the variable).
2. Dynamically allocate the buffers so we can grow them if someone
defines a super-long variable name.
These two fixes allow me to examine all the variables in my BIOS and
also removes the repeated printing of variables.
files and, in a number of these places, there were problems with how they
were declared.
Some used int return instead of time_t. On some architectures the bit
width of time_t did not naturally fit into an integer and could lead to
some unexpected behavior. (For example, 32-bit ARM builds uses a 64-bit
time_t.)
Make sure the function prototypes always specify void for the argument
list when they do not have any arguemnts, otherwise some compilers can
complain about the prototype.
Reported by: Kevin Zheng
Reviewed by: sjg
Approved by: sjg (mentor)
Obtained from: Juniper Networks, Inc.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D7463
