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
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
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
The boot2 family of bootblocks (zfsboot/gptzfsboot) are using separate
implementation if keyboard reading code, which has deadlock case when
extended key (arrows etc) are pressed.
The problem is about avoiding the noise from some systems, generating
false key events with scan code 1 and ascii code 00, so the code
does attempt to filter such cases out. Unfortunately the extended keys
also set ascii 0, and therefore the pressed key event is ignored and
the keypress is never read, resulting in infinite loop.
This update is moving the check to keyhit() function and is allowing
the rest of the code to process the extended keys.
Reviewed by: bapt, allanjude
Approved by: allanjude (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D8608
(gpt)zfsboot will read one-time boot directives from a special ZFS pool
area. The area was previously described as "Boot Block Header", but
currently it is know as Pad2, marked as reserved and is zeroed out on
pool creation. The new code interprets data in this area, if any, using
the same format as boot.config. The area is immediately wiped out.
Failure to parse the directives results in a reboot right after the
cleanup. Otherwise the boot sequence proceeds as usual.
zfsbootcfg writes zfsboot arguments specified on its command line to the
Pad2 area of a disk identified by vfs.zfs.boot.primary_pool and
vfs.zfs.boot.primary_vdev kenv variables that are set by loader during
boot. Please see the manual page for more.
Thanks to all who reviewed, contributed and made suggestions! There are
many potential improvements to the feature, please see the review for
details.
Reviewed by: wblock (docs)
Discussed with: jhb, tsoome
MFC after: 3 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D7612
The sole purpose of this change is to make sure that sizeof produces
"canonical" sizes for these structures. This is to avoid triggering
bugs in the BIOSes that properly handle only the canonical values of
input length provided to INT 13h AH=48h.
The canonical sizes are: 30 for v2, 66 for v3, etc.
Buggy BIOS code probably looks like:
if (input_length > 30) { /* > v2 */
assume that input length is 66 /* assume v3 or later */
}
This should fix boot problems at least on Supermicro X8DT6 and possibly
on P410i Smart Array Controller (as found in e.g. HP DL360 G7).
Reported by: gnn, np, rstone
Debugged by: rstone
Discussed with: ae, np, rstone
MFC after: 4 days
Place the arguments at a fixed offset of 0x800 withing the argument area
(of size 0x1000). Allow variable size extended arguments first of which
should be a size of the extended arguments (including the size
parameter).
Consolidate all related definitions in a new i386/common/bootargs.h header.
Many thanks to jhb and bde for their guidance and reviews.
Reviewed by: jhb, bde
Approved by: jhb
MFC after: 1 month
and constants related to the BIOS Enhanced Disk Drive Specification.
- Use this header instead of magic numbers and various duplicate structure
definitions for doing I/O.
- Use an actual structure for the request to fetch drive parameters in
drvsize() rather than a gross hack of a char array with some magic
size. While here, change drvsize() to only pass the 1.1 version of
the structure and not request device path information. If we want
device path information you have to set the length of the device
path information as an input (along with probably checking the actual
EDD version to see which size one should use as the device path
information is variable-length). This fixes data smashing problems
from passing an EDD 3 structure to BIOSes supporting EDD 4.
Reviewed by: avg
Tested by: Dennis Koegel dk neveragain.de
MFC after: 1 week
boot2 calls back into boot1 to perform disk reads. The ZFS MBR boot blocks
do not have the same space constraints, so remove this hack for ZFS.
While here, remove commented out code to support C/H/S addressing from
zfsldr. The ZFS and GPT bootstraps always just use EDD LBA addressing.
MFC after: 2 weeks
clean up most layering violations:
sys/boot/i386/common/rbx.h:
RBX_* defines
OPT_SET()
OPT_CHECK()
sys/boot/common/util.[ch]:
memcpy()
memset()
memcmp()
bcpy()
bzero()
bcmp()
strcmp()
strncmp() [new]
strcpy()
strcat()
strchr()
strlen()
printf()
sys/boot/i386/common/cons.[ch]:
ioctrl
putc()
xputc()
putchar()
getc()
xgetc()
keyhit() [now takes number of seconds as an argument]
getstr()
sys/boot/i386/common/drv.[ch]:
struct dsk
drvread()
drvwrite() [new]
drvsize() [new]
sys/boot/common/crc32.[ch] [new]
sys/boot/common/gpt.[ch] [new]
- Teach gptboot and gptzfsboot about new files. I haven't touched the
rest, but there is still a lot of code duplication to be removed.
- Implement full GPT support. Currently we just read primary header and
partition table and don't care about checksums, etc. After this change we
verify checksums of primary header and primary partition table and if
there is a problem we fall back to backup header and backup partition
table.
- Clean up most messages to use prefix of boot program, so in case of an
error we know where the error comes from, eg.:
gptboot: unable to read primary GPT header
- If we can't boot, print boot prompt only once and not every five
seconds.
- Honour newly added GPT attributes:
bootme - this is bootable partition
bootonce - try to boot from this partition only once
bootfailed - we failed to boot from this partition
- Change boot order of gptboot to the following:
1. Try to boot from all the partitions that have both 'bootme'
and 'bootonce' attributes one by one.
2. Try to boot from all the partitions that have only 'bootme'
attribute one by one.
3. If there are no partitions with 'bootme' attribute, boot from
the first UFS partition.
- The 'bootonce' functionality is implemented in the following way:
1. Walk through all the partitions and when 'bootonce'
attribute is found without 'bootme' attribute, remove
'bootonce' attribute and set 'bootfailed' attribute.
'bootonce' attribute alone means that we tried to boot from
this partition, but boot failed after leaving gptboot and
machine was restarted.
2. Find partition with both 'bootme' and 'bootonce' attributes.
3. Remove 'bootme' attribute.
4. Try to execute /boot/loader or /boot/kernel/kernel from that
partition. If succeeded we stop here.
5. If execution failed, remove 'bootonce' and set 'bootfailed'.
6. Go to 2.
If whole boot succeeded there is new /etc/rc.d/gptboot script coming
that will log all partitions that we failed to boot from (the ones with
'bootfailed' attribute) and will remove this attribute. It will also
find partition with 'bootonce' attribute - this is the partition we
booted from successfully. The script will log success and remove the
attribute.
All the GPT updates we do here goes to both primary and backup GPT if
they are valid. We don't touch headers or partition tables when
checksum doesn't match.
Reviewed by: arch (Message-ID: <20100917234542.GE1902@garage.freebsd.pl>)
Obtained from: Wheel Systems Sp. z o.o. http://www.wheelsystems.com
MFC after: 2 weeks
