My change had good intentions, but the implementation was incorrect:
- printf was returning the number of characters in the format string
plus the NUL, but failed in two regards implementation wise:
-- the pathological case, printf(""), wasn't being handled properly since
the pointer is always incremented, so the value returned would be
off-by-one.
-- printf(3) reports the number of characters printed post-conversion via
vfprintf, etc.
- putchar(3) should return the character printed or EOF, not the number
of characters output to the screen.
My goal in making the change (again) was to increase parity, but as bde
pointed out these are freestanding functions, so they don't have to
conform to libc/POSIX. I argued that the functions should be named
differently since the implementation is different enough to warrant it
and to allow boot2 code to be usable when linked against sys/boot and
libstand and other libraries in base. I have no interest in pushing
this change forward more though, as the original concern I had behind
the change with zfsboottest was resolved in r321849 and r321852. The
next person that updates the toolchain gets to deal with the
inconsistency if it's flagged by a newer compiler.
MFC after: 1 month
Reported by: ed, markj
POSIX equivalents
Both printf and putchar return int, not void.
This will allow code that leverages the libcalls and checks/rely on the
return type to interchangeably between loader code and non-loader
code.
MFC after: 1 month
this to be too restrictive. We need to have both broadcast and unicast
enabled for loader to work. Set them in all cases to ensure this is true.
This allows the Cavium ThunderX 2s in the netperf cluster to netboot using
a USB NIC.
PR: 221001
Reviewed by: emaste, tsoome
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D11732
Clang 5.0.0 got better warnings about print format strings using %zd,
and this leads to the following -Werror warning on e.g. arm:
sys/boot/efi/boot1/zfs_module.c:186:18: error: format specifies type 'ssize_t' (aka 'int') but the argument has type 'off_t' (aka 'long long') [-Werror,-Wformat]
"(%lu)\n", st.st_size, spa->spa_name, filepath, EFI_ERROR_CODE(status));
^~~~~~~~~~
Fix this by casting off_t arguments to intmax_t, and using %jd instead.
Reviewed by: tsoome
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D11678
This fixes an integer underflow in efipart_realstrategy, which causes
crashes when an I/O operation's start point is after the end of the disk.
This can happen when trying to detect filesystems on very small disks.
This can occur if a BIOS freebsd-boot partition exists on a system when the
EFI loader is being used.
PR: 219000
Submitted by: Eric McCorkle <eric@metricspace.net>
Reviewed by: cem (previous version), tsoome (previous version)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D10559
By default LLD links with relocations disallowed against readonly
sections (e.g., .text), but the 32-bit ARM EFI & uboot boot bits require
such relocations. -znotext is either ignored as an unknown -z option
(in-tree lld 2.17.50) or is already the default (GNU ld or GNU gold from
ports) so we can just add it unconditionally to allow building with LLD.
This is similar to the change in r320179 for the kernel link.
Sponsored by: The FreeBSD Foundation
The implementation is using fixed size array allocated in asm module,
need to use proper array declaration for C source.
CID: 1376405
Reported by: Coverity, cem
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D11321
The smbios code does a lot of unaligned access, since we don't really
care about smbios info on ARM (not all board expose information and those
who does don't expose useful ones) disable smbios for this arch (at least
for now).
dim@ compared clang IAS-built and GNU as-built boot0 and found them
equivalent. IAS encoded one instruction using two bytes where GNU as
used three, and another instruction using three bytes where GNU as used
two. The net result is equivalent and tested, so there is no need to
force IAS off for boot0.
The EFI memory descriptor 64-bit aligns PhysicalStart on both 32- and
64-bit platforms. Make the padding explicit for i386 EFI.
Submitted by: Siva Mahadevan <smahadevan@freebsdfoundation.org>
MFC after: 3 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D11301
This patch disables outer cache sync in PL310 driver
by adding "arm,io-coherent" property. In addition to
the previous patches it was the last bit needed
for enabling proper operation of Armada 38x SoCs
with the IO cache coherency.
Submitted by: Michal Mazur <mkm@semihalf.com>
Obtained from: Semihalf
Sponsored by: Stormshield
Reviewed by: mmel
Differential revision: https://reviews.freebsd.org/D11204
Since buildenv exports SYSROOT all of these uses will now look in
WORLDTMP by default.
sys/boot/efi/loader/Makefile
A LIBSTAND hack is no longer required for buildenv.
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Implement simple chain loader in loader; this update does add chain command,
taking device or file as argument to load and start new boot loader.
In case of BIOS, the chain will read the boot block to address 0000:7c00 and
jumps on it. In case of UEFI, the chain command is to be used with efi
application, typically stored in EFI System Partition.
The update also does add simple menu entry, if the variable chain_disk is set.
The value of the variable chain_disk is used as argument for chain loading.
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D5992
This commit enables usage of HWPMC interrupts for the
Marvell SoCs, which use MPIC (Armada38x and ArmadaXP).
Those interrupts require extra unmasking, comparing to
others. Also, in order to process counters per-CPU,
they are masked/unmasked using separate registers' sets
for each core.
Submitted by: Michal Mazur <mkm@semihalf.com>
Marcin Wojtas <mw@semihalf.com>
Obtained from: Semihalf
Sponsored by: Stormshield, Netgate
Differential revision: https://reviews.freebsd.org/D10913
This patch adds in-band link management over SGMII of the
SFP transceiver on Armada-388-Clearfog board.
Submitted by: Marcin Wojtas <mw@semihalf.com>
Obtained from: Semihalf
Sponsored by: Netgate
Reviewed by: loos
Differential revision: https://reviews.freebsd.org/D10708
in /boot/defaults/loader.conf to something that's actually commonly used,
"mdroot". It's arbitrary, but it's easier to find this way.
MFC after: 2 weeks
Add pcie-controller node as a bus-parent of pcie nodes for Armada38x
boards. This reduces diff between Linux and FreeBSD PCIe device tree
representation to the minimum. This commit also allows for using multiple
PCIe ports, thanks to the recent driver updates, which support such
hierarchy. Restore original PCIe nodes in armada-385.dtsi and
apply necessary changes in hitherto unused armada-380.dtsi.
Submitted by: Michal Mazur <mkm@semihalf.com>
Marcin Wojtas <mw@semihalf.com>
Obtained from: Semihalf
Sponsored by: Stormshield, Netgate
Differential revision: https://reviews.freebsd.org/D10907
While it sounds like a good idea to extract the RFC1048 data from PXE, in the
end it is not and it is causing lots of issues. Our pxeloader might need
options which are incompatible with other pxe servers (for example iPXE, but
not only).
Our pxe loaders are also now settings their own user class, so it is useful to
issue our own pxe request at startup
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D10953
All the code are now only issueing one single dhcp request at startup of the
loader meaning we can always request a the PXE informations from the
dhcp server.
Previous code lost that information, meaning no option 55 anymore (meaning not
working with the kea dhcp server) and no request for rootpath etc, no user class
Remove the flags from the bootp function which is not needed anymore
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D10952
Rather that previous attempts to add tftpfs support at the same time as NFS
support. This time decide on a proper URI parser rather than hacks.
root-path can now be define the following way:
For tftpfs:
tftp://ip/path
tftp:/path (this one will consider the tftp server is the same as the one where
the pxeboot file was fetched from)
For nfs:
nfs:/path
nfs://ip/path
The historical
ip:/path
/path
are kept on NFS
Reviewed by: tsoom, rgrimes
Differential Revision: https://reviews.freebsd.org/D10947
Please note that only a subset of CPU0 registers are exported. CPU1
registers are not touched.
Obtained from: ARMADA38X Functional Specifications
Sponsored by: Rubicon Communications, LLC (Netgate)
With ip fragment reassembly implemented, it makes sense to allow
larger nfs reads. Note due to loader heap size limit, we do not want
to set too large maximum read size. Also we do not change default read size.
Reviewed by: bcr, allanjude
Differential Revision: https://reviews.freebsd.org/D10754
The current read from network is working from up to down - we have some
protocol needing the data from the network, so we build the buffer space
for that protocol, add the extra space for headers and pass this buffer
down to be filled by nif get call in hope, we have guessed the incoming
packet size right. Amazingly enough this approach mostly does work, but
not always...
So, this update does work from down to up - we allocate buffer (based
on MTU or frame size info), fill it up, and pass on for upper layers.
The obvious problem is that when we should free the buffer - if at all.
In the current implementation the upper layer will free the packet on error
or when the packet is no longer needed.
While working on the issue, the additional issue did pop up - the bios
implementation does not have generic get/put interface but is using pxe
udpsend/udpreceive instead. So the udp calls are gone and undi interface
is implemented instead. Which in turn means slight other changes as we
do not need to have duplicated pxe implementation and can just use dev_net.
To align packet content, the actual read from nic is using shifted buffer by
ETHER_ALIGN (2).
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D10232
Don't use DHCP 150 option to decide which protocol use to netboot. When
root-path includes ip address - go thru NFS, if ip address not exists in
root-path - go thru TFTP from server which ip address is in next-server. But
there is one limitation - only one tftp server in network to provide loader and
everything else. Does enybody use more than only one?
Submitted by: kczekirda
Sponsored by: Oktawave
MFC after: 3 weeks
Relnote: Yes
Differential Revision: https://reviews.freebsd.org/D8740
This code base on lpc code. Ralink RT1310 is oem from 5V Technologies.
RT1310 is ARM926EJS(arm5t).
Tested:
* Buffalo WZR2-G300N
Submitted by: Hiroki Mori <yamori813@yahoo.co.jp>
Reviewed by: mizhka
Differential Revision: https://reviews.freebsd.org/D7238
From user report, the errors are seen:
error 1
error 1
gptzfsboot: error 1 lba 4294967288
gptzfsboot: error 1 lba 1
gptzfsboot: no ZFS pools located, can't boot
The first two errors above are from issuing INT13 EAX=0x4800, meaning we
need to check if EDD is available and use EAX=0x800 if not.
For an workaround I'm using the similar idea as in biosdisk.c - first probe
ah=8h, then check if we have EDD.
Note we would like to see the correct disk size info, but we *may*
get away with anything >64MB, so we could at least test 2 zfs pool labels
on whole disk setup and not to freak out the INT13 interface.
If we get away with initial disk probing, then we have partition sizes from
the partition table and we should be able to complete the disk probing.
Note: this update does not provide full fix to all errors, but we get
the drvsize() errors removed.
Reported by: Michael W. Lucas
Reviewed by: julian
Differential Revision: https://reviews.freebsd.org/D10591
The current reboot command in efi/loader/main.c is passing extra data with
ResetSystem, however, UEFI spec 2.6, page 265 does state:
"ResetData is only valid if ResetStatus is something other than EFI_SUCCESS
unless the ResetType is EfiResetPlatformSpecific where a minimum amount of
ResetData is always required."
Therefore we should use DataSize 0 and ResetData NULL - those are two last
arguments for the call.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D10562
patm(4) devices.
Maintaining an address family and framework has real costs when we make
infrastructure improvements. In the case of NATM we support no devices
manufactured in the last 20 years and some will not even work in modern
motherboards (some newer devices that patm(4) could be updated to
support apparently exist, but we do not currently have support).
With this change, support remains for some netgraph modules that don't
require NATM support code. It is unclear if all these should remain,
though ng_atmllc certainly stands alone.
Note well: FreeBSD 11 supports NATM and will continue to do so until at
least September 30, 2021. Improvements to the code in FreeBSD 11 are
certainly welcome.
Reviewed by: philip
Approved by: harti
As the uboot disk interface is using common/disk.c API, we also
should use disk_ioctl() call, this will give us chance to read partition
sizes and have feature parity with UEFI and BIOS implementations.
This does also fix arm boot issue on some systems, reported/tested by Ian,
thanks.
Reported by: ian
Reviewed by: ian
Differential Revision: https://reviews.freebsd.org/D10421
The work to make it possible to avoid bcache via using F_NORA modifier did
miss the fact that not all loader platforms are using the bcache, and so
it is possible the modifier is not cleared, as bcache strategy function is
not used.
For fix, we make sure the checks are dont with masked flag.
This patch does fix boot for platforms which do not use bcache.
Reported by: emaste
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D10422
The smallest device we can have in the pool is 64MB, since we are trying to
walk all four labels to find the most up to date uberblock, this limit will
also give us good method to check if we even should attempt to probe.
Enforcing the check also will make sure we are not getting wrapped while
calculating the label offset.
Also, after label check, we should verify if we actually got any UB or not.
PR: 218473
Reported by: Masachika ISHIZUKA
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D10381
numbers with Chacha20. Keep the API, though, as that is what the
other *BSD's have done.
Use the boot-time entropy stash (if present) to bootstrap the
in-kernel entropy source.
Reviewed by: delphij,rwatson
Approved by: so(delphij)
MFC after: 2 months
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D10048
The current multiboot loader code doesn't clean the metadata added to the
kernel after the bi_load64 dry run, which breaks accounting of the required
memory for the metadata.
This issue didn't show itself before because all the metadata items where small
(8bytes), but after r316343 there's a big blob in the metadata, which triggers
this. Fix it by cleaning the metadata added to the kernel after the bi_load64
dry run. Also add a comment describing the memory layout when booting using
multiboot (Xen Dom0).
This unbreaks booting a FreeBSD/Xen Dom0 after r316343.
MFC after: 3 weeks
Sponsored by: Citrix Systems R&D
With the zfs probe cleanup, the mistake did slip in the probe code;
instead of reading the pool GUID for the actual boot device (partition),
we read GUID for first found pool from the boot disk.
This will break the case when there are both zfs pool and ufs on the boot
disk, and the ufs is used for boot, not zfs.
Reviewed by: smh
Differential Revision: https://reviews.freebsd.org/D10359
This update does add the code to pass partition size to vdev_probe() via
simple callback. Tested via tinderbox build, but not yet with actual boot.
The code can be improved still, but to verify the idea to read media
block size and amedia size has to be confirmed first.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D10302
The work to implement zfs reader to inspect all pool label copies did
miss the userboot, this update does correct this issue.
Since userboot is already using common/disk.c API (disk_open() etc),
the fix is quite simple - we only need to make sure the userdisk_iocl()
will call disk_ioctl(). In addition, the diskioctl callback does return
int, not pointer.
Note, the review request is actually addressing the sparc and userboot,
but as testing the fix for sparc will take some more time, I am posting the
userboot fix now.
This patch is part of the implementation presented in review:
https://reviews.freebsd.org/D10302
Once we have the sparc part tested, we will have the complete fix
for the issue.
Reviewed by: imp
GNU GCC does does recognise it as a valid option and we already
use -mgeneral-regs-only that has the desired effect.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D10306
The current zfs reader is only checking first label from each device, however,
we do have 4 labels on device and we should check all 4 to be protected
against disk failures and incomplete label updates.
The difficulty is about the fact that 2 label copies are in front of the
pool data, and 2 are at the end, which means, we have to know the size of
the pool data area.
Since we have now the mechanism from common/disk.c to use the partition
information, it does help us in this task; however, there are still some
corner cases.
Namely, if the pool is created without partition, directly on the disk,
and firmware will give us the wrong size for the disk, we only can check
the first two label copies.
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D10203
While we have mechanisms in place to protect ourselves against the read
behind the disk end, there is still one corner case. As the GPT
partition table has backup table at the end of the disk, and we yet
do not know the size of the disk (if the wrong size is provided by the
firmware/bios), we need to limit the reads to avoid read ahead in such case.
Note: this update does add constant into stand.h, so the incremental build
will need to get local stand.h updated first.
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D10187
The description tells it all, as an side note, I am using uint8_t instead of
u_char as the partition table data really is handled as byte stream, not
char array.
Reviewed by: allanjude, imp
Differential Revision: https://reviews.freebsd.org/D10180
passed in from u-boot across the call to self_reloc and any other early-init
code, and restore them before calling main().
The self_reloc() routine uses r0 and r1 (and calling it uses lr), and
depending on what values get left in them, main() would intermittantly lock
up trying to interpret them as argc and argv values. This problem affected
the self-relocatable ubldr.bin but not ubldr (the elf version).
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
This is a minimal attempt to keep consistency in the Makefiles so that
moving ficl to somwehere like contrib will be less error prone.
MFC after: 1 week
Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96
When we was compering it to code from boot2 it also looks like
this code is buggy and boot2 was never updated to use this code.
USE_XREAD flag is unused in boot2, and common/drv.c was never
build with that flag.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D9780
pwgets() is based on ngets() from libstand, which includes a feature
that is not wanted in a very of the function designed for password
handling.
Pressing control+r echos out the entered string
This commit removes that feature from pwgets()
PR: 217298
Reported by: ehaupt
Reviewed by: kristof, tsoome, ehaupt
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D9782
As the current zfs file system is providing symlink via system attributes, need
to update the code accordingly.
Note, as the zfsboot code does not free the memory at this time, the
object list will put some stress on the boot2 heap, eventually we should
address the issue.
Reviewed by: allanjude, smh
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D9706
The PBKDF2 in sys/geom/eli/pkcs5v2.c is around half the speed it could be
GELI's PBKDF2 uses a simple benchmark to determine a number of iterations
that will takes approximately 2 seconds. The security provided is actually
half what is expected, because an attacker could use the optimized
algorithm to brute force the key in half the expected time.
With this change, all newly generated GELI keys will be approximately 2x
as strong. Previously generated keys will talk half as long to calculate,
resulting in faster mounting of encrypted volumes. Users may choose to
rekey, to generate a new key with the larger default number of iterations
using the geli(8) setkey command.
Security of existing data is not compromised, as ~1 second per brute force
attempt is still a very high threshold.
PR: 202365
Original Research: https://jbp.io/2015/08/11/pbkdf2-performance-matters/
Submitted by: Joe Pixton <jpixton@gmail.com> (Original Version), jmg (Later Version)
Reviewed by: ed, pjd, delphij
Approved by: secteam, pjd (maintainer)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D8236
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
From NetBSD christos Sat Jan 26 00:19:39 2013 +0000
make the buffer functions look exactly like the kernel ones and add other
cruft to make the kernel files compile.
ffs.c 1.54
ffs/buf.c 1.13
ffs/buf.h 1.3
ffs/ffs_alloc.c 1.21
ffs/ffs_balloc.c 1.15
Reviewed by: marcel, ngie
Obtained from: NetBSD
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8404
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
The alloca() does give us pointer and we have no practical way to check if the
area is actually available, resulting in corruption in corner cases.
Unfortunately we do not have too many options right now, but to use one page.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D9455
This fix is implementing partition based boundary check for
disk IO and updates disk mediasize (if needed), based on information
from partition table.
As it appeared, the signed int based approach still has corner cases,
and the wrapover based behavior is non-standard.
The idea for this fix is based on two assumptions:
The bug about media size is hitting large (2+TB) disks, lesser disks
hopefully, are not affected.
Large disks are using GPT (which does include information about disk size).
Since our concern is about boot support and boot disks are partitioned,
implementing partition boundaries based IO verification should make the
media size issues mostly disappear.
However, for large disk case, we do have the disk size available from GPT table.
If non-GPT cases will appear, we still can make approximate calculation about
disk size based on defined partition(s), however, this is not the objective
of this patch, and can be added later if there is any need.
This patch does implement disk media size adjustment (if needed) in bd_open(),
and boundary check in bd_realstrategy().
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D8595
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 loader bcache is implementing simple read-ahead to boost the cache.
The bcache is built based on 512B block sizes, and the read ahead is attempting
to read number of cache blocks, based on amount of the free bcache space.
However, there are devices using larger sector sizes than 512B, most obviously
the CD media is based on 2k sectors. This means the read-ahead can not be just
random number of blocks, but we should use value suitable also for use with
larger sectors, as for example, with CD devices, we should read multiple of 2KB.
Since the sector size from disk interface is not too reliable, i guess we can
just use "good enough" value, so the implementation is rounding down the read
ahead block count to be multiple of 16.
This means we have covered sector sizes to 8k.
In addition, the update does implement the end of cache marker, to help to
detect the possible memory corruption - I have not seen it happening so far,
but it does not hurt to have the detection mechanism in place.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D9179
Need interface to extract information about disk abstraction,
to read disk or partition size depending on the provided argument
and adjust disk size based on information in partition table.
The disk handle from disk_open() has d_offset field to point to
partition start. So we can use this fact to return either whole disk
size or partition size. For this we only need to record partition size
we get from disk_open() anyhow.
In addition, this will also make it possible to adjust the disk media size
based on information from partition table. The problem with disk size is
about some BIOS systems reporting bogus disk size for 2+TB disks, but
since such disks are using GPT partitioning, and GPT does have information
about disk size (alternate LBA + 1), we can use this fact to record disk
size based on partition table.
This patch does exactly this: implements DIOCGSECTORSIZE and DIOCGMEDIASIZE
ioctl, and DIOCGMEDIASIZE will report either disk media size or partition size.
Adds ptable_getsize() call to read partition size in bytes from ptable pointer.
Updates disk_open() to use ptable_getsize() to update mediasize value.
Implements GPT detection function to update ptable size (used by
ptable_getsize()) according to alternate lba (which is location of backup copy
of GPT header table).
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D8594
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
The disk_* and part_* api is using 64bit values for media size and
offsets. However, the current api is using off_t type, which is signed
64-bit int.
In this context the signed media size does not make any sense, and
the offsets are used to mark absolute, not relative locations.
Also, the data from GPT partition table and some other sources is
already using uint64_t data type, so using signed off_t can cause sign
issues.
Reviewed by: imp
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D8710
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
-G0 is sufficent except on old version of clang (<3.8) and such versions
are unlikely to be generally useful on mips64.
Reported by: sbruno
Sponsored by: DARPA, AFRL
Remove custom DTS duplicate of tda19988 node and use upstream-provided
one introduced by r295436. This duplication created two tdaX devices
which confused fb driver into using only 640x480 area while setting
display to native resolution.
Reported by: Michael Smith
MFC after: 3 days
