main/vaseboot
main
/
vaseboot
1
0
Fork 0
Code Issues Pull Requests 1 Packages Projects Releases Wiki Activity
vaseboot/docs/VasEBoot.info-2

5051 lines
213 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This is VasEBoot.info, produced by makeinfo version 6.8 from VasEBoot.texi.
This manual is for GNU VAS_EBOOT (version 2.14, 8 January 2026).
Copyright (C)
1999,2000,2001,2002,2004,2006,2008,2009,2010,2011,2012,2013 Free
Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software
Foundation; with no Invariant Sections.
INFO-DIR-SECTION Kernel
START-INFO-DIR-ENTRY
* VAS_EBOOT: (VasEBoot). The GRand Unified Bootloader
* VasEBoot-install: (VasEBoot)Invoking VasEBoot-install. Install VAS_EBOOT on your drive
* VasEBoot-mkconfig: (VasEBoot)Invoking VasEBoot-mkconfig. Generate VAS_EBOOT configuration
* VasEBoot-mkpasswd-pbkdf2: (VasEBoot)Invoking VasEBoot-mkpasswd-pbkdf2.
* VasEBoot-mkrelpath: (VasEBoot)Invoking VasEBoot-mkrelpath.
* VasEBoot-mkrescue: (VasEBoot)Invoking VasEBoot-mkrescue. Make a VAS_EBOOT rescue image
* VasEBoot-mount: (VasEBoot)Invoking VasEBoot-mount. Mount a file system using VAS_EBOOT
* VasEBoot-probe: (VasEBoot)Invoking VasEBoot-probe. Probe device information
* VasEBoot-script-check: (VasEBoot)Invoking VasEBoot-script-check.
END-INFO-DIR-ENTRY

File: VasEBoot.info, Node: blocklist, Next: blscfg, Prev: badram, Up: Command-line commands
17.4.14 blocklist
-----------------
-- Command: blocklist file
Print a block list (*note Block list syntax::) for FILE.

File: VasEBoot.info, Node: blscfg, Next: boot, Prev: blocklist, Up: Command-line commands
17.4.15 blscfg
--------------
-- Command: blscfg [-p|--path dir] [-f|--enable-fallback]
[-d|--show-default] [-n|--show-non-default] [-e|--entry file]
Load Boot Loader Specification (BLS) entries into the VAS_EBOOT menu.
Boot entries generated from 'blscfg' won't interfere with entries
from 'VasEBoot.cfg' appearing in the VAS_EBOOT menu. Also, entries
generated from 'blscfg' exists only in memory and don't update
'VasEBoot.cfg'.
By default, the BLS entries are stored in the '/loader/entries'
directory in the boot partition. If BLS entries are stored
elsewhere, the '--path' option can be used to check a different
directory instead of the default location. If no BLS entries are
found while using the '--path' option, the '--enable-fallback'
option can be used to check for entries in the default location.
The '--show-default' option allows the default boot entry to be
added to the VAS_EBOOT menu from the BLS entries.
The '--show-non-default' option allows non-default boot entries to
be added to the VAS_EBOOT menu from the BLS entries.
The '--entry' option allows specific boot entries to be added to
the VAS_EBOOT menu from the BLS entries.
The '--entry', '--show-default', and '--show-non-default' options
are used to filter which BLS entries are added to the VAS_EBOOT menu.
If none are used, all entries in the default location or the
location specified by '--path' will be added to the VAS_EBOOT menu.
A BLS config file example:
# /boot/loader/entries/6a9857a393724b7a981ebb5b8495b9ea-3.8.0-2.fc19.x86_64.conf
title Fedora 19 (Rawhide)
sort-key fedora
machine-id 6a9857a393724b7a981ebb5b8495b9ea
version 3.8.0-2.fc19.x86_64
options root=UUID=6d3376e4-fc93-4509-95ec-a21d68011da2 quiet
architecture x64
linux /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/linux
initrd /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/initrd
For more information on BLS entry keys as well as other information
on BLS, see: The Boot Loader Specification
(https://uapi-group.org/specifications/specs/boot_loader_specification/).
For the VAS_EBOOT, there are a few additional BLS entry keys based on
the 'menuentry' command (*note menuentry::).
The 'VasEBoot_class' key may be used any number of times to group menu
entries into classes. Menu themes may display different classes
using different styles.
The 'VasEBoot_users' key grants specific users access to specific menu
entries. *Note Security::.
The 'VasEBoot_hotkey' key associates a hotkey with a menu entry. KEY
may be a single letter, or one of the aliases 'backspace', 'tab',
or 'delete'.
The 'VasEBoot_args' key can be used for any other argument to be passed
as positonal parameters when the list of commands generated from
the BLS config file are executed.
Variable expansion using the '$' character (*Note Shell-like
scripting::) may be used with BLS config files for the VAS_EBOOT but
might not be compatible with other bootloaders.

File: VasEBoot.info, Node: boot, Next: cat, Prev: blscfg, Up: Command-line commands
17.4.16 boot
------------
-- Command: boot
Boot the OS or chain-loader which has been loaded. Only necessary
if running the fully interactive command-line (it is implicit at
the end of a menu entry).

File: VasEBoot.info, Node: cat, Next: clear, Prev: boot, Up: Command-line commands
17.4.17 cat
-----------
-- Command: cat [--dos] file
Display the contents of the file FILE. This command may be useful
to remind you of your OS's root partition:
VasEBoot> cat /etc/fstab
If the '--dos' option is used, then carriage return / new line
pairs will be displayed as a simple new line. Otherwise, the
carriage return will be displayed as a control character ('<d>') to
make it easier to see when boot problems are caused by a file
formatted using DOS-style line endings.
Note: 'cat' can be used to view the contents of devices using the
block list syntax (*note Block list syntax::). However, it is not
advised to view binary data because it will try to decode UTF-8
strings, which can lead to some bytes missing or added in the
output. Instead, use the 'hexdump' command (*note hexdump::).

File: VasEBoot.info, Node: clear, Next: cmosclean, Prev: cat, Up: Command-line commands
17.4.18 clear
-------------
-- Command: clear
Clear the screen.

File: VasEBoot.info, Node: cmosclean, Next: cmosdump, Prev: clear, Up: Command-line commands
17.4.19 cmosclean
-----------------
-- Command: cmosclean byte:bit
Clear value of bit in CMOS at location BYTE:BIT. This command is
available only on platforms that support CMOS.

File: VasEBoot.info, Node: cmosdump, Next: cmostest, Prev: cmosclean, Up: Command-line commands
17.4.20 cmosdump
----------------
-- Dump: CMOS contents
Dump full CMOS contents as hexadecimal values. This command is
available only on platforms that support CMOS.

File: VasEBoot.info, Node: cmostest, Next: cmp, Prev: cmosdump, Up: Command-line commands
17.4.21 cmostest
----------------
-- Command: cmostest byte:bit
Test value of bit in CMOS at location BYTE:BIT. Exit status is
zero if bit is set, non zero otherwise. This command is available
only on platforms that support CMOS.

File: VasEBoot.info, Node: cmp, Next: configfile, Prev: cmostest, Up: Command-line commands
17.4.22 cmp
-----------
-- Command: cmp [-v] file1 file2
Compare the file FILE1 with the file FILE2. If they are completely
identical, '$?' will be set to 0. Otherwise, if the files are not
identical, '$?' will be set to a nonzero value.
By default nothing will be output. If the '-v' is used, verbose
mode is enabled. In this mode when when the files differ in size,
print the sizes like this:
Differ in size: 0x1234 [foo], 0x4321 [bar]
If the sizes are equal but the bytes at an offset differ, then
print the bytes like this:
Differ at the offset 777: 0xbe [foo], 0xef [bar]

File: VasEBoot.info, Node: configfile, Next: cpuid, Prev: cmp, Up: Command-line commands
17.4.23 configfile
------------------
-- Command: configfile file
Load FILE as a configuration file. If FILE defines any menu
entries, then show a menu containing them immediately. Any
environment variable changes made by the commands in FILE will not
be preserved after 'configfile' returns.

File: VasEBoot.info, Node: cpuid, Next: crc, Prev: configfile, Up: Command-line commands
17.4.24 cpuid
-------------
-- Command: cpuid [-l] [-p]
Check for CPU features. This command is only available on x86
systems.
With the '-l' option, return true if the CPU supports long mode
(64-bit).
With the '-p' option, return true if the CPU supports Physical
Address Extension (PAE).
If invoked without options, this command currently behaves as if it
had been invoked with '-l'. This may change in the future.

File: VasEBoot.info, Node: crc, Next: cryptocheck, Prev: cpuid, Up: Command-line commands
17.4.25 crc
-----------
-- Command: crc arg ...
Alias for 'hashsum --hash crc32 arg ...'. See command 'hashsum'
(*note hashsum::) for full description.

File: VasEBoot.info, Node: cryptocheck, Next: cryptomount, Prev: crc, Up: Command-line commands
17.4.26 cryptocheck
-------------------
-- Command: cryptocheck [ --quiet ] device
Check if a given diskfilter device is backed by encrypted devices
(*note cryptomount:: for additional information).
The command examines all backing devices, physical volumes, of a
specified logical volume, like LVM2, and fails when at least one of
them is unencrypted.
The option '--quiet' can be given to suppress the output.

File: VasEBoot.info, Node: cryptomount, Next: cutmem, Prev: cryptocheck, Up: Command-line commands
17.4.27 cryptomount
-------------------
-- Command: cryptomount [ [-p password] | [-k keyfile [-O keyoffset]
[-S keysize] ] | [-P protector] | [-A] ] [-H file] device|-u
uuid|-a|-b
Setup access to encrypted device. A passphrase will be requested
interactively, if neither the '-p' nor '-k' options are given. The
option '-p' can be used to supply a passphrase (useful for
scripts). Alternatively the '-k' option can be used to supply a
keyfile with options '-O' and '-S' optionally supplying the offset
and size, respectively, of the key data in the given key file.
Besides the keyfile, the key can be stored in a key protector, and
option '-P' configures specific key protector, e.g. tpm2, to
retrieve the key from. The option '-A' enables hardware
acceleration in libgcrypt to speed up decryption. The '-H' options
can be used to supply cryptomount backends with an alternative
header file (aka detached header). Not all backends have headers
nor support alternative header files (currently only LUKS1 and
LUKS2 support them). Argument DEVICE configures specific VasEBoot
device (*note Naming convention::); option '-u' UUID configures
device with specified UUID; option '-a' configures all detected
encrypted devices; option '-b' configures all geli containers that
have boot flag set.
Devices are not allowed to be given as key files nor as detached
header files. However, this limitation can be worked around by
using blocklist syntax. So for instance, '(hd1,gpt2)' can not be
used, but '(hd1,gpt2)0+' will achieve the desired result.
VAS_EBOOT supports devices encrypted using LUKS, LUKS2 and geli. Note
that necessary modules (LUKS, LUKS2 and GELI) have to be loaded
manually before this command can be used. For LUKS2 only the
PBKDF2 key derivation function is supported, as Argon2 is not yet
supported.
Successfully decrypted disks are named as (cryptoX) and have
increasing numeration suffix for each new decrypted disk. If the
encrypted disk hosts some higher level of abstraction (like LVM2 or
MDRAID) it will be created under a separate device namespace in
addition to the cryptodisk namespace.
Support for plain encryption mode (plain dm-crypt) is provided via
separate '*note plainmount::' command.
On the EFI platform, VAS_EBOOT tries to erase master keys from memory
when the cryptodisk module is unloaded or the command 'exit' is
executed. All secrets remain in memory when the command
'chainloader' is issued, because execution can return to VAS_EBOOT on
the EFI platform.

File: VasEBoot.info, Node: cutmem, Next: date, Prev: cryptomount, Up: Command-line commands
17.4.28 cutmem
--------------
-- Command: cutmem from[K|M|G] to[K|M|G]
Remove any memory regions in specified range.
This command notifies the memory manager that specified regions of
RAM ought to be filtered out. This remains in effect after a
payload kernel has been loaded by VAS_EBOOT, as long as the loaded
kernel obtains its memory map from VAS_EBOOT. Kernels that support this
include Linux, GNU Mach, the kernel of FreeBSD and Multiboot
kernels in general.
The command is similar to 'badram' command.
Note: The command is not allowed when lockdown is enforced (*note
Lockdown::). This prevents removing EFI memory regions to
potentially subvert the security mechanisms provided by the UEFI
secure boot.

File: VasEBoot.info, Node: date, Next: devicetree, Prev: cutmem, Up: Command-line commands
17.4.29 date
------------
-- Command: date [[year-]month-day] [hour:minute[:second]]
With no arguments, print the current date and time.
Otherwise, take the current date and time, change any elements
specified as arguments, and set the result as the new date and
time. For example, 'date 01-01' will set the current month and day
to January 1, but leave the year, hour, minute, and second
unchanged.

File: VasEBoot.info, Node: devicetree, Next: distrust, Prev: date, Up: Command-line commands
17.4.30 devicetree
------------------
-- Command: devicetree file
Load a device tree blob (.dtb) from a filesystem, for later use by
a Linux kernel. Does not perform merging with any device tree
supplied by firmware, but rather replaces it completely.
Note: The command is not allowed when lockdown is enforced (*note
Lockdown::). This is done to prevent subverting various security
mechanisms.

File: VasEBoot.info, Node: distrust, Next: drivemap, Prev: devicetree, Up: Command-line commands
17.4.31 distrust
----------------
-- Command: distrust pubkey_id
Remove public key PUBKEY_ID from VAS_EBOOT's keyring of trusted keys.
PUBKEY_ID is the last four bytes (eight hexadecimal digits) of the
GPG v4 key id, which is also the output of 'list_trusted' (*note
list_trusted::). Outside of VAS_EBOOT, the key id can be obtained using
'gpg --fingerprint'). These keys are used to validate signatures
when environment variable 'check_signatures' is set to 'enforce'
(*note check_signatures::), and by some invocations of
'verify_detached' (*note verify_detached::). *Note Using GPG-style
digital signatures::, for more information.

File: VasEBoot.info, Node: drivemap, Next: echo, Prev: distrust, Up: Command-line commands
17.4.32 drivemap
----------------
-- Command: drivemap -l|-r|[-s] from_drive to_drive
Without options, map the drive FROM_DRIVE to the drive TO_DRIVE.
This is necessary when you chain-load some operating systems, such
as DOS, if such an OS resides at a non-first drive. For
convenience, any partition suffix on the drive is ignored, so you
can safely use ${root} as a drive specification.
With the '-s' option, perform the reverse mapping as well, swapping
the two drives.
With the '-l' option, list the current mappings.
With the '-r' option, reset all mappings to the default values.
For example:
drivemap -s (hd0) (hd1)
NOTE: Only available on i386-pc.

File: VasEBoot.info, Node: echo, Next: efitextmode, Prev: drivemap, Up: Command-line commands
17.4.33 echo
------------
-- Command: echo [-n] [-e] string ...
Display the requested text and, unless the '-n' option is used, a
trailing new line. If there is more than one string, they are
separated by spaces in the output. As usual in VAS_EBOOT commands,
variables may be substituted using '${var}'.
The '-e' option enables interpretation of backslash escapes. The
following sequences are recognised:
'\\'
backslash
'\a'
alert (BEL)
'\c'
suppress trailing new line
'\f'
form feed
'\n'
new line
'\r'
carriage return
'\t'
horizontal tab
'\v'
vertical tab
When interpreting backslash escapes, backslash followed by any
other character will print that character.

File: VasEBoot.info, Node: efitextmode, Next: eval, Prev: echo, Up: Command-line commands
17.4.34 efitextmode
-------------------
-- Command: efitextmode [min | max | <mode_num> | <cols> <rows>]
When used with no arguments displays all available text output
modes. The set mode determines the columns and rows of the text
display when in text mode. An asterisk, '*', will be at the end of
the line of the currently set mode.
If given a single parameter, it must be 'min', 'max', or a mode
number given by the listing when run with no arguments. These
arguments set the mode to the minimum, maximum, and particular mode
respectively.
Otherwise, the command must be given two numerical arguments
specifying the columns and rows of the desired mode. Specifying a
columns and rows combination that corresponds to no supported mode,
will return error, but otherwise have no effect.
By default VAS_EBOOT will start in whatever mode the EFI firmware
defaults to. There are firmwares known to set up the default mode
such that output behaves strangely, for example the cursor in the
VAS_EBOOT shell never reaches the bottom of the screen or, when typing
characters at the prompt, characters from previous command output
are overwritten. Setting the mode may fix this.
The EFI specification says that mode 0 must be available and have
columns and rows of 80 and 25 respectively. Mode 1 may be defined
and if so must have columns and rows of 80 and 50 respectively.
Any other modes may have columns and rows arbitrarily defined by
the firmware. This means that a mode with columns and rows of 100
and 31 on one firmware may be a different mode number on a
different firmware or not exist at all. Likewise, mode number 2 on
one firmware may have a different number of columns and rows than
mode 2 on a different firmware. So one should not rely on a
particular mode number or a mode of a certain number of columns and
rows existing on all firmwares, except for mode 0.
Note: This command is only available on EFI platforms and is
similar to EFI shell "mode" command.

File: VasEBoot.info, Node: eval, Next: export, Prev: efitextmode, Up: Command-line commands
17.4.35 eval
------------
-- Command: eval string ...
Concatenate arguments together using single space as separator and
evaluate result as sequence of VAS_EBOOT commands.

File: VasEBoot.info, Node: export, Next: false, Prev: eval, Up: Command-line commands
17.4.36 export
--------------
-- Command: export envvar
Export the environment variable ENVVAR. Exported variables are
visible to subsidiary configuration files loaded using
'configfile'.

File: VasEBoot.info, Node: false, Next: fdtdump, Prev: export, Up: Command-line commands
17.4.37 false
-------------
-- Command: false
Do nothing, unsuccessfully. This is mainly useful in control
constructs such as 'if' and 'while' (*note Shell-like scripting::).

File: VasEBoot.info, Node: fdtdump, Next: file, Prev: false, Up: Command-line commands
17.4.38 fdtdump
---------------
-- Command: fdtdump [--prop PROP] [--set VARIABLE]
Retrieve device tree information.
The 'fdtdump' command returns the value of a property in the device
tree provided by the firmware. The '--prop' option determines
which property to select.
The default action is to print the value of the requested field to
the console, but a variable name can be specified with '--set' to
store the value instead of printing it.
For example, this will store and then display the model string.
fdtdump --prop model --set machine_model
echo $machine_model

File: VasEBoot.info, Node: file, Next: fwsetup, Prev: fdtdump, Up: Command-line commands
17.4.39 file
------------
-- Command: file is_file_type filename
The 'file' command tests whether the provided FILENAME is the type
provided by IS_FILE_TYPE. When the 'file' is of type IS_FILE_TYPE
this command will return 0, otherwise it will return non-zero (no
output is provided to the terminal).
IS_FILE_TYPE may be one of the following options:
* '--is-i386-xen-pae-domu' Check if FILENAME can be booted as
i386 PAE Xen unprivileged guest kernel
* '--is-x86_64-xen-domu' Check if FILENAME can be booted as
x86_64 Xen unprivileged guest kernel
* '--is-x86-xen-dom0' Check if FILENAME can be used as Xen x86
privileged guest kernel
* '--is-x86-multiboot' Check if FILENAME can be used as x86
multiboot kernel
* '--is-x86-multiboot2' Check if FILENAME can be used as x86
multiboot2 kernel
* '--is-arm-linux' Check if FILENAME is ARM Linux
* '--is-arm64-linux' Check if FILENAME is ARM64 Linux
* '--is-ia64-linux' Check if FILENAME is IA64 Linux
* '--is-mips-linux' Check if FILENAME is MIPS Linux
* '--is-mipsel-linux' Check if FILENAME is MIPSEL Linux
* '--is-sparc64-linux' Check if FILENAME is SPARC64 Linux
* '--is-powerpc-linux' Check if FILENAME is POWERPC Linux
* '--is-x86-linux' Check if FILENAME is x86 Linux
* '--is-x86-linux32' Check if FILENAME is x86 Linux supporting
32-bit protocol
* '--is-x86-kfreebsd' Check if FILENAME is x86 kFreeBSD
* '--is-i386-kfreebsd' Check if FILENAME is i386 kFreeBSD
* '--is-x86_64-kfreebsd' Check if FILENAME is x86_64 kFreeBSD
* '--is-x86-knetbsd' Check if FILENAME is x86 kNetBSD
* '--is-i386-knetbsd' Check if FILENAME is i386 kNetBSD
* '--is-x86_64-knetbsd' Check if FILENAME is x86_64 kNetBSD
* '--is-i386-efi' Check if FILENAME is i386 EFI file
* '--is-x86_64-efi' Check if FILENAME is x86_64 EFI file
* '--is-ia64-efi' Check if FILENAME is IA64 EFI file
* '--is-arm64-efi' Check if FILENAME is ARM64 EFI file
* '--is-arm-efi' Check if FILENAME is ARM EFI file
* '--is-riscv32-efi' Check if FILENAME is RISC-V 32bit EFI file
* '--is-riscv64-efi' Check if FILENAME is RISC-V 64bit EFI file
* '--is-hibernated-hiberfil' Check if FILENAME is hiberfil.sys
in hibernated state
* '--is-x86_64-xnu' Check if FILENAME is x86_64 XNU (Mac OS X
kernel)
* '--is-i386-xnu' Check if FILENAME is i386 XNU (Mac OS X
kernel)
* '--is-xnu-hibr' Check if FILENAME is XNU (Mac OS X kernel)
hibernated image
* '--is-x86-bios-bootsector' Check if FILENAME is BIOS
bootsector

File: VasEBoot.info, Node: fwsetup, Next: gdbinfo, Prev: file, Up: Command-line commands
17.4.40 fwsetup
---------------
-- Command: fwsetup [--is-supported]
Reboot into the firmware setup menu. If '--is-supported' option is
specified, instead check whether the firmware supports a setup menu
and exit successfully if so.

File: VasEBoot.info, Node: gdbinfo, Next: gettext, Prev: fwsetup, Up: Command-line commands
17.4.41 gdbinfo
---------------
-- Command: gdbinfo
Output text to be used as a GDB command for a GDB session using the
gdb_VasEBoot script and attached to a running VAS_EBOOT instance. The GDB
command that is output will tell GDB how to load debugging symbols
to their proper runtime address. Currently this is only available
for EFI platforms. See the Debugging in the developer
documentation for more information.

File: VasEBoot.info, Node: gettext, Next: gptsync, Prev: gdbinfo, Up: Command-line commands
17.4.42 gettext
---------------
-- Command: gettext string
Translate STRING into the current language.
The current language code is stored in the 'lang' variable in
VAS_EBOOT's environment (*note lang::). Translation files in MO format
are read from 'locale_dir' (*note locale_dir::), usually
'/boot/VasEBoot/locale'.

File: VasEBoot.info, Node: gptsync, Next: halt, Prev: gettext, Up: Command-line commands
17.4.43 gptsync
---------------
-- Command: gptsync device [partition[+/-[type]]] ...
Disks using the GUID Partition Table (GPT) also have a legacy
Master Boot Record (MBR) partition table for compatibility with the
BIOS and with older operating systems. The legacy MBR can only
represent a limited subset of GPT partition entries.
This command populates the legacy MBR with the specified PARTITION
entries on DEVICE. Up to three partitions may be used.
TYPE is an MBR partition type code; prefix with '0x' if you want to
enter this in hexadecimal. The separator between PARTITION and
TYPE may be '+' to make the partition active, or '-' to make it
inactive; only one partition may be active. If both the separator
and type are omitted, then the partition will be inactive.

File: VasEBoot.info, Node: halt, Next: hashsum, Prev: gptsync, Up: Command-line commands
17.4.44 halt
------------
-- Command: halt [--no-apm]
The command halts the computer. On the i386-pc target, the
'--no-apm' option, or short '-n', is specified, no APM BIOS call is
performed. Otherwise, the computer is shut down using APM on that
target.

File: VasEBoot.info, Node: hashsum, Next: help, Prev: halt, Up: Command-line commands
17.4.45 hashsum
---------------
-- Command: hashsum --hash hash --keep-going --uncompress --check file
[--prefix dir]|file ...
Compute or verify file hashes. Hash type is selected with option
'--hash'. Supported hashes are: 'adler32', 'crc64', 'crc32',
'crc32rfc1510', 'crc24rfc2440', 'md4', 'md5', 'ripemd160', 'sha1',
'sha224', 'sha256', 'sha512', 'sha384', 'tiger192', 'tiger',
'tiger2', 'whirlpool'. Option '--uncompress' uncompresses files
before computing hash.
When list of files is given, hash of each file is computed and
printed, followed by file name, each file on a new line.
When option '--check' is given, it points to a file that contains
list of HASH NAME pairs in the same format as used by UNIX 'md5sum'
command. Option '--prefix' may be used to give directory where
files are located. Hash verification stops after the first
mismatch was found unless option '--keep-going' was given. The
exit code '$?' is set to 0 if hash verification is successful. If
it fails, '$?' is set to a nonzero value.

File: VasEBoot.info, Node: help, Next: hexdump, Prev: hashsum, Up: Command-line commands
17.4.46 help
------------
-- Command: help [pattern ...]
Display helpful information about builtin commands. If you do not
specify PATTERN, this command shows short descriptions of all
available commands.
If you specify any PATTERNS, it displays longer information about
each of the commands whose names begin with those PATTERNS.

File: VasEBoot.info, Node: hexdump, Next: insmod, Prev: help, Up: Command-line commands
17.4.47 hexdump
---------------
-- Command: hexdump [--skip offset] [--length len] FILE_OR_DEVICE
Show raw contents of a file or memory. When option '--skip' is
given, 'offset' number of bytes are skipped from the start of the
device or file given. And '--length' allows specifying a maximum
number of bytes to be shown.
If given the special device named '(mem)', then the 'offset' given
to '--skip' is treated as the address of a memory location to dump
from.
Note: The dumping of RAM memory (by the (mem) argument) is not
allowed when when lockdown is enforced (*note Lockdown::). The
dumping of disk or file data is allowed when lockdown is enforced.

File: VasEBoot.info, Node: insmod, Next: keystatus, Prev: hexdump, Up: Command-line commands
17.4.48 insmod
--------------
-- Command: insmod module
Insert the dynamic VAS_EBOOT module called MODULE.

File: VasEBoot.info, Node: keystatus, Next: list_env, Prev: insmod, Up: Command-line commands
17.4.49 keystatus
-----------------
-- Command: keystatus [--shift] [--ctrl] [--alt]
Return true if the Shift, Control, or Alt modifier keys are held
down, as requested by options. This is useful in scripting, to
allow some user control over behaviour without having to wait for a
keypress.
Checking key modifier status is only supported on some platforms.
If invoked without any options, the 'keystatus' command returns
true if and only if checking key modifier status is supported.

File: VasEBoot.info, Node: list_env, Next: list_trusted, Prev: keystatus, Up: Command-line commands
17.4.50 list_env
----------------
-- Command: list_env [--file file]
List all variables in the environment block file. *Note
Environment block::.
The '--file' option overrides the default location of the
environment block.

File: VasEBoot.info, Node: list_trusted, Next: load_env, Prev: list_env, Up: Command-line commands
17.4.51 list_trusted
--------------------
-- Command: list_trusted
List all public keys trusted by VAS_EBOOT for validating signatures.
The output is in GPG's v4 key fingerprint format (i.e., the output
of 'gpg --fingerprint'). The least significant four bytes (last
eight hexadecimal digits) can be used as an argument to 'distrust'
(*note distrust::). *Note Using GPG-style digital signatures::,
for more information about uses for these keys.

File: VasEBoot.info, Node: load_env, Next: loadfont, Prev: list_trusted, Up: Command-line commands
17.4.52 load_env
----------------
-- Command: load_env [--file file] [--skip-sig]
[whitelisted_variable_name] ...
Load all variables from the environment block file into the
environment. *Note Environment block::.
The '--file' option overrides the default location of the
environment block.
The '--skip-sig' option skips signature checking even when the
value of environment variable 'check_signatures' is set to
'enforce' (*note check_signatures::).
If one or more variable names are provided as arguments, they are
interpreted as a whitelist of variables to load from the
environment block file. Variables set in the file but not present
in the whitelist are ignored.
The '--skip-sig' option should be used with care, and should always
be used in concert with a whitelist of acceptable variables whose
values should be set. Failure to employ a carefully constructed
whitelist could result in reading a malicious value into critical
environment variables from the file, such as setting
'check_signatures=no', modifying 'prefix' to boot from an
unexpected location or not at all, etc.
When used with care, '--skip-sig' and the whitelist enable an
administrator to configure a system to boot only signed
configurations, but to allow the user to select from among multiple
configurations, and to enable "one-shot" boot attempts and
"savedefault" behavior. *Note Using GPG-style digital
signatures::, for more information.
If the environment variable 'check_appended_signatures' value is
set to 'yes' and VAS_EBOOT is in lockeddown mode, the user is not
allowed to set 'check_appended_signatures' to 'no' and
'appendedsig_key_mgmt' to 'static' or 'dynamic' either directly
using 'load_env' command or via environment block file. *Note
Using appended signatures::, for more information.

File: VasEBoot.info, Node: loadfont, Next: loopback, Prev: load_env, Up: Command-line commands
17.4.53 loadfont
----------------
-- Command: loadfont file ...
Load specified font files. Unless absolute pathname is given, FILE
is assumed to be in directory '$prefix/fonts' with suffix '.pf2'
appended. *Note Fonts: Theme file format.

File: VasEBoot.info, Node: loopback, Next: ls, Prev: loadfont, Up: Command-line commands
17.4.54 loopback
----------------
-- Command: loopback [-d] [-D] device file
Make the device named DEVICE correspond to the contents of the
filesystem image in FILE. For example:
loopback loop0 /path/to/image
ls (loop0)/
Specifying the '-D' option allows the loopback file to be
tranparently decompressed if there is an appropriate decompressor
loaded.
With the '-d' option, delete a device previously created using this
command.

File: VasEBoot.info, Node: ls, Next: lsfonts, Prev: loopback, Up: Command-line commands
17.4.55 ls
----------
-- Command: ls [arg ...]
List devices or files.
With no arguments, print all devices known to VAS_EBOOT.
If the argument is a device name enclosed in parentheses (*note
Device syntax::), then print the name of the filesystem of that
device.
If the argument is a directory given as an absolute file name
(*note File name syntax::), then list the contents of that
directory.

File: VasEBoot.info, Node: lsfonts, Next: lsfreemem, Prev: ls, Up: Command-line commands
17.4.56 lsfonts
---------------
-- Command: lsfonts
List loaded fonts.

File: VasEBoot.info, Node: lsfreemem, Next: lsmod, Prev: lsfonts, Up: Command-line commands
17.4.57 lsfreemem
-----------------
-- Command: lsfreemem
List free memory blocks.

File: VasEBoot.info, Node: lsmod, Next: lsmem, Prev: lsfreemem, Up: Command-line commands
17.4.58 lsmod
-------------
-- Command: lsmod
Show list of loaded modules.

File: VasEBoot.info, Node: lsmem, Next: lsmemregions, Prev: lsmod, Up: Command-line commands
17.4.59 lsmem
-------------
-- Command: lsmem
List free and allocated memory blocks.

File: VasEBoot.info, Node: lsmemregions, Next: md5sum, Prev: lsmem, Up: Command-line commands
17.4.60 lsmemregions
--------------------
-- Command: lsmemregions
Prints memory region general information including size, number of
blocks, and total free / total allocated memory per region.

File: VasEBoot.info, Node: md5sum, Next: module, Prev: lsmemregions, Up: Command-line commands
17.4.61 md5sum
--------------
-- Command: md5sum arg ...
Alias for 'hashsum --hash md5 arg ...'. See command 'hashsum'
(*note hashsum::) for full description.

File: VasEBoot.info, Node: module, Next: multiboot, Prev: md5sum, Up: Command-line commands
17.4.62 module
--------------
-- Command: module [--nounzip] file [arguments]
Load a module for multiboot kernel image. The rest of the line is
passed verbatim as the module command line.

File: VasEBoot.info, Node: multiboot, Next: nativedisk, Prev: module, Up: Command-line commands
17.4.63 multiboot
-----------------
-- Command: multiboot [--quirk-bad-kludge]
[--quirk-modules-after-kernel] file ...
Load a multiboot kernel image from FILE. The rest of the line is
passed verbatim as the "kernel command-line". Any module must be
reloaded after using this command (*note module::).
Some kernels have known problems. You need to specify -quirk-* for
those. -quirk-bad-kludge is a problem seen in several products
that they include loading kludge information with invalid data in
ELF file. VAS_EBOOT prior to 0.97 and some custom builds preferred ELF
information while 0.97 and VAS_EBOOT 2 use kludge. Use this option to
ignore kludge. Known affected systems: old Solaris, SkyOS.
-quirk-modules-after-kernel is needed for kernels which load at
relatively high address e.g. 16MiB mark and can't cope with
modules stuffed between 1MiB mark and beginning of the kernel.
Known afftected systems: VMWare.

File: VasEBoot.info, Node: nativedisk, Next: normal, Prev: multiboot, Up: Command-line commands
17.4.64 nativedisk
------------------
-- Command: nativedisk
Switch from firmware disk drivers to native ones. Really useful
only on platforms where both firmware and native disk drives are
available. Currently i386-pc, i386-efi, i386-ieee1275 and
x86_64-efi.

File: VasEBoot.info, Node: normal, Next: normal_exit, Prev: nativedisk, Up: Command-line commands
17.4.65 normal
--------------
-- Command: normal [file]
Enter normal mode and display the VAS_EBOOT menu.
In normal mode, commands, filesystem modules, and cryptography
modules are automatically loaded, and the full VAS_EBOOT script parser
is available. Other modules may be explicitly loaded using
'insmod' (*note insmod::).
If a FILE is given, then commands will be read from that file.
Otherwise, they will be read from '$prefix/VasEBoot.cfg' if it exists.
'normal' may be called from within normal mode, creating a nested
environment. It is more usual to use 'configfile' (*note
configfile::) for this.

File: VasEBoot.info, Node: normal_exit, Next: parttool, Prev: normal, Up: Command-line commands
17.4.66 normal_exit
-------------------
-- Command: normal_exit
Exit normal mode (*note normal::). If this instance of normal mode
was not nested within another one, then return to rescue mode.

File: VasEBoot.info, Node: parttool, Next: password, Prev: normal_exit, Up: Command-line commands
17.4.67 parttool
----------------
-- Command: parttool partition commands
Make various modifications to partition table entries.
Each COMMAND is either a boolean option, in which case it must be
followed with '+' or '-' (with no intervening space) to enable or
disable that option, or else it takes a value in the form
'COMMAND=VALUE'.
Currently, 'parttool' is only useful on DOS partition tables (also
known as Master Boot Record, or MBR). On these partition tables,
the following commands are available:
'boot' (boolean)
When enabled, this makes the selected partition be the active
(bootable) partition on its disk, clearing the active flag on
all other partitions. This command is limited to _primary_
partitions.
'type' (value)
Change the type of an existing partition. The value must be a
number in the range 0-0xFF (prefix with '0x' to enter it in
hexadecimal).
'hidden' (boolean)
When enabled, this hides the selected partition by setting the
"hidden" bit in its partition type code; when disabled,
unhides the selected partition by clearing this bit. This is
useful only when booting DOS or Windows and multiple primary
FAT partitions exist in one disk. See also *note
DOS/Windows::.

File: VasEBoot.info, Node: password, Next: password_pbkdf2, Prev: parttool, Up: Command-line commands
17.4.68 password
----------------
-- Command: password user clear-password
Define a user named USER with password CLEAR-PASSWORD. *Note
Security::.

File: VasEBoot.info, Node: password_pbkdf2, Next: plainmount, Prev: password, Up: Command-line commands
17.4.69 password_pbkdf2
-----------------------
-- Command: password_pbkdf2 user hashed-password
Define a user named USER with password hash HASHED-PASSWORD. Use
'VasEBoot-mkpasswd-pbkdf2' (*note Invoking VasEBoot-mkpasswd-pbkdf2::) to
generate password hashes. *Note Security::.

File: VasEBoot.info, Node: plainmount, Next: play, Prev: password_pbkdf2, Up: Command-line commands
17.4.70 plainmount
------------------
-- Command: plainmount device -c cipher -s key size [-h hash]
['-S' sector size] ['-p' password] ['-u' uuid] [['-d' keyfile]
['-O' keyfile offset]]
Setup access to the encrypted device in plain mode. Offset of the
encrypted data at the device is specified in terms of 512 byte
sectors using the blocklist syntax and loopback device. The
following example shows how to specify 1MiB offset:
loopback node (hd0,gpt1)2048+
plainmount node ...
The 'plainmount' command can be used to open LUKS encrypted volume
if its master key and parameters (key size, cipher, offset, etc)
are known.
There are two ways to specify a password: a keyfile and a secret
passphrase. The keyfile path parameter has higher priority than
the secret passphrase parameter and is specified with the option
'-d'. Password data obtained from keyfiles is not hashed and is
used directly as a cipher key. An optional offset of password data
in the keyfile can be specified with the option '-O' or directly
with the option '-d' and VAS_EBOOT blocklist syntax, if the keyfile data
can be accessed from a device and is 512 byte aligned. The
following example shows both methods to specify password data in
the keyfile at offset 1MiB:
plainmount -d (hd0,gpt1)2048+ ...
plainmount -d (hd0,gpt1)+ -O 1048576 ...
If no keyfile is specified then the password is set to the string
specified by option '-p' or is requested interactively from the
console. In both cases the provided password is hashed with the
algorithm specified by the option '-h'. This option is mandatory
if no keyfile is specified, but it can be set to 'plain' which
means that no hashing is done and such password is used directly as
a key.
Cipher '-c' and keysize '-s' options specify the cipher algorithm
and the key size respectively and are mandatory options. Cipher
must be specified with the mode separated by a dash (for example,
'aes-xts-plain64'). Key size option '-s' is the key size of the
cipher in bits, not to be confused with the offset of the key data
in a keyfile specified with the '-O' option. It must not exceed
1024 bits, so a 32 byte key would be specified as 256 bits
The optional parameter '-S' specifies encrypted device sector size.
It must be at least 512 bytes long (default value) and a power of
2. (1) (*note plainmount-Footnote-1::). Disk sector size is
configured when creating the encrypted volume. Attempting to
decrypt volumes with a different sector size than it was created
with will not result in an error, but will decrypt to random bytes
and thus prevent accessing the volume (in some cases the filesystem
driver can detect the presence of a filesystem, but nevertheless
will refuse to mount it).
By default new plainmount devices will be given a UUID starting
with '109fea84-a6b7-34a8-4bd1-1c506305a401' where the last digits
are incremented by one for each plainmounted device beyond the
first up to 2^10 devices.
All encryption arguments (cipher, hash, key size, disk offset and
disk sector size) must match the parameters used to create the
volume. If any of them does not match the actual arguments used
during the initial encryption, plainmount will create virtual
device with the garbage data and VAS_EBOOT will report unknown
filesystem for such device.

File: VasEBoot.info, Node: plainmount-Footnotes, Up: plainmount
(1) Current implementation of cryptsetup supports only
512/1024/2048/4096 byte sectors

File: VasEBoot.info, Node: play, Next: probe, Prev: plainmount, Up: Command-line commands
17.4.71 play
------------
-- Command: play file | tempo [pitch1 duration1] [pitch2 duration2] ...
Plays a tune
If the argument is a file name (*note File name syntax::), play the
tune recorded in it. The file format is first the tempo as an
unsigned 32bit little-endian number, then pairs of unsigned 16bit
little-endian numbers for pitch and duration pairs.
If the arguments are a series of numbers, play the inline tune.
The tempo is the base for all note durations. 60 gives a 1-second
base, 120 gives a half-second base, etc. Pitches are Hz. Set
pitch to 0 to produce a rest.

File: VasEBoot.info, Node: probe, Next: rdmsr, Prev: play, Up: Command-line commands
17.4.72 probe
-------------
-- Command: probe [--set var]
--driver|--partmap|--fs|--fs-uuid|--label|--part-uuid device
Retrieve device information. If option '--set' is given, assign
result to variable VAR, otherwise print information on the screen.
The option '--part-uuid' is currently only implemented for MSDOS
and GPT formatted disks.

File: VasEBoot.info, Node: rdmsr, Next: read, Prev: probe, Up: Command-line commands
17.4.73 rdmsr
-------------
-- Command:: rdmsr 0xADDR [-v VARNAME]
Read a model-specific register at address 0xADDR. If the parameter
'-v' is used and an environment variable VARNAME is given, set that
environment variable to the value that was read.
Please note that on SMP systems, reading from a MSR that has a
scope per hardware thread, implies that the value that is returned
only applies to the particular cpu/core/thread that runs the
command.
Also, if you specify a reserved or unimplemented MSR address, it
will cause a general protection exception (which is not currently
being handled) and the system will reboot.

File: VasEBoot.info, Node: read, Next: reboot, Prev: rdmsr, Up: Command-line commands
17.4.74 read
------------
-- Command: read [-s] [var]
Read a line of input from the user. If an environment variable VAR
is given, set that environment variable to the line of input that
was read, with no terminating newline. If the parameter '-s' is
used, enable silent mode where input is not printed to the
terminal.

File: VasEBoot.info, Node: reboot, Next: regexp, Prev: read, Up: Command-line commands
17.4.75 reboot
--------------
-- Command: reboot
Reboot the computer.

File: VasEBoot.info, Node: regexp, Next: rmmod, Prev: reboot, Up: Command-line commands
17.4.76 regexp
--------------
-- Command: regexp [--set [number:]var] regexp string
Test if regular expression REGEXP matches STRING. Supported
regular expressions are POSIX.2 Extended Regular Expressions. If
option '--set' is given, store NUMBERth matched subexpression in
variable VAR. Subexpressions are numbered in order of their
opening parentheses starting from '1'. NUMBER defaults to '1'.

File: VasEBoot.info, Node: rmmod, Next: save_env, Prev: regexp, Up: Command-line commands
17.4.77 rmmod
-------------
-- Command: rmmod module
Remove a loaded MODULE.

File: VasEBoot.info, Node: save_env, Next: search, Prev: rmmod, Up: Command-line commands
17.4.78 save_env
----------------
-- Command: save_env [--file file] var ...
Save the named variables from the environment to the environment
block file. *Note Environment block::.
The '--file' option overrides the default location of the
environment block.
This command will operate successfully even when environment
variable 'check_signatures' is set to 'enforce' (*note
check_signatures::), since it writes to disk and does not alter the
behavior of VAS_EBOOT based on any contents of disk that have been read.
It is possible to modify a digitally signed environment block file
from within VAS_EBOOT using this command, such that its signature will
no longer be valid on subsequent boots. Care should be taken in
such advanced configurations to avoid rendering the system
unbootable. *Note Using GPG-style digital signatures::, for more
information.

File: VasEBoot.info, Node: search, Next: sendkey, Prev: save_env, Up: Command-line commands
17.4.79 search
--------------
-- Command: search [--file|--label|--fs-uuid] [--set [var]]
[--no-floppy|--efidisk-only|--cryptodisk-only] name
Search devices by file ('-f', '--file'), filesystem label ('-l',
'--label'), or filesystem UUID ('-u', '--fs-uuid').
If the ('-s', '--set') option is used, the first device found is
set as the value of environment variable VAR. The default variable
is 'root'.
The ('-n', '--no-floppy') option prevents searching floppy devices,
which can be slow.
The ('--efidisk-only') option prevents searching any other devices
then EFI disks. This is typically used when chainloading to local
EFI partition.
The ('--cryptodisk-only') option prevents searching any devices
other than encrypted disks. This is typically used when booting
from an encrypted file system to ensure that no code gets executed
from an unencrypted device having the same filesystem UUID or
label.
This option implicitly invokes the command 'cryptocheck', if it is
available (*note cryptocheck:: for additional information).
The 'search.file', 'search.fs_label', and 'search.fs_uuid' commands
are aliases for 'search --file', 'search --label', and 'search
--fs-uuid' respectively.
Also hints as to which device may be the most likely to contain the
item searched for may be given via the ('-h', '--hint') option with
a device name as an argument. If the argument ends with a comma,
then partitions on the device are also searched. Furthermore,
platform specific hints may be given via the options
'--hint-ieee1275', '--hint-bios', '--hint-baremetal', '--hint-efi',
and '--hint-arc'. When specified, these options take an argument
and operate like '--hint', but only on the specified platform.

File: VasEBoot.info, Node: sendkey, Next: set, Prev: search, Up: Command-line commands
17.4.80 sendkey
---------------
-- Command: sendkey
[--num|--caps|--scroll|--insert|--pause|--left-shift|--right-shift|--sysrq|--numkey|--capskey|--scrollkey|--insertkey|--left-alt|--right-alt|--left-ctrl|--right-ctrl
on|off]... [no-led] keystroke
Insert keystrokes into the keyboard buffer when booting. Sometimes
an operating system or chainloaded boot loader requires particular
keys to be pressed: for example, one might need to press a
particular key to enter "safe mode", or when chainloading another
boot loader one might send keystrokes to it to navigate its menu.
Note: This command is currently only available on the i386-pc
target.
You may provide up to 16 keystrokes (the length of the BIOS
keyboard buffer). Keystroke names may be upper-case or lower-case
letters, digits, or taken from the following table:
Name Key
-------------------------------------------------------------------
escape Escape
exclam !
at @
numbersign #
dollar $
percent %
caret ^
ampersand &
asterisk *
parenleft (
parenright )
minus -
underscore _
equal =
plus +
backspace Backspace
tab Tab
bracketleft [
braceleft {
bracketright ]
braceright }
enter Enter
control press and release Control
semicolon ;
colon :
quote '
doublequote "
backquote '
tilde ~
shift press and release left Shift
backslash \
bar |
comma ,
less <
period .
greater >
slash /
question ?
rshift press and release right Shift
alt press and release Alt
space space bar
capslock Caps Lock
F1 F1
F2 F2
F3 F3
F4 F4
F5 F5
F6 F6
F7 F7
F8 F8
F9 F9
F10 F10
F11 F11
F12 F12
num1 1 (numeric keypad)
num2 2 (numeric keypad)
num3 3 (numeric keypad)
num4 4 (numeric keypad)
num5 5 (numeric keypad)
num6 6 (numeric keypad)
num7 7 (numeric keypad)
num8 8 (numeric keypad)
num9 9 (numeric keypad)
num0 0 (numeric keypad)
numperiod . (numeric keypad)
numend End (numeric keypad)
numdown Down (numeric keypad)
numpgdown Page Down (numeric keypad)
numleft Left (numeric keypad)
numcenter 5 with Num Lock inactive (numeric
keypad)
numright Right (numeric keypad)
numhome Home (numeric keypad)
numup Up (numeric keypad)
numpgup Page Up (numeric keypad)
numinsert Insert (numeric keypad)
numdelete Delete (numeric keypad)
numasterisk * (numeric keypad)
numminus - (numeric keypad)
numplus + (numeric keypad)
numslash / (numeric keypad)
numenter Enter (numeric keypad)
delete Delete
insert Insert
home Home
end End
pgdown Page Down
pgup Page Up
down Down
up Up
left Left
right Right
As well as keystrokes, the 'sendkey' command takes various options
that affect the BIOS keyboard status flags. These options take an
'on' or 'off' parameter, specifying that the corresponding status
flag be set or unset; omitting the option for a given status flag
will leave that flag at its initial state at boot. The '--num',
'--caps', '--scroll', and '--insert' options emulate setting the
corresponding mode, while the '--numkey', '--capskey',
'--scrollkey', and '--insertkey' options emulate pressing and
holding the corresponding key. The other status flag options are
self-explanatory.
If the '--no-led' option is given, the status flag options will
have no effect on keyboard LEDs.
If the 'sendkey' command is given multiple times, then only the
last invocation has any effect.
Since 'sendkey' manipulates the BIOS keyboard buffer, it may cause
hangs, reboots, or other misbehaviour on some systems. If the
operating system or boot loader that runs after VAS_EBOOT uses its own
keyboard driver rather than the BIOS keyboard functions, then
'sendkey' will have no effect.
This command is only available on PC BIOS systems.

File: VasEBoot.info, Node: set, Next: sha1sum, Prev: sendkey, Up: Command-line commands
17.4.81 set
-----------
-- Command: set [envvar=value]
Set the environment variable ENVVAR to VALUE. If invoked with no
arguments, print all environment variables with their values. For
the list of environment variables currently used by VAS_EBOOT itself see
the relevant section *note Environment::.

File: VasEBoot.info, Node: sha1sum, Next: sha256sum, Prev: set, Up: Command-line commands
17.4.82 sha1sum
---------------
-- Command: sha1sum arg ...
Alias for 'hashsum --hash sha1 arg ...'. See command 'hashsum'
(*note hashsum::) for full description.

File: VasEBoot.info, Node: sha256sum, Next: sha512sum, Prev: sha1sum, Up: Command-line commands
17.4.83 sha256sum
-----------------
-- Command: sha256sum arg ...
Alias for 'hashsum --hash sha256 arg ...'. See command 'hashsum'
(*note hashsum::) for full description.

File: VasEBoot.info, Node: sha512sum, Next: sleep, Prev: sha256sum, Up: Command-line commands
17.4.84 sha512sum
-----------------
-- Command: sha512sum arg ...
Alias for 'hashsum --hash sha512 arg ...'. See command 'hashsum'
(*note hashsum::) for full description.

File: VasEBoot.info, Node: sleep, Next: smbios, Prev: sha512sum, Up: Command-line commands
17.4.85 sleep
-------------
-- Command: sleep [--verbose] [--interruptible] count
Sleep for COUNT seconds. If option '--interruptible' is given,
allow pressing <ESC>, <F4> or holding down <SHIFT> to interrupt
sleep. With '--verbose' show countdown of remaining seconds. Exit
code is set to 0 if timeout expired and to 1 if timeout was
interrupted using any of the mentioned keys.

File: VasEBoot.info, Node: smbios, Next: source, Prev: sleep, Up: Command-line commands
17.4.86 smbios
--------------
-- Command: smbios [--type TYPE] [--handle HANDLE] [--match MATCH]
(--get-byte | --get-word | --get-dword | --get-qword |
--get-string | --get-uuid) OFFSET [--set VARIABLE]
Retrieve SMBIOS information.
The 'smbios' command returns the value of a field in an SMBIOS
structure. The following options determine which structure to
select.
* Specifying '--type' will select structures with a matching
TYPE. The type can be any integer from 0 to 255.
* Specifying '--handle' will select structures with a matching
HANDLE. The handle can be any integer from 0 to 65535.
* Specifying '--match' will select structure number MATCH in the
filtered list of structures; e.g. 'smbios --type 4 --match 2'
will select the second Process Information (Type 4) structure.
The list is always ordered the same as the hardware's SMBIOS
table. The match number must be a positive integer. If
unspecified, the first matching structure will be selected.
The remaining options determine which field in the selected SMBIOS
structure to return. Only one of these options may be specified at
a time.
* When given '--get-byte', return the value of the byte at
OFFSET bytes into the selected SMBIOS structure. It will be
formatted as an unsigned decimal integer.
* When given '--get-word', return the value of the word (two
bytes) at OFFSET bytes into the selected SMBIOS structure. It
will be formatted as an unsigned decimal integer.
* When given '--get-dword', return the value of the dword (four
bytes) at OFFSET bytes into the selected SMBIOS structure. It
will be formatted as an unsigned decimal integer.
* When given '--get-qword', return the value of the qword (eight
bytes) at OFFSET bytes into the selected SMBIOS structure. It
will be formatted as an unsigned decimal integer.
* When given '--get-string', return the string with its index
found at OFFSET bytes into the selected SMBIOS structure.
* When given '--get-uuid', return the value of the UUID (sixteen
bytes) at OFFSET bytes into the selected SMBIOS structure. It
will be formatted as lower-case hyphenated hexadecimal digits,
with the first three fields as little-endian, and the rest
printed byte-by-byte.
The default action is to print the value of the requested field to
the console, but a variable name can be specified with '--set' to
store the value instead of printing it.
For example, this will store and then display the system
manufacturer's name.
smbios --type 1 --get-string 4 --set system_manufacturer
echo $system_manufacturer

File: VasEBoot.info, Node: source, Next: stress_big_allocs, Prev: smbios, Up: Command-line commands
17.4.87 source
--------------
-- Command: source file
Read FILE as a configuration file, as if its contents had been
incorporated directly into the sourcing file. Unlike 'configfile'
(*note configfile::), this executes the contents of FILE without
changing context: any environment variable changes made by the
commands in FILE will be preserved after 'source' returns, and the
menu will not be shown immediately.

File: VasEBoot.info, Node: stress_big_allocs, Next: test, Prev: source, Up: Command-line commands
17.4.88 stress_big_allocs
-------------------------
-- Command: stress_big_allocs
Stress test large memory allocations.

File: VasEBoot.info, Node: test, Next: tpm2_key_protector_init, Prev: stress_big_allocs, Up: Command-line commands
17.4.89 test
------------
-- Command: test expression
Evaluate EXPRESSION and return zero exit status if result is true,
non zero status otherwise.
EXPRESSION is one of:
STRING1 '==' STRING2
the strings are equal
STRING1 '!=' STRING2
the strings are not equal
STRING1 '<' STRING2
STRING1 is lexicographically less than STRING2
STRING1 '<=' STRING2
STRING1 is lexicographically less or equal than STRING2
STRING1 '>' STRING2
STRING1 is lexicographically greater than STRING2
STRING1 '>=' STRING2
STRING1 is lexicographically greater or equal than STRING2
INTEGER1 '-eq' INTEGER2
INTEGER1 is equal to INTEGER2
INTEGER1 '-ge' INTEGER2
INTEGER1 is greater than or equal to INTEGER2
INTEGER1 '-gt' INTEGER2
INTEGER1 is greater than INTEGER2
INTEGER1 '-le' INTEGER2
INTEGER1 is less than or equal to INTEGER2
INTEGER1 '-lt' INTEGER2
INTEGER1 is less than INTEGER2
INTEGER1 '-ne' INTEGER2
INTEGER1 is not equal to INTEGER2
PREFIXINTEGER1 '-pgt' PREFIXINTEGER2
INTEGER1 is greater than INTEGER2 after stripping off common
non-numeric PREFIX.
PREFIXINTEGER1 '-plt' PREFIXINTEGER2
INTEGER1 is less than INTEGER2 after stripping off common
non-numeric PREFIX.
FILE1 '-nt' FILE2
FILE1 is newer than FILE2 (modification time). Optionally
numeric BIAS may be directly appended to '-nt' in which case
it is added to the first file modification time.
FILE1 '-ot' FILE2
FILE1 is older than FILE2 (modification time). Optionally
numeric BIAS may be directly appended to '-ot' in which case
it is added to the first file modification time.
'-d' FILE
FILE exists and is a directory
'-e' FILE
FILE exists
'-f' FILE
FILE exists and is not a directory
'-s' FILE
FILE exists and has a size greater than zero
'-n' STRING
the length of STRING is nonzero
STRING
STRING is equivalent to '-n STRING'
'-z' STRING
the length of STRING is zero
'(' EXPRESSION ')'
EXPRESSION is true
'!' EXPRESSION
EXPRESSION is false
EXPRESSION1 '-a' EXPRESSION2
both EXPRESSION1 and EXPRESSION2 are true
EXPRESSION1 EXPRESSION2
both EXPRESSION1 and EXPRESSION2 are true. This syntax is not
POSIX-compliant and is not recommended.
EXPRESSION1 '-o' EXPRESSION2
either EXPRESSION1 or EXPRESSION2 is true

File: VasEBoot.info, Node: tpm2_key_protector_init, Next: tpm2_key_protector_clear, Prev: test, Up: Command-line commands
17.4.90 tpm2_key_protector_init
-------------------------------
-- Command: tpm2_key_protector_init [--mode | -m mode] | [--pcrs | -p
pcrlist] | [--bank | -b pcrbank] | [--cap-pcrs | -c pcrlist] |
[ [--tpm2key | -T tpm2key_file] | [--keyfile | -k keyfile] ] |
[--srk | -s handle] | [--asymmetric | -a srk_type] |
[--nvindex | -n nv_index]
Initialize the TPM2 key protector to unseal the key for the
'cryptomount' (*note cryptomount::) command. There are two
supported modes, SRK('srk') and NV index('nv'), to be specified by
the option '-m'. The default mode is SRK. The main difference
between SRK mode and NV index mode is the storage of the sealed
key. For SRK mode, the sealed key is stored in a file while NV
index mode stores the sealed key in the non-volatile memory inside
TPM with a given NV index.
The '-p' and '-b' options are used to supply the PCR list and bank
that the key is sealed with. The PCR list is a comma-separated
list, e.g., '0,2,4,7,9', to represent the involved PCRs, and the
default is '7'. The PCR bank is chosen by selecting a hash
algorithm. The current supported PCR banks are SHA1, SHA256,
SHA384, and SHA512, and the default is SHA256.
The '-c' option is introduced to enable the "capping" of a
specified list of PCRs. This feature addresses scenarios where a
user wants to ensure a sealed key cannot be unsealed again after
its initial use. When the '-c' option is employed, and the key is
successfully unsealed, the TPM2 key protector automatically extends
the selected PCRs with an EV_SEPARATOR event. This action
cryptographically alters the PCR values, thereby preventing the
associated key from being unsealed in any subsequent attempts until
those specific PCRs are reset to their original state, which
typically occurs during a system reboot. In general, it is
sufficient to extend one associated PCR to cap the key.
It's noteworthy that a key sealed against PCR 8 naturally
incorporates a "capping" behavior, even without explicitly using a
'-c' option. This is because VAS_EBOOT measures all commands into PCR
8, including those from configuration files. As a result, the
value of PCR 8 changes with virtually every command execution
during the boot process. Consequently, a key sealed against PCR 8
can only be unsealed once in a given boot session, as any
subsequent VAS_EBOOT command will alter PCR 8, invalidating the
unsealing policy and effectively "capping" the key.
Some options are only available for the specific mode. The
SRK-specific options are '-T', '-k', '-a', and '-s'. On the other
hand, the NV index-specific option is '-n'.
The key file for SRK mode can be supplied with either '-T' or '-k'.
Those two options were used to distinguish the file formats but are
same now. There are two supported file formats: raw format and TPM
2.0 Key File format. When using the key file in the raw format,
the '-p' and '-b' options are necessary for the non-default PCR
list or bank. On the other hand, when using the key file in TPM
2.0 Key File format, the the parameters for the TPM commands are
written in the file, and there is no need to set the PCR list('-p')
and bank('-b'). In general, TPM 2.0 Key File format is preferred
due to the simplified VAS_EBOOT command options and the authorized
policy support
Besides the key file, there are two options, '-a' and '-s', to
tweak the TPM Storage Root Key (SRK). The SRK can be either created
at runtime or stored in the non-volatile memory. When creating SRK
at runtime, VAS_EBOOT provides the SRK template to the TPM to create the
key. There are two SRK templates for the '-a' option, ECC and RSA,
and the default is ECC. If the SRK is stored in a specific handle,
e.g. '0x81000001', the '-s' option can be used to set the handle
to notify VAS_EBOOT to load the SRK from the given handle.
The only NV index-specific option is the '-n' option which is used
to set the NV index containing the sealed key. Then VAS_EBOOT can load
the sealed key and unseal it with the given PCR list and bank.

File: VasEBoot.info, Node: tpm2_key_protector_clear, Next: tpm2_dump_pcr, Prev: tpm2_key_protector_init, Up: Command-line commands
17.4.91 tpm2_key_protector_clear
--------------------------------
-- Command: tpm2_key_protector_clear
Clear the TPM2 key protector if previously initialized.

File: VasEBoot.info, Node: tpm2_dump_pcr, Next: true, Prev: tpm2_key_protector_clear, Up: Command-line commands
17.4.92 tpm2_dump_pcr
---------------------
-- Command: tpm2_dump_pcr [BANK]
Print all PCRs of the specified TPM 2.0 BANK. The supported banks
are 'sha1', 'sha256', 'sha384', and 'sha512'. If BANK is not
specified, 'sha256' is chosen by default.
Since VAS_EBOOT measures every command into PCR 8, invoking
'tpm2_dump_pcr' also extends PCR 8, so PCR 8 will not be a stable
value in VAS_EBOOT shell.

File: VasEBoot.info, Node: true, Next: trust, Prev: tpm2_dump_pcr, Up: Command-line commands
17.4.93 true
------------
-- Command: true
Do nothing, successfully. This is mainly useful in control
constructs such as 'if' and 'while' (*note Shell-like scripting::).

File: VasEBoot.info, Node: trust, Next: uki, Prev: true, Up: Command-line commands
17.4.94 trust
-------------
-- Command: trust [--skip-sig] pubkey_file
Read public key from PUBKEY_FILE and add it to VAS_EBOOT's internal list
of trusted public keys. These keys are used to validate digital
signatures when environment variable 'check_signatures' is set to
'enforce'. Note that if 'check_signatures' is set to 'enforce'
when 'trust' executes, then PUBKEY_FILE must itself be properly
signed. The '--skip-sig' option can be used to disable
signature-checking when reading PUBKEY_FILE itself. It is expected
that '--skip-sig' is useful for testing and manual booting. *Note
Using GPG-style digital signatures::, for more information.

File: VasEBoot.info, Node: uki, Next: unset, Prev: trust, Up: Command-line commands
17.4.95 uki
-----------
-- Command: uki [-p|--path dir] [-f|--enable-fallback]
[-d|--show-default] [-n|--show-non-default] [-e|--entry file]
Load Unified Kernel Image (UKI) files into the VAS_EBOOT menu. Boot
entries generated from 'uki' won't interfere with entries from
'VasEBoot.cfg' appearing in the VAS_EBOOT menu. Also, entries generated
from 'uki' exists only in memory and don't update 'VasEBoot.cfg'.
By default, the UKI files are stored in the '/EFI/Linux' directory
in the EFI system partition. If UKI files are stored elsewhere,
the '--path' option can be used to check a different directory
instead of the default location. If no UKI files are found while
using the '--path' option, the '--enable-fallback' option can be
used to check for files in the default location.
The '--show-default' option allows the default boot entry to be
added to the VAS_EBOOT menu from the UKI files.
The '--show-non-default' option allows non-default boot entries to
be added to the VAS_EBOOT menu from the UKI files.
The '--entry' option allows specific boot entries to be added to
the VAS_EBOOT menu from the UKI files.
The '--entry', '--show-default', and '--show-non-default' options
are used to filter which UKI files are added to the VAS_EBOOT menu. If
none are used, all files in the default location or the location
specified by '--path' will be added to the VAS_EBOOT menu.
For more information on UKI, see: The Unified Kernel Image
Specification
(https://uapi-group.org/specifications/specs/unified_kernel_image/)

File: VasEBoot.info, Node: unset, Next: verify_detached, Prev: uki, Up: Command-line commands
17.4.96 unset
-------------
-- Command: unset envvar
Unset the environment variable ENVVAR.

File: VasEBoot.info, Node: verify_detached, Next: videoinfo, Prev: unset, Up: Command-line commands
17.4.97 verify_detached
-----------------------
-- Command: verify_detached [--skip-sig] file signature_file
[pubkey_file]
Verifies a GPG-style detached signature, where the signed file is
FILE, and the signature itself is in file SIGNATURE_FILE.
Optionally, a specific public key to use can be specified using
PUBKEY_FILE. When environment variable 'check_signatures' is set
to 'enforce', then PUBKEY_FILE must itself be properly signed by an
already-trusted key. An unsigned PUBKEY_FILE can be loaded by
specifying '--skip-sig'. If PUBKEY_FILE is omitted, then public
keys from VAS_EBOOT's trusted keys (*note list_trusted::, *note trust::,
and *note distrust::) are tried.
Exit code '$?' is set to 0 if the signature validates successfully.
If validation fails, it is set to a non-zero value. *Note Using
GPG-style digital signatures::, for more information.

File: VasEBoot.info, Node: videoinfo, Next: wrmsr, Prev: verify_detached, Up: Command-line commands
17.4.98 videoinfo
-----------------
-- Command: videoinfo [[WxH]xD]
List available video modes. If resolution is given, show only
matching modes.

File: VasEBoot.info, Node: wrmsr, Prev: videoinfo, Up: Command-line commands
17.4.99 wrmsr
-------------
-- Command:: wrmsr 0xADDR 0xVALUE
Write a 0xVALUE to a model-specific register at address 0xADDR.
Please note that on SMP systems, writing to a MSR that has a scope
per hardware thread, implies that the value that is written only
applies to the particular cpu/core/thread that runs the command.
Also, if you specify a reserved or unimplemented MSR address, it
will cause a general protection exception (which is not currently
being handled) and the system will reboot.
Note: The command is not allowed when lockdown is enforced (*note
Lockdown::). This is done to prevent subverting various security
mechanisms.

File: VasEBoot.info, Node: Networking commands, Next: Undocumented commands, Prev: Command-line commands, Up: Commands
17.5 Networking commands
========================
* Menu:
* net_add_addr:: Add a network address
* net_add_dns:: Add a DNS server
* net_add_route:: Add routing entry
* net_bootp:: Perform a bootp/DHCP autoconfiguration
* net_del_addr:: Remove IP address from interface
* net_del_dns:: Remove a DNS server
* net_del_route:: Remove a route entry
* net_dhcp:: Perform a DHCP autoconfiguration
* net_get_dhcp_option:: Retrieve DHCP options
* net_ipv6_autoconf:: Perform IPv6 autoconfiguration
* net_ls_addr:: List interfaces
* net_ls_cards:: List network cards
* net_ls_dns:: List DNS servers
* net_ls_routes:: List routing entries
* net_nslookup:: Perform a DNS lookup
* net_set_vlan:: Set vlan id on an interface

File: VasEBoot.info, Node: net_add_addr, Next: net_add_dns, Up: Networking commands
17.5.1 net_add_addr
-------------------
-- Command: net_add_addr INTERFACE CARD ADDRESS
Configure additional network INTERFACE with ADDRESS on a network
CARD. ADDRESS can be either IP in dotted decimal notation, or
symbolic name which is resolved using DNS lookup. If successful,
this command also adds local link routing entry to the default
subnet of ADDRESS with name INTERFACE':local' via INTERFACE.

File: VasEBoot.info, Node: net_add_dns, Next: net_add_route, Prev: net_add_addr, Up: Networking commands
17.5.2 net_add_dns
------------------
-- Command: net_add_dns SERVER
Resolve SERVER IP address and add to the list of DNS servers used
during name lookup.

File: VasEBoot.info, Node: net_add_route, Next: net_bootp, Prev: net_add_dns, Up: Networking commands
17.5.3 net_add_route
--------------------
-- Command: net_add_route SHORTNAME IP[/PREFIX] [INTERFACE | gw
GATEWAY]
Add route to network with address IP as modified by PREFIX via
either local INTERFACE or GATEWAY. PREFIX is optional and defaults
to 32 for IPv4 address and 128 for IPv6 address. Route is
identified by SHORTNAME which can be used to remove it (*note
net_del_route::).

File: VasEBoot.info, Node: net_bootp, Next: net_del_addr, Prev: net_add_route, Up: Networking commands
17.5.4 net_bootp
----------------
-- Command: net_bootp [CARD]
Alias for net_dhcp, for compatibility with older VasEBoot versions.
Will perform the same DHCP handshake with potential fallback to
BOOTP as the net_dhcp command (*note net_dhcp::).

File: VasEBoot.info, Node: net_del_addr, Next: net_del_dns, Prev: net_bootp, Up: Networking commands
17.5.5 net_del_addr
-------------------
-- Command: net_del_addr INTERFACE
Remove configured INTERFACE with associated address.

File: VasEBoot.info, Node: net_del_dns, Next: net_del_route, Prev: net_del_addr, Up: Networking commands
17.5.6 net_del_dns
------------------
-- Command: net_del_dns ADDRESS
Remove ADDRESS from list of servers used during name lookup.

File: VasEBoot.info, Node: net_del_route, Next: net_dhcp, Prev: net_del_dns, Up: Networking commands
17.5.7 net_del_route
--------------------
-- Command: net_del_route SHORTNAME
Remove route entry identified by SHORTNAME.

File: VasEBoot.info, Node: net_dhcp, Next: net_get_dhcp_option, Prev: net_del_route, Up: Networking commands
17.5.8 net_dhcp
---------------
-- Command: net_dhcp [CARD]
Perform configuration of CARD using DHCP protocol. If no card name
is specified, try to configure all existing cards. Falls back to
the BOOTP protocol, if needed. If configuration was successful,
interface with name CARD':dhcp' and configured address is added to
CARD. Additionally the following DHCP options are recognized and
processed:
'1 (Subnet Mask)'
Used to calculate network local routing entry for interface
CARD':dhcp'.
'3 (Router)'
Adds default route entry with the name CARD':dhcp:default' via
gateway from DHCP option. Note that only option with single
route is accepted.
'6 (Domain Name Server)'
Adds all servers from option value to the list of servers used
during name resolution.
'12 (Host Name)'
Sets environment variable 'net_'<CARD>'_dhcp_hostname' (*note
net_<INTERFACE>_hostname::) to the value of option.
'15 (Domain Name)'
Sets environment variable 'net_'<CARD>'_dhcp_domain' (*note
net_<INTERFACE>_domain::) to the value of option.
'17 (Root Path)'
Sets environment variable 'net_'<CARD>'_dhcp_rootpath' (*note
net_<INTERFACE>_rootpath::) to the value of option.
'18 (Extensions Path)'
Sets environment variable 'net_'<CARD>'_dhcp_extensionspath'
(*note net_<INTERFACE>_extensionspath::) to the value of
option.
'66 (TFTP Server Name)'
Sets environment variable 'net_'<CARD>'_dhcp_server_name'
(*note net_<INTERFACE>_dhcp_server_name::) to the value of
option.
'67 (Filename)'
Sets environment variable 'net_'<CARD>'_boot_file' (*note
net_<INTERFACE>_boot_file::) to the value of option.

File: VasEBoot.info, Node: net_get_dhcp_option, Next: net_ipv6_autoconf, Prev: net_dhcp, Up: Networking commands
17.5.9 net_get_dhcp_option
--------------------------
-- Command: net_get_dhcp_option VAR INTERFACE NUMBER TYPE
Request DHCP option NUMBER of TYPE via INTERFACE. TYPE can be one
of 'string', 'number' or 'hex'. If option is found, assign its
value to variable VAR. Values of types 'number' and 'hex' are
converted to string representation.

File: VasEBoot.info, Node: net_ipv6_autoconf, Next: net_ls_addr, Prev: net_get_dhcp_option, Up: Networking commands
17.5.10 net_ipv6_autoconf
-------------------------
-- Command: net_ipv6_autoconf [CARD]
Perform IPv6 autoconfiguration by adding to the CARD interface with
name CARD':link' and link local MAC-based address. If no card is
specified, perform autoconfiguration for all existing cards.

File: VasEBoot.info, Node: net_ls_addr, Next: net_ls_cards, Prev: net_ipv6_autoconf, Up: Networking commands
17.5.11 net_ls_addr
-------------------
-- Command: net_ls_addr
List all configured interfaces with their MAC and IP addresses.

File: VasEBoot.info, Node: net_ls_cards, Next: net_ls_dns, Prev: net_ls_addr, Up: Networking commands
17.5.12 net_ls_cards
--------------------
-- Command: net_ls_cards
List all detected network cards with their MAC address.

File: VasEBoot.info, Node: net_ls_dns, Next: net_ls_routes, Prev: net_ls_cards, Up: Networking commands
17.5.13 net_ls_dns
------------------
-- Command: net_ls_dns
List addresses of DNS servers used during name lookup.

File: VasEBoot.info, Node: net_ls_routes, Next: net_nslookup, Prev: net_ls_dns, Up: Networking commands
17.5.14 net_ls_routes
---------------------
-- Command: net_ls_routes
List routing entries.

File: VasEBoot.info, Node: net_nslookup, Next: net_set_vlan, Prev: net_ls_routes, Up: Networking commands
17.5.15 net_nslookup
--------------------
-- Command: net_nslookup NAME [SERVER]
Resolve address of NAME using DNS server SERVER. If no server is
given, use default list of servers.

File: VasEBoot.info, Node: net_set_vlan, Prev: net_nslookup, Up: Networking commands
17.5.16 net_set_vlan
--------------------
-- Command: net_set_vlan INTERFACE VLANID
Set the 802.1Q VLAN identifier on INTERFACE to VLANID. For
example, to set the VLAN identifier on interface 'efinet1' to
'100':
net_set_vlan efinet1 100
The VLAN identifier can be removed by setting it to '0':
net_set_vlan efinet1 0

File: VasEBoot.info, Node: Undocumented commands, Prev: Networking commands, Up: Commands
17.6 Commands currently undocumented
====================================
Unfortunately, not all VAS_EBOOT commands are documented at this time due to
developer resource constraints. One way to contribute back to the VAS_EBOOT
project would be to help document these commands, and submit patches or
ideas to the mailing list. The following is a (most likely incomplete)
list of undocumented or poorly documented commands and not all of them
are allowed for all platforms. Running the command help from within the
VAS_EBOOT shell may provide more information on parameters and usage.
* 'all_functional_test' - Run all functional tests.
* 'backtrace' - Print backtrace.
* 'boottime' - Show boot time statistics.
* 'cacheinfo' - Get disk cache info.
* 'cbmemc' - Show CBMEM console content.
* 'cmosset' - Set bit at BYTE:BIT in CMOS.
* 'coreboot_boottime' - Show coreboot boot time statistics.
* 'dump' - Show memory contents.
* 'efiemu_loadcore' - Load and initialize EFI emulator.
* 'efiemu_prepare' - Finalize loading of EFI emulator.
* 'efiemu_unload' - Unload EFI emulator.
* 'exit' - Exit from VAS_EBOOT.
* 'extract_entries_configfile' - Load another config file but take
only menu entries.
* 'extract_entries_source' - Load another config file without
changing context but take only menu entries.
* 'extract_legacy_entries_configfile' - Parse legacy config in new
context taking only menu entries
* 'extract_legacy_entries_source' - Parse legacy config in same
context taking only menu entries
* 'extract_syslinux_entries_configfile' - Execute syslinux config in
new context taking only menu entries
* 'extract_syslinux_entries_source' - Execute syslinux config in same
context taking only menu entries
* 'fakebios' - Create BIOS-like structures for backward compatibility
with existing OS.
* 'fix_video' - Fix video problem.
* 'fpswa' - Display FPSWA version.
* 'functional_test' - Run all loaded functional tests.
* 'gdbstub_break' - Break into GDB
* 'gdbstub' - Start GDB stub on given port
* 'gdbstub_stop' - Stop GDB stub
* 'hdparm' - Get/set ATA disk parameters.
* 'hexdump_random' - Hexdump random data.
* 'inb' - Read 8-bit value from PORT.
* 'inl' - Read 32-bit value from PORT.
* 'inw' - Read 16-bit value from PORT.
* 'jpegtest' - Tests loading of JPEG bitmap.
* 'keymap' - Load a keyboard layout.
* 'legacy_check_password' - Simulate VasEBoot-legacy 'password' command
in menu entry mode
* 'legacy_configfile' - Parse legacy config in new context
* 'legacy_password' - Simulate VasEBoot-legacy 'password' command
* 'legacy_source' - Parse legacy config in same context
* 'loadbios' - Load BIOS dump.
* 'lsacpi' - Show ACPI information.
* 'lsapm' - Show APM information.
* 'lscoreboot' - List coreboot tables.
* 'lsdev' - List devices.
* 'lsefi' - Display EFI handles.
* 'lsefimmap' - Display EFI memory map.
* 'lsefisystab' - Display EFI system tables.
* 'lsmmap' - List memory map provided by firmware.
* 'lspci' - List PCI devices.
* 'lssal' - Display SAL system table.
* 'lsspd' - Print Memory information.
* 'macppcbless' - Bless DIR of HFS or HFS+ partition for PPC macs.
* 'mactelbless' - Bless FILE of HFS or HFS+ partition for intel macs.
* 'net_set_vlan' - Set an interface's vlan id.
* 'outb' - Write 8-bit VALUE to PORT.
* 'outl' - Write 32-bit VALUE to PORT.
* 'outw' - Write 16-bit VALUE to PORT.
* 'pcidump' - Show raw dump of the PCI configuration space.
* 'pngtest' - Tests loading of PNG bitmap.
* 'read_byte' - Read 8-bit value from ADDR.
* 'read_dword' - Read 32-bit value from ADDR.
* 'read_word' - Read 16-bit value from ADDR.
* 'setpci' - Manipulate PCI devices.
* 'suspend' - Return to IEEE1275 prompt.
* 'syslinux_configfile' - Execute syslinux config in new context
* 'syslinux_source' - Execute syslinux config in same context
* 'test_blockarg' - Print and execute block argument., 0
* 'testload' - Load the same file in multiple ways.
* 'testspeed' - Test file read speed.
* 'tgatest' - Tests loading of TGA bitmap.
* 'time' - Measure time used by COMMAND
* 'tr' - Translate SET1 characters to SET2 in STRING.
* 'usb' - Test USB support.
* 'vbeinfo' - List available video modes. If resolution is given
show only modes matching it.
* 'vbetest' - Test video subsystem.
* 'videotest' - Test video subsystem in mode WxH.
* 'write_byte' - Write 8-bit VALUE to ADDR.
* 'write_dword' - Write 32-bit VALUE to ADDR.
* 'write_word' - Write 16-bit VALUE to ADDR.
* 'xen_cat' - List Xen storage.
* 'xen_ls' - List Xen storage.
* 'xnu_devprop_load' - Load 'device-properties' dump.
* 'xnu_uuid' - Transform 64-bit UUID to format suitable for XNU. If
-l is given keep it lowercase as done by blkid.
* 'zfs-bootfs' - Print ZFS-BOOTFSOBJ or store it into VARIABLE
* 'zfsinfo' - Print ZFS info about DEVICE.
* 'zfskey' - Import ZFS wrapping key stored in FILE.

File: VasEBoot.info, Node: Internationalisation, Next: Security, Prev: Commands, Up: Top
18 Internationalisation
***********************
18.1 Charset
============
VAS_EBOOT uses UTF-8 internally other than in rendering where some
VAS_EBOOT-specific appropriate representation is used. All text files
(including config) are assumed to be encoded in UTF-8.
18.2 Filesystems
================
NTFS, JFS, UDF, HFS+, exFAT, long filenames in FAT, Joliet part of
ISO9660 are treated as UTF-16 as per specification. AFS and BFS are
read as UTF-8, again according to specification. BtrFS, cpio, tar,
squash4, minix, minix2, minix3, ROMFS, ReiserFS, XFS, EROFS, ext2, ext3,
ext4, FAT (short names), F2FS, RockRidge part of ISO9660, nilfs2, UFS1,
UFS2 and ZFS are assumed to be UTF-8. This might be false on systems
configured with legacy charset but as long as the charset used is
superset of ASCII you should be able to access ASCII-named files. And
it's recommended to configure your system to use UTF-8 to access the
filesystem, convmv may help with migration. ISO9660 (plain) filenames
are specified as being ASCII or being described with unspecified escape
sequences. VAS_EBOOT assumes that the ISO9660 names are UTF-8 (since any
ASCII is valid UTF-8). There are some old CD-ROMs which use CP437 in
non-compliant way. You're still able to access files with names
containing only ASCII characters on such filesystems though. You're
also able to access any file if the filesystem contains valid Joliet
(UTF-16) or RockRidge (UTF-8). AFFS, SFS and HFS never use unicode and
VAS_EBOOT assumes them to be in Latin1, Latin1 and MacRoman respectively.
VAS_EBOOT handles filesystem case-insensitivity however no attempt is
performed at case conversion of international characters so e.g. a file
named lowercase greek alpha is treated as different from the one named
as uppercase alpha. The filesystems in questions are NTFS (except POSIX
namespace), HFS+ (configurable at mkfs time, default insensitive), SFS
(configurable at mkfs time, default insensitive), JFS (configurable at
mkfs time, default sensitive), HFS, AFFS, FAT, exFAT and ZFS
(configurable on per-subvolume basis by property "casesensitivity",
default sensitive). On ZFS subvolumes marked as case insensitive files
containing lowercase international characters are inaccessible. Also
like all supported filesystems except HFS+ and ZFS (configurable on
per-subvolume basis by property "normalization", default none) VAS_EBOOT
makes no attempt at check of canonical equivalence so a file name
u-diaresis is treated as distinct from u+combining diaresis. This
however means that in order to access file on HFS+ its name must be
specified in normalisation form D. On normalized ZFS subvolumes
filenames out of normalisation are inaccessible.
18.3 Output terminal
====================
Firmware output console "console" on ARC and IEEE1275 are limited to
ASCII.
BIOS firmware console and VGA text are limited to ASCII and some
pseudographics.
None of above mentioned is appropriate for displaying international
and any unsupported character is replaced with question mark except
pseudographics which we attempt to approximate with ASCII.
EFI console on the other hand nominally supports UTF-16 but actual
language coverage depends on firmware and may be very limited.
The encoding used on serial can be chosen with 'terminfo' as either
ASCII, UTF-8 or "visual UTF-8". Last one is against the specification
but results in correct rendering of right-to-left on some readers which
don't have own bidi implementation.
On emu VAS_EBOOT checks if charset is UTF-8 and uses it if so and uses
ASCII otherwise.
When using gfxterm or gfxmenu VAS_EBOOT itself is responsible for
rendering the text. In this case VAS_EBOOT is limited by loaded fonts. If
fonts contain all required characters then bidirectional text, cursive
variants and combining marks other than enclosing, half (e.g. left half
tilde or combining overline) and double ones. Ligatures aren't
supported though. This should cover European, Middle Eastern (if you
don't mind lack of lam-alif ligature in Arabic) and East Asian scripts.
Notable unsupported scripts are Brahmic family and derived as well as
Mongolian, Tifinagh, Korean Jamo (precomposed characters have no
problem) and tonal writing (2e5-2e9). VAS_EBOOT also ignores deprecated (as
specified in Unicode) characters (e.g. tags). VAS_EBOOT also doesn't handle
so called "annotation characters" If you can complete either of two
lists or, better, propose a patch to improve rendering, please contact
developer team.
18.4 Input terminal
===================
Firmware console on BIOS, IEEE1275 and ARC doesn't allow you to enter
non-ASCII characters. EFI specification allows for such but author is
unaware of any actual implementations. Serial input is currently
limited for latin1 (unlikely to change). Own keyboard implementations
(at_keyboard and usb_keyboard) supports any key but work on
one-char-per-keystroke. So no dead keys or advanced input method. Also
there is no keymap change hotkey. In practice it makes difficult to
enter any text using non-Latin alphabet. Moreover all current input
consumers are limited to ASCII.
18.5 Gettext
============
VAS_EBOOT supports being translated. For this you need to have language *.mo
files in $prefix/locale, load gettext module and set "lang" variable.
18.6 Regexp
===========
Regexps work on unicode characters, however no attempt at checking
canonical equivalence has been made. Moreover the classes like
[:alpha:] match only ASCII subset.
18.7 Other
==========
Currently VAS_EBOOT always uses YEAR-MONTH-DAY HOUR:MINUTE:SECOND [WEEKDAY]
24-hour datetime format but weekdays are translated. VAS_EBOOT always uses
the decimal number format with [0-9] as digits and . as descimal
separator and no group separator. IEEE1275 aliases are matched
case-insensitively except non-ASCII which is matched as binary. Similar
behaviour is for matching OSBundleRequired. Since IEEE1275 aliases and
OSBundleRequired don't contain any non-ASCII it should never be a
problem in practice. Case-sensitive identifiers are matched as raw
strings, no canonical equivalence check is performed. Case-insensitive
identifiers are matched as RAW but additionally [a-z] is equivalent to
[A-Z]. VAS_EBOOT-defined identifiers use only ASCII and so should
user-defined ones. Identifiers containing non-ASCII may work but aren't
supported. Only the ASCII space characters (space U+0020, tab U+000b,
CR U+000d and LF U+000a) are recognised. Other unicode space characters
aren't a valid field separator. 'test' (*note test::) tests <, >, <=,
>=, -pgt and -plt compare the strings in the lexicographical order of
unicode codepoints, replicating the behaviour of test from coreutils.
environment variables and commands are listed in the same order.

File: VasEBoot.info, Node: Security, Next: Platform limitations, Prev: Internationalisation, Up: Top
19 Security
***********
* Menu:
* Authentication and authorisation:: Users and access control
* Using GPG-style digital signatures:: Booting digitally signed code
* Using appended signatures:: An alternative approach to booting digitally signed code
* UEFI secure boot and shim:: Booting digitally signed PE files
* Secure Boot Advanced Targeting:: Embedded information for generation number based revocation
* Measured Boot:: Measuring boot components
* Lockdown:: Lockdown when booting on a secure setup
* TPM2 key protector:: Managing disk key with TPM2 key protector
* Signing certificate and hash files:: Certificate and hash file signing
* Signing VAS_EBOOT itself:: Ensuring the integrity of the VAS_EBOOT core image
* Hardening:: Configuration and customization to maximize security

File: VasEBoot.info, Node: Authentication and authorisation, Next: Using GPG-style digital signatures, Up: Security
19.1 Authentication and authorisation in VAS_EBOOT
=============================================
By default, the boot loader interface is accessible to anyone with
physical access to the console: anyone can select and edit any menu
entry, and anyone can get direct access to a VAS_EBOOT shell prompt. For
most systems, this is reasonable since anyone with direct physical
access has a variety of other ways to gain full access, and requiring
authentication at the boot loader level would only serve to make it
difficult to recover broken systems.
However, in some environments, such as kiosks, it may be appropriate
to lock down the boot loader to require authentication before performing
certain operations.
The 'password' (*note password::) and 'password_pbkdf2' (*note
password_pbkdf2::) commands can be used to define users, each of which
has an associated password. 'password' sets the password in plain text,
requiring 'VasEBoot.cfg' to be secure; 'password_pbkdf2' sets the password
hashed using the Password-Based Key Derivation Function (RFC 2898),
requiring the use of 'VasEBoot-mkpasswd-pbkdf2' (*note Invoking
VasEBoot-mkpasswd-pbkdf2::) to generate password hashes.
In order to enable authentication support, the 'superusers'
environment variable must be set to a list of usernames, separated by
any of spaces, commas, semicolons, pipes, or ampersands. Superusers are
permitted to use the VAS_EBOOT command line, edit menu entries, and execute
any menu entry. If 'superusers' is set, then use of the command line
and editing of menu entries are automatically restricted to superusers.
Setting 'superusers' to empty string effectively disables both access to
CLI and editing of menu entries. Building a VasEBoot image with
'--disable-cli' option will also disable access to CLI and editing of
menu entries, as well as disabling rescue mode. Note: The environment
variable needs to be exported to also affect the section defined by the
'submenu' command (*note submenu::).
Other users may be allowed to execute specific menu entries by giving
a list of usernames (as above) using the '--users' option to the
'menuentry' command (*note menuentry::). If the '--unrestricted' option
is used for a menu entry, then that entry is unrestricted. If the
'--users' option is not used for a menu entry, then that only superusers
are able to use it.
Putting this together, a typical 'VasEBoot.cfg' fragment might look like
this:
set superusers="root"
password_pbkdf2 root VasEBoot.pbkdf2.sha512.10000.biglongstring
password user1 insecure
menuentry "May be run by any user" --unrestricted {
set root=(hd0,1)
linux /vmlinuz
}
menuentry "Superusers only" --users "" {
set root=(hd0,1)
linux /vmlinuz single
}
menuentry "May be run by user1 or a superuser" --users user1 {
set root=(hd0,2)
chainloader +1
}
The 'VasEBoot-mkconfig' program does not yet have built-in support for
generating configuration files with authentication. You can use
'/etc/VasEBoot.d/40_custom' to add simple superuser authentication, by
adding 'set superusers=' and 'password' or 'password_pbkdf2' commands.

File: VasEBoot.info, Node: Using GPG-style digital signatures, Next: Using appended signatures, Prev: Authentication and authorisation, Up: Security
19.2 Using GPG-style digital signatures in VAS_EBOOT
===============================================
VAS_EBOOT's 'core.img' can optionally provide enforcement that all files
subsequently read from disk are covered by a valid digital signature.
This section does *not* cover how to ensure that your platform's
firmware (e.g., Coreboot) validates 'core.img'.
If environment variable 'check_signatures' (*note check_signatures::)
is set to 'enforce', then every attempt by the VAS_EBOOT 'core.img' to load
another file 'foo' implicitly invokes 'verify_detached foo foo.sig'
(*note verify_detached::). 'foo.sig' must contain a valid digital
signature over the contents of 'foo', which can be verified with a
public key currently trusted by VAS_EBOOT (*note list_trusted::, *note
trust::, and *note distrust::). If validation fails, then file 'foo'
cannot be opened. This failure may halt or otherwise impact the boot
process.
An initial trusted public key can be embedded within the VAS_EBOOT
'core.img' using the '--pubkey' option to 'VasEBoot-install' (*note Invoking
VasEBoot-install::).
VAS_EBOOT uses GPG-style detached signatures (meaning that a file
'foo.sig' will be produced when file 'foo' is signed), and currently
supports the DSA and RSA signing algorithms. A signing key can be
generated as follows:
gpg --gen-key
An individual file can be signed as follows:
gpg --detach-sign /path/to/file
For successful validation of all of VAS_EBOOT's subcomponents and the
loaded OS kernel, they must all be signed. One way to accomplish this
is the following (after having already produced the desired 'VasEBoot.cfg'
file, e.g., by running 'VasEBoot-mkconfig' (*note Invoking VasEBoot-mkconfig::):
# Edit /dev/shm/passphrase.txt to contain your signing key's passphrase
for i in `find /boot -name "*.cfg" -or -name "*.lst" -or \
-name "*.mod" -or -name "vmlinuz*" -or -name "initrd*" -or \
-name "VasEBootenv"`;
do
gpg --batch --detach-sign --passphrase-fd 0 $i < \
/dev/shm/passphrase.txt
done
shred /dev/shm/passphrase.txt
See also: *note check_signatures::, *note verify_detached::, *note
trust::, *note list_trusted::, *note distrust::, *note load_env::, *note
save_env::.
Note that internally signature enforcement is controlled by setting
the environment variable 'check_signatures' equal to 'enforce'. Passing
one or more '--pubkey' options to 'VasEBoot-mkimage' implicitly defines
'check_signatures' equal to 'enforce' in 'core.img' prior to processing
any configuration files.
Note that signature checking does *not* prevent an attacker with
(serial, physical, ...) console access from dropping manually to the
VAS_EBOOT console and executing:
set check_signatures=no
To prevent this, password-protection (*note Authentication and
authorisation::) is essential. Note that even with VAS_EBOOT password
protection, VAS_EBOOT itself cannot prevent someone with physical access to
the machine from altering that machine's firmware (e.g., Coreboot or
BIOS) configuration to cause the machine to boot from a different
(attacker-controlled) device. VAS_EBOOT is at best only one link in a secure
boot chain.

File: VasEBoot.info, Node: Using appended signatures, Next: UEFI secure boot and shim, Prev: Using GPG-style digital signatures, Up: Security
19.3 Using appended signatures in VAS_EBOOT
======================================
VAS_EBOOT supports verifying Linux-style 'appended signatures' for Linux on
Power LPAR secure boot. Appended signatures are PKCS#7 messages
containing a signature over the contents of a file, plus some metadata,
appended to the end of a file. A file with an appended signature ends
with the magic string:
~Module signature appended~\n
where '\n' represents the line feed character, '0x0a'.
Linux on Power LPAR secure boot is controlled by *'ibm,secure-boot'*
device tree property and if this property is set to '2' ('enforce'),
VAS_EBOOT enters lockdown mode. There are three secure boot modes. They are
* '0 - disabled': Secure boot is disabled. This is the default.
* '1 - audit': Enforce signature verification by setting
'check_appended_signatures' (*note check_appended_signatures::) to
'yes' and do not enter lockdown mode. Signature verification is
performed and if signature verification fails, display the errors
and allow the boot to continue.
* '2 - enforce': Enter lockdown mode and enforce signature
verification by setting 'check_appended_signatures' (*note
check_appended_signatures::) to 'yes'.
Note that Linux on Power LPAR only supports '0 - disabled' and '2 -
enforce', and '1 - audit' is considered as secure boot being disabled.
Enforcement of signature verification is controlled by the
environment variable 'check_appended_signatures' (*note
check_appended_signatures::).
* 'no': No verification is performed. This is the default.
* 'yes': Signature verification is performed and if signature
verification fails, display the errors and stop the boot.
Signature verification cannot be disabled by setting the
'check_appended_signatures' variable back to 'no'.
To enable appended signature verification, load the appendedsig
module and an X.509 certificate for verification. It is recommended to
build the appendedsig module into the core VAS_EBOOT image.
Key management is controlled by the environment variable
'appendedsig_key_mgmt' (*note appendedsig_key_mgmt::).
* 'static': Enforce static key management signature verification.
This is the default. When VAS_EBOOT is in lockdown mode, then the user
cannot change the value of the 'appendedsig_key_mgmt'.
* 'dynamic': Enforce dynamic key management signature verification.
When VAS_EBOOT is in lockdown mode, then the user cannot change the
value of the 'appendedsig_key_mgmt'.
In static key management mode, certificates will be built into the
core image using the '--x509' parameter to 'VasEBoot-mkimage'. The list of
trusted certificates available at boot time can be shown using
'append_list_db' (*note append_list_db::). Distrusted certificates can
be explicitly removed from the db using 'append_add_dbx_cert' (*note
append_add_dbx_cert::). Also, trusted certificates can be explicitly
added to the db using 'append_add_db_cert' (*note append_add_db_cert::).
In dynamic key management mode, db and dbx are read from the Platform
KeyStore (PKS). If db does not exist in PKS, static keys (built-in keys)
are used as the default keys. The list of trusted certificates and
binary hashes available at boot time can be shown using 'append_list_db'
(*note append_list_db::) and the list of distrusted certificates and
binary/certificate hashes available at boot time can be shown using
'append_list_dbx' (*note append_list_dbx::). The trusted certificates
and binary hashes can be explicitly added to the db using
'append_add_db_cert' (*note append_add_db_cert::) and
'append_add_db_hash' (*note append_add_db_hash::). Distrusted
certificates can be explicitly added to the dbx using
'append_add_dbx_cert' (*note append_add_dbx_cert::) and distrusted
certificate/binary hashes can be explicitly added to the dbx using
'append_add_dbx_hash' (*note append_add_dbx_hash::).
A file can be explicitly verified using 'append_verify' (*note
append_verify::).
Note that when the environment variable 'check_appended_signatures'
is set to 'yes', the 'append_add_db_cert' and 'append_add_dbx_cert'
commands only accept the file 'X509_CERTIFICATE' that is signed with an
appended signature (*note Signing certificate and hash files::), and the
'append_add_db_hash' and 'append_add_dbx_hash' commands only accept the
file 'HASH_FILE' that is signed with an appended signature (*note
Signing certificate and hash files::). The signature is verified by the
appendedsig module. When the environment variable
'check_appended_signatures' is set to 'no', these commands accept files
without an appended signature.
Also, note that 'X509_CERTIFICATE' should be in DER-format and
'HASH_FILE' should be in binary format. Only SHA-256, SHA-384, or
SHA-512 hashes of binary/certificate are allowed. Certificates/hashes
of certificates/binaries added through 'append_add_db_cert',
'append_add_dbx_cert', 'append_add_db_hash', and 'append_add_dbx_hash'
will not be persisted across boots.
Only signatures created using SHA-256 or SHA-512 hash algorithm along
with RSA keys of size 2048, 3072, or 4096 bits are supported.
A file can be signed with the 'sign-file' utility supplied with the
Linux kernel source. For example, if you have 'signing.key' as the
private key and 'certificate.der' as the X.509 certificate containing
the public key:
sign-file SHA256 signing.key certificate.der vmlinux vmlinux.signed
Once signature verification is turned on, the following file types
must carry appended signatures:
1. Linux kernels
2. VAS_EBOOT modules, except those built in to the core image
3. Any new certificate or binary hash files to be trusted
4. Any new certificate/binary hash files to be distrusted
When VAS_EBOOT is in lockdown mode (when secure boot mode is set to
'enforce'), signature verification cannot be *disabled* by setting the
'check_appended_signatures' (*note check_appended_signatures::) variable
to 'no' or using the 'load_env' (*note load_env::) command from the VAS_EBOOT
console.

File: VasEBoot.info, Node: UEFI secure boot and shim, Next: Secure Boot Advanced Targeting, Prev: Using appended signatures, Up: Security
19.4 UEFI secure boot and shim support
======================================
The VAS_EBOOT works with UEFI secure boot and the shim. This functionality
is provided by the shim_lock verifier. It is built into the 'core.img'
and is registered if the UEFI secure boot is enabled. The 'shim_lock'
variable is set to 'y' when shim_lock verifier is registered. If it is
desired to use UEFI secure boot without shim, one can disable shim_lock
by disabling shim verification with MokSbState UEFI variable or by
building VasEBoot image with '--disable-shim-lock' option.
All VAS_EBOOT modules not stored in the 'core.img', OS kernels, ACPI
tables, Device Trees, etc. have to be signed, e.g, using PGP.
Additionally, the commands that can be used to subvert the UEFI secure
boot mechanism, such as 'iorw' and 'memrw' will not be available when
the UEFI secure boot is enabled. This is done for security reasons and
are enforced by the VAS_EBOOT Lockdown mechanism (*note Lockdown::).

File: VasEBoot.info, Node: Secure Boot Advanced Targeting, Next: Measured Boot, Prev: UEFI secure boot and shim, Up: Security
19.5 Embedded information for generation number based revocation
================================================================
The Secure Boot Advanced Targeting (SBAT) is a mechanism to allow the
revocation of components in the boot path by using generation numbers
embedded into the EFI binaries. The SBAT metadata is located in an
.sbat data section that has set of UTF-8 strings as comma-separated
values (CSV). See <https://github.com/rhboot/shim/blob/main/SBAT.md> for
more details.
To add a data section containing the SBAT information into the
binary, the '--sbat' option of 'VasEBoot-mkimage' command should be used.
The content of a CSV file, encoded with UTF-8, is copied as is to the
.sbat data section into the generated EFI binary. The CSV file can be
stored anywhere on the file system.
VasEBoot-mkimage -O x86_64-efi -o VasEBootx64.efi -p '(tftp)/VasEBoot' --sbat sbat.csv efinet tftp

File: VasEBoot.info, Node: Measured Boot, Next: Lockdown, Prev: Secure Boot Advanced Targeting, Up: Security
19.6 Measuring boot components
==============================
If the tpm module is loaded and the platform has a Trusted Platform
Module installed, VAS_EBOOT will log each command executed and each file
loaded into the TPM event log and extend the PCR values in the TPM
correspondingly. All events will be logged into the PCR described below
with a type of EV_IPL and an event description as described below.
Event type PCR Description
---------------------------------------------------------------------------
Command 8 All executed commands (including those
from configuration files) will be logged
and measured as entered with a prefix of
"VasEBoot_cmd: "
Kernel command line 8 Any command line passed to a kernel will
be logged and measured as entered with a
prefix of "kernel_cmdline: "
Module command line 8 Any command line passed to a kernel
module will be logged and measured as
entered with a prefix of "module_cmdline:
"
Files 9 Any file read by VAS_EBOOT will be logged and
measured with a descriptive text
corresponding to the filename.
VAS_EBOOT will not measure its own 'core.img' - it is expected that
firmware will carry this out. VAS_EBOOT will also not perform any
measurements until the tpm module is loaded. As such it is recommended
that the tpm module be built into 'core.img' in order to avoid a
potential gap in measurement between 'core.img' being loaded and the tpm
module being loaded.
Measured boot is currently only supported on EFI and IBM IEEE1275
PowerPC platforms.

File: VasEBoot.info, Node: Lockdown, Next: TPM2 key protector, Prev: Measured Boot, Up: Security
19.7 Lockdown when booting on a secure setup
============================================
The VAS_EBOOT can be locked down when booted on a secure boot environment,
for example if UEFI or Power secure boot is enabled. On a locked down
configuration, the VAS_EBOOT will be restricted and some operations/commands
cannot be executed. This also includes limiting which filesystems are
supported to those thought to be more robust and widely used within
VAS_EBOOT.
The filesystems currently allowed in lockdown mode include:
* BtrFS
* cpio
* exFAT
* Enhanced Read-Only File System (EROFS)
* Linux ext2/ext3/ext4
* F2FS
* DOS FAT12/FAT16/FAT32
* HFS+
* ISO9660
* Squash4
* tar
* XFS
* ZFS
The filesystems currently not allowed in lockdown mode include:
* Amiga Fast FileSystem (AFFS)
* AtheOS File System (AFS)
* Bee File System (BFS)
* Coreboot File System (CBFS)
* Hierarchical File System (HFS)
* Journaled File System (JFS)
* Minix filesystem
* New Implementation of Log filesystem (nilfs2)
* Windows New Technology File System (NTFS)
* ReiserFS
* Read-Only Memory File System (ROMFS)
* Amiga Smart File System (SFS)
* Universal Disk Format (UDF)
* Unix File System (UFS)
The 'lockdown' variable is set to 'y' when the VAS_EBOOT is locked down.
Otherwise it does not exist.

File: VasEBoot.info, Node: TPM2 key protector, Next: Signing certificate and hash files, Prev: Lockdown, Up: Security
19.8 TPM2 key protector in VAS_EBOOT
===============================
TPM2 key protector extends measured boot to unlock the encrypted
partition without user intervention. It uses the TPM Storage Root Key
(SRK) to seal the disk key with a given set of PCR values. If the
system state matches, i.e. PCR values match the sealed PCR set, TPM2
key protector unseals the disk key for 'cryptomount' (*note
cryptomount::) to unlock the encrypted partition. In case the unsealed
key fails to unlock the partition, 'cryptomount' falls back to the
passphrase prompt.
Please note that TPM2 key protector uses the SRK in the owner
hierarchy _without_ authorization. If the owner hierarchy is
password-protected, TPM2 key protector may fail to unseal the key due to
the absence of the password. For the systems that already enable the
password protection for the owner hierarchy, the following command
removes the password protection with the existing password.
# tpm2_changeauth -c owner -p password
There are two supported modes to store the sealed key, SRK and NV
index. The details will be addressed in later sections.
TPM2 key protector is currently only supported on EFI and EMU
platforms.
19.8.1 TPM PCR usage
--------------------
Since TPM2 key protector relies on PCRs to check the system state, it is
important to decide which PCRs to seal the key with. The following
table lists uses of PCRs and the measured objects on EFI platforms.
PCR Used by Measured Objects
--------------------------------------------------------------------------
0 Firmware Core system firmware executable code
1 Firmware Core system firmware data/host platform
configuration; typically contains serial and
model numbers
2 Firmware Extended or pluggable executable code; includes
option ROMs on pluggable hardware
3 Firmware Extended or pluggable firmware data; includes
information about pluggable hardware
4 Firmware Boot loader and additional drivers; binaries and
extensions loaded by the boot loader
5 Firmware GPT/Partition table
7 Firmware SecureBoot state
8 VAS_EBOOT Commands and kernel command line
9 VAS_EBOOT All files read (including kernel image)
9 Linux Kernel All passed initrds (when the new LOAD_FILE2
initrd protocol is used)
10 Linux Kernel Protection of the IMA measurement log
14 shim “MOK” certificates and hashes
PCR 0, 2, 4, and 7 can be used to check the integrity of the firmware
code and bootloaders. PCR 8 and 9 are useful to check the file and data
processed by VAS_EBOOT. PCRs 10, 11, 12, 13, and 15 are controlled by the
operating system, so those PCRs are usually still in the initial state
when VAS_EBOOT is running.
In general, it is nice to include PCR 0, 2, 4, and 7 to ensure the
integrity of the firmware and bootloaders. For PCR 8 and 9, a
sophisticated tool is required to examine the VAS_EBOOT configuration files
and the files to be loaded to calculate the correct PCR values.
Please note that PCRs are sensitive to any change, so an update of a
component could invalidate the sealed key, due to the so-called PCR
brittleness. For the bootloader update, PCR 4 may be affected. This
can be mitigated by extracting the events from the TPM event log and
predict the value with the updated bootloader binary. On the other
hand, it is difficult to predict PCR 0~7 after a firmware update since
the content of the code and the order of drivers may not follow the TPM
event log from the previous firmware version, so it is necessary to
reboot the system to update the measurement results of PCR 0~7 and seal
or sign the sealed key again.
Reference: Linux TPM PCR Registry
(https://uapi-group.org/specifications/specs/linux_tpm_pcr_registry/)
19.8.2 Setting up the extra disk key
------------------------------------
Instead of using the existing password, it is recommended to seal a new
random disk key and use the existing password for recovery.
Here are the sample commands to create a 128 random bytes key file
and enroll the key into the target partition (sda2).
# dd if=/dev/urandom of=luks.key bs=1 count=128
# cryptsetup luksAddKey /dev/sda2 luks.key --pbkdf=pbkdf2 --hash=sha512
19.8.3 SRK mode
---------------
To unlock the partition with SRK mode, assume that the sealed key is in
'(hd0,gpt1)/efi/VasEBoot/sealed.tpm', the following VAS_EBOOT commands unseal the
disk key with SRK mode and supply it to 'cryptomount'.
VasEBoot> tpm2_key_protector_init -T (hd0,gpt1)/efi/VasEBoot/sealed.tpm
VasEBoot> cryptomount -u <UUID> -P tpm2
There are two programs to create the sealed key for SRK mode:
'VasEBoot-protect' and 'pcr-oracle'
(<https://github.com/okirch/pcr-oracle>).
The following sample command uses 'VasEBoot-protect' to seal the random
key, 'luks.key', with PCR 0, 2, 4 and 7 in TPM 2.0 Key File format.
# VasEBoot-protect --action=add \
--protector=tpm2 \
--tpm2-pcrs=0,2,4,7 \
--tpm2key \
--tpm2-keyfile=luks.key \
--tpm2-outfile=/boot/efi/efi/VasEBoot/sealed.tpm
'VasEBoot-protect' only seals the key with the current PCR values.
Therefore, when a boot component, such as shim or VAS_EBOOT, is updated, it
is necessary to reboot the system to update the measurement results and
seal the key again. That means the random disk key has to be stored in
cleartext for the next key sealing. Besides this, the measurement
result of some PCRs may differ between boot time and OS runtime. For
example, PCR 9 measures the files loaded by VAS_EBOOT including the Linux
kernel and initrd. To unlock the disk containing the kernel and initrd,
the key has to be sealed with PCR 9 value before loading the kernel and
initrd. However, PCR 9 changes after VAS_EBOOT loading the kernel and
initrd, so PCR 9 at OS runtime cannot be used directly for key sealing.
To solve these problems, 'pcr-oracle' takes a different approach. It
reads the TPM eventlog and predicts the PCR values. Besides,
'pcr-oracle' also supports "authorized policy" which allows the PCR
policy to be updated with a valid signature, so that the user only seals
the random disk key once. If at some later time the PCR values change
due to an update of the system firmware, bootloader, or config file, the
user just needs to update the signature of the PCR policy.
To seal the key with the authorized policy, the first thing is to
generate the RSA policy key, 'policy-key.pem', and the authorized policy
file, 'authorized.policy'. In this example, PCR 0, 2, 4, 7 and 9 are
chosen for key sealing.
# pcr-oracle --rsa-generate-key \
--private-key policy-key.pem \
--auth authorized.policy \
create-authorized-policy 0,2,4,7,9
Then, we seal the random disk key, 'luks.key', with the authorized
policy file and save the sealed key in 'sealed.key'.
# pcr-oracle --key-format tpm2.0 \
--auth authorized.policy \
--input luks.key \
--output sealed.key \
seal-secret
Since we now have the sealed key, we can remove the random disk key
file 'luks.key'.
The last step is to sign the predicted PCR policy and save the final
key file, 'sealed.tpm'.
# pcr-oracle --key-format tpm2.0 \
--private-key policy-key.pem \
--from eventlog \
--stop-event "VasEBoot-file=VasEBoot.cfg" \
--after \
--input sealed.key \
--output /boot/efi/efi/VasEBoot/sealed.tpm \
sign 0,2,4,7,9
Here we also set a stop event for the prediction. With '--stop-event
VasEBoot-file=VasEBoot.cfg --after', 'pcr-oracle' stops the calculation of PCR
values right after VAS_EBOOT loads 'VasEBoot.cfg'.
When/After the shim or VAS_EBOOT are updated, it only requires to run the
last 'pcr-oracle' command to update the predicted PCR policy.
19.8.4 NV index mode
--------------------
Instead of storing the sealed key in a file, NV index mode uses the TPM
non-volatile memory to store the sealed key and could be useful when
accessing the file is not possible.
However, the Linux root user must be careful who she/he gives access
to the TPM (tss group) since those users will also be able to modify the
NV index that's holding the key.
There are two types of TPM handles supported by NV index mode:
persistent handle and NV index handle.
19.8.4.1 Persistent handle
..........................
The range of persistent handles is from '0x81000000' to '0x81FFFFFF'.
The persistent handle is designed to make TPM objects persistent through
power cycles, and only TPM objects, such as RSA or EC keys, are
accepted. Thus, only the raw format is supported by persistent handles.
The following shows the 'VasEBoot-protect' command to seal the disk key
'luks.key' into the persistent handle '0x81000000' with the PCRs
'0,2,4,7'.
# VasEBoot-protect \
--protector=tpm2 \
--action=add \
--tpm2-bank=sha256 \
--tpm2-pcrs=0,2,4,7 \
--tpm2-keyfile=luks.key \
--tpm2-nvindex=0x81000000
To unseal the key, we have to specify the mode 'nv', the persistent
handle '0x81000000', and the PCRs '0,2,4,7' for the
'tpm2_key_protector_init' command.
VasEBoot> tpm2_key_protector_init --mode=nv --nvindex=0x81000000 --pcrs=0,2,4,7
VasEBoot> cryptomount -u <UUID> --protector tpm2
If the key in the persistent handle becomes unwanted, the following
'VasEBoot-protect' command removes the specified persistent handle
'0x81000000'.
# VasEBoot-protect \
--protector=tpm2 \
--action=remove \
--tpm2-evict \
--tpm2-nvindex=0x81000000
19.8.4.2 NV index handle
........................
The range of NV index handles is from '0x1000000' to '0x1FFFFFF'.
Unlike the persistent handle, the NV index handle allows user-defined
data, so it can easily support both the TPM 2.0 Key File format as well
as the raw format.
The following 'VasEBoot-protect' command seals the disk key 'luks.key'
into the NV index handle '0x1000000' with the PCRs '0,2,4,7' while using
the TPM 2.0 Key File format.
# VasEBoot-protect \
--protector=tpm2 \
--action=add \
--tpm2key \
--tpm2-bank=sha256 \
--tpm2-pcrs=0,2,4,7 \
--tpm2-keyfile=luks.key \
--tpm2-nvindex=0x1000000
Furthermore, it is also possible to insert an existing key file,
'sealed.tpm', into a specific NV index handle using the following
tpm2-tools (<https://github.com/tpm2-software/tpm2-tools>) commands.
# tpm2_nvdefine -C o \
-a "ownerread|ownerwrite" \
-s $(stat -c %s sealed.tpm) \
0x1000000
# tpm2_nvwrite -C o -i sealed.tpm 0x1000000
When unsealing the key in TPM 2.0 Key File format, only the mode 'nv'
and the NV index handle '0x1000000' have to be specified for the
'tpm2_key_protector_init' command.
VasEBoot> tpm2_key_protector_init --mode=nv --nvindex=0x1000000
VasEBoot> cryptomount -u <UUID> --protector tpm2
The following 'VasEBoot-protect' command allows to remove the specified
NV index handle '0x1000000'.
# VasEBoot-protect \
--protector=tpm2 \
--action=remove \
--tpm2-evict \
--tpm2-nvindex=0x1000000
19.8.5 Setting up software TPM for EMU platform
-----------------------------------------------
In order to test TPM2 key protector and TPM2 Software Stack (TSS2), it
is useful to set up a software TPM (swtpm) instance and run the commands
on the EMU platform.
Here are the commands to start a swtpm instance which provides a
character device interface. To store the TPM states, the directory,
'swtpm-state', is created before the 'swtpm' command. All the messages
are stored in 'swtpm.log' including the name of the character device.
# mkdir swtpm-state
# swtpm chardev --vtpm-proxy --tpmstate dir=swtpm-state \
--tpm2 --ctrl type=unixio,path="swtpm-state/ctrl" \
--flags startup-clear --daemon > swtpm.log
Then, we extract the name of the character device from 'swtpm.log'
and save it to the variable, 'tpm2dev'.
# tpm2dev=$(grep "New TPM device" swtpm.log | cut -d' ' -f 4)
Now we can start 'VasEBoot-emu' with '--tpm-device $tpm2dev' to interact
with the swtpm instance.
# VasEBoot-emu --tpm-device $tpm2dev
On the host, the tpm2-tools commands can interact with the swtpm
instance by setting 'TPM2TOOLS_TCTI'.
# export TPM2TOOLS_TCTI="device:$tpm2dev"
When the test is done, use 'swtpm_ioctl' to send the shutdown command
through the swtpm control channel.
# swtpm_ioctl -s --unix swtpm-state/ctrl
19.8.6 Command line and menuentry editor protection
---------------------------------------------------
The TPM key protector provides full disk encryption support on servers
or virtual machine images, meanwhile keeping the boot process
unattended. This prevents service disruptions by eliminating the need
for manual password input during startup, improving system uptime and
continuity. It is achieved by TPM, which verifies the integrity of boot
components by checking cryptographic hashes against securely stored
values, to confirm the disks are unlocked in a trusted state.
However, for users to access the system interactively, some form of
authentication is still required, as the disks are not unlocked by an
authorized user. This raised concerns about using an unprotected
'command-line interface' (*note Command-line interface::), as anyone
could execute commands to access decrypted data. To address this issue,
the LUKS password is used to ensure that only authorized users are
granted access to the interface. Additionally, the 'menu entry editor'
(*note Menu entry editor::) is also safeguarded by the LUKS password, as
modifying a boot entry is effectively the same as altering the
'VasEBoot.cfg' file read from encrypted files.
It is worth mentioning that the built-in password support, as
described in 'Authentication and Authorization in VAS_EBOOT' (*note
Authentication and authorisation::), can also be used to protect the
command-line interface from unauthorized access. However, it is not
recommended to rely on this approach as it is an optional step. Setting
it up requires additional manual intervention, which increases the risk
of password leakage during the process. Moreover, the superuser list
must be well maintained, and the password used cannot be synchronized
with LUKS key rotation.

File: VasEBoot.info, Node: Signing certificate and hash files, Next: Signing VAS_EBOOT itself, Prev: TPM2 key protector, Up: Security
19.9 Signing certificate and hash files
=======================================
X.509 certificate (public key) files and hash files (binary/certificate
hash files) can be signed with a Linux kernel module-style appended
signature.
The signer.key is a private key used for signing and signer.der is
the corresponding public key (certificate) used for appended signature
verification. Note that the signer.der (certificate) should exist in
the db (*note Using appended signatures::).
* Signing the X.509 certificate file using 'sign-file'. The
kernel.der is an X.509 certificate file.
sign-file SHA256 signer.key signer.der kernel.der \
kernel.der.signed
* Signing the hash file using 'sign-file'. The binary_hash.bin is a
binary hash file.
sign-file SHA256 signer.key signer.der binary_hash.bin \
binary_hash.signed

File: VasEBoot.info, Node: Signing VAS_EBOOT itself, Next: Hardening, Prev: Signing certificate and hash files, Up: Security
19.10 Signing VAS_EBOOT itself
=========================
To ensure a complete secure-boot chain, there must be a way for the code
that loads VAS_EBOOT to verify the integrity of the core image. This is
ultimately platform-specific and individual platforms can define their
own mechanisms. However, there are general-purpose mechanisms that can
be used with VAS_EBOOT.
19.10.1 Signing VAS_EBOOT for UEFI secure boot
-----------------------------------------
On UEFI platforms, 'core.img' is a PE binary. Therefore, it can be
signed with a tool such as 'pesign' or 'sbsign'. Refer to the
suggestions in *note UEFI secure boot and shim:: to ensure that the
final image works under UEFI secure boot and can maintain the
secure-boot chain. It will also be necessary to enroll the public key
used into a relevant firmware key database.
19.10.2 Signing VAS_EBOOT with an appended signature
-----------------------------------------------
The 'core.elf' itself can be signed with a Linux kernel module-style
appended signature (*note Using appended signatures::). To support
IEEE1275 platforms where the boot image is often loaded directly from a
disk partition rather than from a file system, the 'core.elf' can
specify the size and location of the appended signature with an ELF Note
added by 'VasEBoot-install' or 'VasEBoot-mkimage'. An image can be signed this
way using the 'sign-file' command from the Linux kernel:
* Signing a VAS_EBOOT image using a single signer key. The VasEBoot.key is
your private key used for VAS_EBOOT signing, VasEBoot.der is a corresponding
public key (certificate) used for VAS_EBOOT signature verification, and
the kernel.der is your public key (certificate) used for kernel
signature verification.
# Determine the size of the appended signature. It depends on the
# signing key and the hash algorithm.
#
# Signing /dev/null with an appended signature.
sign-file SHA256 VasEBoot.key VasEBoot.der /dev/null ./empty.sig
# Build a VAS_EBOOT image for the signature.
VasEBoot-mkimage -O powerpc-ieee1275 -o core.elf.unsigned -x kernel.der \
-p /VasEBoot --appended-signature-size $(stat -c '%s' ./empty.sig) \
--modules="appendedsig ..." ...
# Remove the signature file.
rm ./empty.sig
# Signing a VAS_EBOOT image with an appended signature.
sign-file SHA256 VasEBoot.key VasEBoot.der core.elf.unsigned core.elf.signed
* Signing a VAS_EBOOT image using more than one signer key. The VasEBoot1.key
and VasEBoot2.key are private keys used for VAS_EBOOT signing, VasEBoot1.der and
VasEBoot2.der are corresponding public keys (certificates) used for
VAS_EBOOT signature verification. The kernel1.der and kernel2.der are
your public keys (certificates) used for kernel signature
verification.
# Generate a signature by signing /dev/null.
openssl cms -sign -binary -nocerts -in /dev/null -signer \
VasEBoot1.der -inkey VasEBoot1.key -signer VasEBoot2.der -inkey VasEBoot2.key \
-out ./empty.p7s -outform DER -noattr -md sha256
# To be able to determine the size of an appended signature, sign an
# empty file (/dev/null) to which a signature will be appended to.
sign-file -s ./empty.p7s sha256 /dev/null /dev/null ./empty.sig
# Build a VAS_EBOOT image for the signature.
VasEBoot-mkimage -O powerpc-ieee1275 -o core.elf.unsigned -x kernel1.der \
kernel2.der -p /VasEBoot --appended-signature-size $(stat -c '%s' ./empty.sig) \
--modules="appendedsig ..." ...
# Remove the signature files.
rm ./empty.sig ./empty.p7s
# Generate a raw signature for VAS_EBOOT image signing using OpenSSL.
openssl cms -sign -binary -nocerts -in core.elf.unsigned -signer \
VasEBoot1.der -inkey VasEBoot1.key -signer VasEBoot2.der -inkey VasEBoot2.key \
-out core.p7s -outform DER -noattr -md sha256
# Sign a VAS_EBOOT image to get an image file with an appended signature.
sign-file -s core.p7s sha256 /dev/null core.elf.unsigned core.elf.signed
* Don't forget to install the signed image as required (e.g. on
powerpc-ieee1275, to the PReP partition).
# Install signed VAS_EBOOT image to the PReP partition on powerpc-ieee1275
dd if=core.elf.signed of=/dev/sda1
As with UEFI secure boot, it is necessary to build-in the required
modules, or sign them if they are not part of the VAS_EBOOT image.

File: VasEBoot.info, Node: Hardening, Prev: Signing VAS_EBOOT itself, Up: Security
19.11 Hardening
===============
Security hardening involves additional / optional configuration and
customization steps to VAS_EBOOT to maximize security. The extent to which
hardening can be accomplished depends on the threats attempting to be
mitigated for a given system / device, the device architecture, and
number of VAS_EBOOT features required. The following is a listing of
hardening steps which may be considered:
* (EFI Only) Enable secure boot to enable lockdown mode. This will
limit the attack surface of VAS_EBOOT by limiting the commands and file
systems supported. (*note Lockdown::)
* (EFI Only) No-Execute capability of memory segments will be
configured by VAS_EBOOT as indicated by the UEFI. This makes some
classes of vulnerabilities more difficult to exploit by providing
support for marking memory as either writable or executable.
* (EFI Only) While building VAS_EBOOT, the stack protector feature may be
enabled during the configuration step. This feature can make
certain vulnerabilities caused by stack buffer overflows more
difficult to exploit. This can be enabled by including the
"-enable-stack-protector" flag to the configure script:
# ./configure --enable-stack-protector
Please reference the file 'INSTALL' for detailed instructions on
how to build VAS_EBOOT.
* Minimize the installed modules included with the VAS_EBOOT installation.
For instance, if a specific file system is used for a given system,
modules for other file systems may be excluded. *note Modules::
for a list of modules.
* Minimize boot sources. In the VAS_EBOOT configuration, reduce the
possible boot sources to the minimum needed for system operation.
For instance, if booting only from an internal drive, remove
support for network booting and booting from removable media.
* Disable network support in VAS_EBOOT if not required. Ensure network
interfaces are not configured in the VAS_EBOOT configuration and
consider setting environment variable 'feature_net_search_cfg' to
'n' in an embedded VAS_EBOOT config file in order to disable attempting
to use the network for obtaining a VAS_EBOOT config file.

File: VasEBoot.info, Node: Platform limitations, Next: Platform-specific operations, Prev: Security, Up: Top
20 Platform limitations
***********************
VAS_EBOOT2 is designed to be portable and is actually ported across
platforms. We try to keep all platforms at the level. Unfortunately
some platforms are better supported than others. This is detailed in
current and 2 following sections.
All platforms have an artificially VAS_EBOOT imposed disk size restriction
of 1 EiB. In some cases, larger disk sizes can be used, but access will
not be allowed beyond 1 EiB.
LUKS2 devices with size larger than 16 EiB are currently not
supported. They can not be created as crypto devices by cryptomount, so
can not even be partially read from. LUKS have no limitations other
than those imposed by the format.
ARC platform is unable to change datetime (firmware doesn't seem to
provide a function for it). EMU has similar limitation.
On EMU platform no serial port is available.
Console charset refers only to firmware-assisted console. gfxterm is
always Unicode (see Internationalisation section for its limitations).
Serial is configurable to UTF-8 or ASCII (see Internationalisation). In
case of qemu and coreboot ports the referred console is vga_text.
Loongson always uses gfxterm.
Most limited one is ASCII. CP437 provides additionally
pseudographics. VAS_EBOOT2 doesn't use any language characters from CP437 as
often CP437 is replaced by national encoding compatible only in
pseudographics. Unicode is the most versatile charset which supports
many languages. However the actual console may be much more limited
depending on firmware
On BIOS, network is supported only if the image is loaded through
network. On sparc64, VAS_EBOOT is unable to determine which server it was
booted from.
Direct ATA/AHCI support allows to circumvent various firmware
limitations but isn't needed for normal operation except on baremetal
ports.
AT keyboard support allows keyboard layout remapping and support for
keys not available through firmware. It isn't needed for normal
operation except baremetal ports.
Speaker allows morse and spkmodem communication.
USB support provides benefits similar to ATA (for USB disks) or AT
(for USB keyboards). In addition it allows USBserial.
Chainloading refers to the ability to load another bootloader through
the same protocol and on some platforms, like EFI, allow that bootloader
to return to the VAS_EBOOT.
Hints allow faster disk discovery by already knowing in advance which
is the disk in question. On some platforms hints are correct unless you
move the disk between boots. On other platforms it's just an educated
guess. Note that hint failure results in just reduced performance, not
a failure
BadRAM is the ability to mark some of the RAM as "bad". Note: due to
protocol limitations mips-loongson (with Linux protocol) and
mips-qemu_mips can use only memory up to first hole.
Bootlocation is ability of VAS_EBOOT to automatically detect where it
boots from. "disk" means the detection is limited to detecting the disk
with partition being discovered on install time. "partition" means that
disk and partiton can be automatically discovered. "file" means that
boot image file name as well as disk and partition can be discovered.
For consistency, default install ignores partition and relies solely on
disk detection. If no bootlocation discovery is available or boot and
VasEBoot-root disks are different, UUID is used instead. On ARC if no
device to install to is specified, UUID is used instead as well.
BIOS Coreboot Multiboot Qemu
video yes yes yes yes
console CP437 CP437 CP437 CP437
charset
network yes (*) no no no
ATA/AHCI yes yes yes yes
AT keyboard yes yes yes yes
Speaker yes yes yes yes
USB yes yes yes yes
chainloader local yes yes no
cpuid partial partial partial partial
rdmsr partial partial partial partial
wrmsr partial partial partial partial
hints guess guess guess guess
PCI yes yes yes yes
badram yes yes yes yes
compression always pointless no no
exit yes no no no
bootlocation disk no no no
ia32 EFI amd64 EFI ia32 Itanium
IEEE1275
video yes yes no no
console Unicode Unicode ASCII Unicode
charset
network yes yes yes yes
ATA/AHCI yes yes yes no
AT keyboard yes yes yes no
Speaker yes yes yes no
USB yes yes yes no
chainloader local local no local
cpuid partial partial partial no
rdmsr partial partial partial no
wrmsr partial partial partial no
hints guess guess good guess
PCI yes yes yes no
badram yes yes no yes
compression no no no no
exit yes yes yes yes
bootlocation file file file, file
ignored
Loongson sparc64 Powerpc ARC
video yes no yes no
console N/A ASCII ASCII ASCII
charset
network no yes (*) yes no
ATA/AHCI yes no no no
AT keyboard yes no no no
Speaker no no no no
USB yes no no no
chainloader yes no no no
cpuid no no no no
rdmsr no no no no
wrmsr no no no no
hints good good good no
PCI yes no no no
badram yes (*) no no no
compression configurable no no configurable
exit no yes yes yes
bootlocation no partition file file (*)
MIPS qemu emu xen
video no yes no
console CP437 Unicode (*) ASCII
charset
network no yes no
ATA/AHCI yes no no
AT keyboard yes no no
Speaker no no no
USB N/A yes no
chainloader yes no yes
cpuid no no yes
rdmsr no no yes
wrmsr no no yes
hints guess no no
PCI no no no
badram yes (*) no no
compression configurable no no
exit no yes no
bootlocation no file no

File: VasEBoot.info, Node: Platform-specific operations, Next: Supported kernels, Prev: Platform limitations, Up: Top
21 Platform-specific operations
*******************************
Some platforms have features which allow implementation of certain
commands that cannot be implemented on others.
Quick summary:
Information retrieval:
* mipsel-loongson: lsspd
* mips-arc: lsdev
* efi: lsefisystab, lssal, lsefimmap, lsefi
* i386-pc: lsapm
* i386-coreboot: lscoreboot, coreboot_boottime, cbmemc
* acpi-enabled (i386-pc, i386-coreboot, i386-multiboot, *-efi):
lsacpi
Workarounds for platform-specific issues:
* i386-efi/x86_64-efi: loadbios, fakebios, fix_video
* acpi-enabled (i386-pc, i386-coreboot, i386-multiboot, *-efi): acpi
(override ACPI tables)
* i386-pc: drivemap
* i386-pc: sendkey
Advanced operations for power users:
* x86: iorw (direct access to I/O ports)
Miscellaneous:
* cmos (x86-*, ieee1275, mips-qemu_mips, mips-loongson): cmostest
(used on some laptops to check for special power-on key), cmosclean
* i386-pc: play

File: VasEBoot.info, Node: Supported kernels, Next: Troubleshooting, Prev: Platform-specific operations, Up: Top
22 Supported boot targets
*************************
X86 support is summarised in the following table. "Yes" means that the
kernel works on the given platform, "crashes" means an early kernel
crash which we hope will be fixed by concerned kernel developers. "no"
means VAS_EBOOT doesn't load the given kernel on a given platform.
"headless" means that the kernel works but lacks console drivers (you
can still use serial or network console). In case of "no" and "crashes"
the reason is given in footnote.
BIOS Coreboot
BIOS chainloading yes no (1)
NTLDR yes no (1)
Plan9 yes no (1)
Freedos yes no (1)
FreeBSD bootloader yes crashes (1)
32-bit kFreeBSD yes crashes (5)
64-bit kFreeBSD yes crashes (5)
32-bit kNetBSD yes crashes (1)
64-bit kNetBSD yes crashes
32-bit kOpenBSD yes yes
64-bit kOpenBSD yes yes
Multiboot yes yes
Multiboot2 yes yes
32-bit Linux (legacy protocol) yes no (1)
64-bit Linux (legacy protocol) yes no (1)
32-bit Linux (modern protocol) yes yes
64-bit Linux (modern protocol) yes yes
32-bit XNU yes ?
64-bit XNU yes ?
32-bit EFI chainloader no (2) no (2)
64-bit EFI chainloader no (2) no (2)
Appleloader no (2) no (2)
Multiboot Qemu
BIOS chainloading no (1) no (1)
NTLDR no (1) no (1)
Plan9 no (1) no (1)
FreeDOS no (1) no (1)
FreeBSD bootloader crashes (1) crashes (1)
32-bit kFreeBSD crashes (5) crashes (5)
64-bit kFreeBSD crashes (5) crashes (5)
32-bit kNetBSD crashes (1) crashes (1)
64-bit kNetBSD yes yes
32-bit kOpenBSD yes yes
64-bit kOpenBSD yes yes
Multiboot yes yes
Multiboot2 yes yes
32-bit Linux (legacy protocol) no (1) no (1)
64-bit Linux (legacy protocol) no (1) no (1)
32-bit Linux (modern protocol) yes yes
64-bit Linux (modern protocol) yes yes
32-bit XNU ? ?
64-bit XNU ? ?
32-bit EFI chainloader no (2) no (2)
64-bit EFI chainloader no (2) no (2)
Appleloader no (2) no (2)
ia32 EFI amd64 EFI
BIOS chainloading no (1) no (1)
NTLDR no (1) no (1)
Plan9 no (1) no (1)
FreeDOS no (1) no (1)
FreeBSD bootloader crashes (1) crashes (1)
32-bit kFreeBSD headless headless
64-bit kFreeBSD headless headless
32-bit kNetBSD crashes (1) crashes (1)
64-bit kNetBSD yes yes
32-bit kOpenBSD headless headless
64-bit kOpenBSD headless headless
Multiboot yes yes
Multiboot2 yes yes
32-bit Linux (legacy protocol) no (1) no (1)
64-bit Linux (legacy protocol) no (1) no (1)
32-bit Linux (modern protocol) yes yes
64-bit Linux (modern protocol) yes yes
32-bit XNU yes yes
64-bit XNU yes (4) yes
32-bit EFI chainloader yes no (3)
64-bit EFI chainloader no (3) yes
Appleloader yes yes
ia32 IEEE1275
BIOS chainloading no (1)
NTLDR no (1)
Plan9 no (1)
FreeDOS no (1)
FreeBSD bootloader crashes (1)
32-bit kFreeBSD crashes (5)
64-bit kFreeBSD crashes (5)
32-bit kNetBSD crashes (1)
64-bit kNetBSD ?
32-bit kOpenBSD ?
64-bit kOpenBSD ?
Multiboot ?
Multiboot2 ?
32-bit Linux (legacy protocol) no (1)
64-bit Linux (legacy protocol) no (1)
32-bit Linux (modern protocol) ?
64-bit Linux (modern protocol) ?
32-bit XNU ?
64-bit XNU ?
32-bit EFI chainloader no (2)
64-bit EFI chainloader no (2)
Appleloader no (2)
1. Requires BIOS
2. EFI only
3. 32-bit and 64-bit EFI have different structures and work in
different CPU modes so it's not possible to chainload 32-bit
bootloader on 64-bit platform and vice-versa
4. Some modules may need to be disabled
5. Requires ACPI
PowerPC, IA64 and Sparc64 ports support only Linux. MIPS port
supports Linux and multiboot2.
22.1 Boot tests
===============
As you have seen in previous chapter the support matrix is pretty big
and some of the configurations are only rarely used. To ensure the
quality bootchecks are available for all x86 targets except EFI
chainloader, Appleloader and XNU. All x86 platforms have bootcheck
facility except ieee1275. Multiboot, multiboot2, BIOS chainloader,
ntldr and freebsd-bootloader boot targets are tested only with a fake
kernel images. Only Linux is tested among the payloads using Linux
protocols.
Following variables must be defined:
VAS_EBOOT_PAYLOADS_DIR directory containing the required kernels
VAS_EBOOT_CBFSTOOL cbfstool from Coreboot package (for coreboot
platform only)
VAS_EBOOT_COREBOOT_ROM empty Coreboot ROM
VAS_EBOOT_QEMU_OPTS additional options to be supplied to QEMU
Required files are:
kfreebsd_env.i386 32-bit kFreeBSD device hints
kfreebsd.i386 32-bit FreeBSD kernel image
kfreebsd.x86_64, same from 64-bit kFreeBSD
kfreebsd_env.x86_64
knetbsd.i386 32-bit NetBSD kernel image
knetbsd.miniroot.i386 32-bit kNetBSD miniroot.kmod.
knetbsd.x86_64, same from 64-bit kNetBSD
knetbsd.miniroot.x86_64
kopenbsd.i386 32-bit OpenBSD kernel bsd.rd image
kopenbsd.x86_64 same from 64-bit kOpenBSD
linux.i386 32-bit Linux
linux.x86_64 64-bit Linux

File: VasEBoot.info, Node: Troubleshooting, Next: User-space utilities, Prev: Supported kernels, Up: Top
23 Error messages produced by VAS_EBOOT
**********************************
* Menu:
* VAS_EBOOT only offers a rescue shell::
* Firmware stalls instead of booting VAS_EBOOT::

File: VasEBoot.info, Node: VAS_EBOOT only offers a rescue shell, Next: Firmware stalls instead of booting VAS_EBOOT, Up: Troubleshooting
23.1 VAS_EBOOT only offers a rescue shell
====================================
VAS_EBOOT's normal start-up procedure involves setting the 'prefix'
environment variable to a value set in the core image by 'VasEBoot-install',
setting the 'root' variable to match, loading the 'normal' module from
the prefix, and running the 'normal' command (*note normal::). This
command is responsible for reading '/boot/VasEBoot/VasEBoot.cfg', running the
menu, and doing all the useful things VAS_EBOOT is supposed to do.
If, instead, you only get a rescue shell, this usually means that
VAS_EBOOT failed to load the 'normal' module for some reason. It may be
possible to work around this temporarily: for instance, if the reason
for the failure is that 'prefix' is wrong (perhaps it refers to the
wrong device, or perhaps the path to '/boot/VasEBoot' was not correctly made
relative to the device), then you can correct this and enter normal mode
manually:
# Inspect the current prefix (and other preset variables):
set
# Find out which devices are available:
ls
# Set to the correct value, which might be something like this:
set prefix=(hd0,1)/VasEBoot
set root=(hd0,1)
insmod normal
normal
However, any problem that leaves you in the rescue shell probably
means that VAS_EBOOT was not correctly installed. It may be more useful to
try to reinstall it properly using 'VasEBoot-install DEVICE' (*note Invoking
VasEBoot-install::). When doing this, there are a few things to remember:
* Drive ordering in your operating system may not be the same as the
boot drive ordering used by your firmware. Do not assume that your
first hard drive (e.g. '/dev/sda') is the one that your firmware
will boot from. 'device.map' (*note Device map::) can be used to
override this, but it is usually better to use UUIDs or file system
labels and avoid depending on drive ordering entirely.
* At least on BIOS systems, if you tell 'VasEBoot-install' to install
VAS_EBOOT to a partition but VAS_EBOOT has already been installed in the
master boot record, then the VAS_EBOOT installation in the partition
will be ignored.
* If possible, it is generally best to avoid installing VAS_EBOOT to a
partition (unless it is a special partition for the use of VAS_EBOOT
alone, such as the BIOS Boot Partition used on GPT). Doing this
means that VAS_EBOOT may stop being able to read its core image due to a
file system moving blocks around, such as while defragmenting,
running checks, or even during normal operation. Installing to the
whole disk device is normally more robust.
* Check that VAS_EBOOT actually knows how to read from the device and file
system containing '/boot/VasEBoot'. It will not be able to read from
encrypted devices with unsupported encryption scheme, nor from file
systems for which support has not yet been added to VAS_EBOOT.

File: VasEBoot.info, Node: Firmware stalls instead of booting VAS_EBOOT, Prev: VAS_EBOOT only offers a rescue shell, Up: Troubleshooting
23.2 Firmware stalls instead of booting VAS_EBOOT
============================================
The EFI implementation of some older MacBook laptops stalls when it gets
presented a VasEBoot-mkrescue ISO image for x86_64-efi target on an USB
stick. Affected are models of year 2010 or earlier. Workaround is to
zeroize the bytes 446 to 461 of the EFI partition, where mformat has put
a partition table entry which claims partition start at block 0. This
change will not hamper bootability on other machines.

File: VasEBoot.info, Node: User-space utilities, Next: Obtaining and Building VAS_EBOOT, Prev: Troubleshooting, Up: Top
24 User-space utilities
***********************
* Menu:
* Invoking VasEBoot-install:: How to use the VAS_EBOOT installer
* Invoking VasEBoot-mkconfig:: Generate a VAS_EBOOT configuration file
* Invoking VasEBoot-mkpasswd-pbkdf2::
Generate VAS_EBOOT password hashes
* Invoking VasEBoot-mkrelpath:: Make system path relative to its root
* Invoking VasEBoot-mkrescue:: Make a VAS_EBOOT rescue image
* Invoking VasEBoot-mount:: Mount a file system using VAS_EBOOT
* Invoking VasEBoot-probe:: Probe device information for VAS_EBOOT
* Invoking VasEBoot-protect:: Protect a disk key with a key protector
* Invoking VasEBoot-script-check:: Check VAS_EBOOT script file for syntax errors

File: VasEBoot.info, Node: Invoking VasEBoot-install, Next: Invoking VasEBoot-mkconfig, Up: User-space utilities
24.1 Invoking VasEBoot-install
==========================
The program 'VasEBoot-install' generates a VAS_EBOOT core image using
'VasEBoot-mkimage' and installs it on your system. You must specify the
device name on which you want to install VAS_EBOOT, like this:
VasEBoot-install INSTALL_DEVICE
The device name INSTALL_DEVICE is an OS device name or a VAS_EBOOT device
name.
'VasEBoot-install' accepts the following options:
'--help'
Print a summary of the command-line options and exit.
'--version'
Print the version number of VAS_EBOOT and exit.
'--boot-directory=DIR'
Install VAS_EBOOT images under the directory 'DIR/VasEBoot/' This option is
useful when you want to install VAS_EBOOT into a separate partition or a
removable disk. If this option is not specified then it defaults
to '/boot', so
VasEBoot-install /dev/sda
is equivalent to
VasEBoot-install --boot-directory=/boot/ /dev/sda
Here is an example in which you have a separate "boot" partition
which is mounted on '/mnt/boot':
VasEBoot-install --boot-directory=/mnt/boot /dev/sdb
'--recheck'
Recheck the device map, even if '/boot/VasEBoot/device.map' already
exists. You should use this option whenever you add/remove a disk
into/from your computer.
'--no-rs-codes'
By default on x86 BIOS systems, 'VasEBoot-install' will use some extra
space in the bootloader embedding area for Reed-Solomon
error-correcting codes. This enables VAS_EBOOT to still boot
successfully if some blocks are corrupted. The exact amount of
protection offered is dependent on available space in the embedding
area. R sectors of redundancy can tolerate up to R/2 corrupted
sectors. This redundancy may be cumbersome if attempting to
cryptographically validate the contents of the bootloader embedding
area, or in more modern systems with GPT-style partition tables
(*note BIOS installation::) where VAS_EBOOT does not reside in any
unpartitioned space outside of the MBR. Disable the Reed-Solomon
codes with this option.

File: VasEBoot.info, Node: Invoking VasEBoot-mkconfig, Next: Invoking VasEBoot-mkpasswd-pbkdf2, Prev: Invoking VasEBoot-install, Up: User-space utilities
24.2 Invoking VasEBoot-mkconfig
===========================
The program 'VasEBoot-mkconfig' generates a configuration file for VAS_EBOOT
(*note Simple configuration::).
VasEBoot-mkconfig -o /boot/VasEBoot/VasEBoot.cfg
'VasEBoot-mkconfig' accepts the following options:
'--help'
Print a summary of the command-line options and exit.
'--version'
Print the version number of VAS_EBOOT and exit.
'-o FILE'
'--output=FILE'
Send the generated configuration file to FILE. The default is to
send it to standard output.

File: VasEBoot.info, Node: Invoking VasEBoot-mkpasswd-pbkdf2, Next: Invoking VasEBoot-mkrelpath, Prev: Invoking VasEBoot-mkconfig, Up: User-space utilities
24.3 Invoking VasEBoot-mkpasswd-pbkdf2
==================================
The program 'VasEBoot-mkpasswd-pbkdf2' generates password hashes for VAS_EBOOT
(*note Security::).
VasEBoot-mkpasswd-pbkdf2
'VasEBoot-mkpasswd-pbkdf2' accepts the following options:
'-c NUMBER'
'--iteration-count=NUMBER'
Number of iterations of the underlying pseudo-random function.
Defaults to 10000.
'-l NUMBER'
'--buflen=NUMBER'
Length of the generated hash. Defaults to 64.
'-s NUMBER'
'--salt=NUMBER'
Length of the salt. Defaults to 64.

File: VasEBoot.info, Node: Invoking VasEBoot-mkrelpath, Next: Invoking VasEBoot-mkrescue, Prev: Invoking VasEBoot-mkpasswd-pbkdf2, Up: User-space utilities
24.4 Invoking VasEBoot-mkrelpath
============================
The program 'VasEBoot-mkrelpath' makes a file system path relative to the
root of its containing file system. For instance, if '/usr' is a mount
point, then:
$ VasEBoot-mkrelpath /usr/share/VasEBoot/unicode.pf2
'/share/VasEBoot/unicode.pf2'
This is mainly used internally by other VAS_EBOOT utilities such as
'VasEBoot-mkconfig' (*note Invoking VasEBoot-mkconfig::), but may occasionally
also be useful for debugging.
'VasEBoot-mkrelpath' accepts the following options:
'--help'
Print a summary of the command-line options and exit.
'--version'
Print the version number of VAS_EBOOT and exit.

File: VasEBoot.info, Node: Invoking VasEBoot-mkrescue, Next: Invoking VasEBoot-mount, Prev: Invoking VasEBoot-mkrelpath, Up: User-space utilities
24.5 Invoking VasEBoot-mkrescue
===========================
The program 'VasEBoot-mkrescue' generates a bootable VAS_EBOOT rescue image
(*note Making a VAS_EBOOT bootable CD-ROM::).
VasEBoot-mkrescue -o VasEBoot.iso
All arguments not explicitly listed as 'VasEBoot-mkrescue' options are
passed on directly to 'xorriso' in 'mkisofs' emulation mode. Options
passed to 'xorriso' will normally be interpreted as 'mkisofs' options;
if the option '--' is used, then anything after that will be interpreted
as native 'xorriso' options.
Non-option arguments specify additional source directories. This is
commonly used to add extra files to the image:
mkdir -p disk/boot/VasEBoot
(add extra files to 'disk/boot/VasEBoot')
VasEBoot-mkrescue -o VasEBoot.iso disk
'VasEBoot-mkrescue' accepts the following options:
'--help'
Print a summary of the command-line options and exit.
'--version'
Print the version number of VAS_EBOOT and exit.
'-o FILE'
'--output=FILE'
Save output in FILE. This "option" is required.
'--modules=MODULES'
Pre-load the named VAS_EBOOT modules in the image. Multiple entries in
MODULES should be separated by whitespace (so you will probably
need to quote this for your shell).
'--rom-directory=DIR'
If generating images for the QEMU or Coreboot platforms, copy the
resulting 'qemu.img' or 'coreboot.elf' files respectively to the
DIR directory as well as including them in the image.
'--xorriso=FILE'
Use FILE as the 'xorriso' program, rather than the built-in
default.
'--VasEBoot-mkimage=FILE'
Use FILE as the 'VasEBoot-mkimage' program, rather than the built-in
default.

File: VasEBoot.info, Node: Invoking VasEBoot-mount, Next: Invoking VasEBoot-probe, Prev: Invoking VasEBoot-mkrescue, Up: User-space utilities
24.6 Invoking VasEBoot-mount
========================
The program 'VasEBoot-mount' performs a read-only mount of any file system
or file system image that VAS_EBOOT understands, using VAS_EBOOT's file system
drivers via FUSE. (It is only available if FUSE development files were
present when VAS_EBOOT was built.) This has a number of uses:
* It provides a convenient way to check how VAS_EBOOT will view a file
system at boot time. You can use normal command-line tools to
compare that view with that of your operating system, making it
easy to find bugs.
* It offers true read-only mounts. Linux does not have these for
journalling file systems, because it will always attempt to replay
the journal at mount time; while you can temporarily mark the block
device read-only to avoid this, that causes the mount to fail.
Since VAS_EBOOT intentionally contains no code for writing to file
systems, it can easily provide a guaranteed read-only mount
mechanism.
* It allows you to examine any file system that VAS_EBOOT understands
without needing to load additional modules into your running
kernel, which may be useful in constrained environments such as
installers.
* Since it can examine file system images (contained in regular
files) just as easily as file systems on block devices, you can use
it to inspect any file system image that VAS_EBOOT understands with only
enough privileges to use FUSE, even if nobody has yet written a
FUSE module specifically for that file system type.
Using 'VasEBoot-mount' is normally as simple as:
VasEBoot-mount /dev/sda1 /mnt
'VasEBoot-mount' must be given one or more images and a mount point as
non-option arguments (if it is given more than one image, it will treat
them as a RAID set), and also accepts the following options:
'--help'
Print a summary of the command-line options and exit.
'--version'
Print the version number of VAS_EBOOT and exit.
'-C'
'--crypto'
Mount encrypted devices, prompting for a passphrase if necessary.
'-d STRING'
'--debug=STRING'
Show debugging output for conditions matching STRING.
'-K prompt|FILE'
'--zfs-key=prompt|FILE'
Load a ZFS encryption key. If you use 'prompt' as the argument,
'VasEBoot-mount' will read a passphrase from the terminal; otherwise,
it will read key material from the specified file.
'-r DEVICE'
'--root=DEVICE'
Set the VAS_EBOOT root device to DEVICE. You do not normally need to
set this; 'VasEBoot-mount' will automatically set the root device to
the root of the supplied file system.
If DEVICE is just a number, then it will be treated as a partition
number within the supplied image. This means that, if you have an
image of an entire disk in 'disk.img', then you can use this
command to mount its second partition:
VasEBoot-mount -r 2 disk.img mount-point
'-v'
'--verbose'
Print verbose messages.

File: VasEBoot.info, Node: Invoking VasEBoot-probe, Next: Invoking VasEBoot-protect, Prev: Invoking VasEBoot-mount, Up: User-space utilities
24.7 Invoking VasEBoot-probe
========================
The program 'VasEBoot-probe' probes device information for a given path or
device.
VasEBoot-probe --target=fs /boot/VasEBoot
VasEBoot-probe --target=drive --device /dev/sda1
'VasEBoot-probe' must be given a path or device as a non-option argument,
and also accepts the following options:
'--help'
Print a summary of the command-line options and exit.
'--version'
Print the version number of VAS_EBOOT and exit.
'-d'
'--device'
If this option is given, then the non-option argument is a system
device name (such as '/dev/sda1'), and 'VasEBoot-probe' will print
information about that device. If it is not given, then the
non-option argument is a filesystem path (such as '/boot/VasEBoot'),
and 'VasEBoot-probe' will print information about the device containing
that part of the filesystem.
'-m FILE'
'--device-map=FILE'
Use FILE as the device map (*note Device map::) rather than the
default, usually '/boot/VasEBoot/device.map'.
'-t TARGET'
'--target=TARGET'
Print information about the given path or device as defined by
TARGET. The available targets and their meanings are:
'fs'
VAS_EBOOT filesystem module.
'fs_uuid'
Filesystem Universally Unique Identifier (UUID).
'fs_label'
Filesystem label.
'drive'
VAS_EBOOT device name.
'device'
System device name.
'partmap'
VAS_EBOOT partition map module.
'abstraction'
VAS_EBOOT abstraction module (e.g. 'lvm').
'cryptodisk_uuid'
Crypto device UUID.
'msdos_parttype'
MBR partition type code (two hexadecimal digits).
'hints_string'
A string of platform search hints suitable for passing to the
'search' command (*note search::).
'bios_hints'
Search hints for the PC BIOS platform.
'ieee1275_hints'
Search hints for the IEEE1275 platform.
'baremetal_hints'
Search hints for platforms where disks are addressed directly
rather than via firmware.
'efi_hints'
Search hints for the EFI platform.
'arc_hints'
Search hints for the ARC platform.
'compatibility_hint'
A guess at a reasonable VAS_EBOOT drive name for this device, which
may be used as a fallback if the 'search' command fails.
'disk'
System device name for the whole disk.
'-v'
'--verbose'
Print verbose messages.

File: VasEBoot.info, Node: Invoking VasEBoot-protect, Next: Invoking VasEBoot-script-check, Prev: Invoking VasEBoot-probe, Up: User-space utilities
24.8 Invoking VasEBoot-protect
==========================
The program 'VasEBoot-protect' protects a disk encryption key with a
specified key protector.
'--help'
Print a summary of the command-line options and exit.
'--version'
Print the version number of VAS_EBOOT and exit.
'-a add|remove'
'--action=add|remove'
Add or remove a key protector to or from a key.
'-p PROTECTOR'
'--protector=PROTECTOR'
Set the key protector. Currently, 'tpm2' is the only supported key
protector.
'--tpm2-asymmetric=TYPE'
Choose the the type of SRK. The valid options are 'RSA' ('RSA2048')
and 'ECC' ('ECC_NIST_P256').(default: 'ECC')
'--tpm2-bank=ALG'
Choose bank of PCRs used to authorize key release: 'SHA1',
'SHA256', 'SHA384', or 'SHA512'. (default: 'SHA256')
'--tpm2-device=DEVICE'
Set the path to the TPM2 device. (default: '/dev/tpm0')
'--tpm2-evict'
Evict a previously persisted SRK from the TPM, if any.
'--tpm2-keyfile=FILE'
Set the path to a file that contains the cleartext key to protect.
'--tpm2-outfile=FILE'
Set the path to the file that will contain the key after sealing
(must be accessible to VAS_EBOOT during boot).
'--tpm2-pcrs=PCRS'
Set a comma-separated list of PCRs used to authorize key release
e.g., '7,11'. Please be aware that PCR 0~7 are used by the
firmware and the measurement result may change after a firmware
update (for baremetal systems) or a package (OVMF/SLOF) update in
the VM host. This may lead to the failure of key unsealing.
(default: '7')
'--tpm2-srk=HANDLE'
Set the SRK handle, e.g. '0x81000000', if the SRK is to be made
persistent.
'--tpm2-nvindex=HANDLE'
Set the handle, e.g. '0x81000000' or '0x1000000', for NV index
mode.
'--tpm2key'
Use TPM 2.0 Key File format.
24.8.1 'Add' action
-------------------
Before sealing the key, please check the TPM PCR usage (*note TPM PCR
usage: TPM2 key protector.) to choose a proper set of PCRs.
Assume that there is a key file, 'luks.key', to be sealed with PCR 0,
2, 4, and 7, and here is the 'VasEBoot-protect' command to create the sealed
key file:
# VasEBoot-protect --action=add \
--protector=tpm2 \
--tpm2-pcrs=0,2,4,7 \
--tpm2key \
--tpm2-keyfile=luks.key \
--tpm2-outfile=/boot/efi/efi/VasEBoot/sealed.tpm
Then, VAS_EBOOT can unlock the target partition with the following
commands:
VasEBoot> tpm2_key_protector_init -T (hd0,gpt1)/efi/VasEBoot/sealed.tpm
VasEBoot> cryptomount -u <UUID> -P tpm2
Besides writing the PCR-sealed key into a file, 'VasEBoot-protect' can
write the sealed key into TPM non-volatile memory. Here is the
'VasEBoot-protect' command to write the sealed key into the NV index handle
'0x1000000'.
# VasEBoot-protect --action=add \
--protector=tpm2 \
--tpm2-pcrs=0,2,4,7 \
--tpm2key \
--tpm2-keyfile=luks.key \
--tpm2-nvindex=0x1000000
Later, VAS_EBOOT can fetch the key from '0x1000000'.
VasEBoot> tpm2_key_protector_init --mode=nv --nvindex=0x1000000
VasEBoot> cryptomount -u <UUID> -P tpm2
In most of cases, the user only needs to create the key with the
'add' action. If auto-unlocking is unwanted, just remove the file and
the 'tpm2_key_protector_init' command and invoke the 'cryptomount'
command without '-P tpm2'.
24.8.2 'Remove' action
----------------------
The 'remove' action is used to remove the handles for NV index mode and
the persistent SRK.
24.8.2.1 Handles for NV index mode
..................................
There are two types of TPM handles supported by NV index mode:
persistent handles and NV index handles, and 'tpm2_getcap' can be used
to check the existing handles.
To display the list of existing persistent handles:
# tpm2_getcap handles-persistent
- 0x81000000
Similarly, to display the list of existing NV index handles:
# tpm2_getcap handles-nv-index
- 0x1000000
If the sealed key at an NV index handle is not needed anymore, the
user can remove the handle with '--tpm2-nvindex' and '--tpm2-evict'.
For example, this command removes the data from NV index '0x1000000':
# VasEBoot-protect --action=remove \
--protector=tpm2 \
--tpm2-evict \
--tpm2-nvindex 0x1000000 \
24.8.2.2 Persistent SRK
.......................
There are two supported SRKs in 'VasEBoot-protect': 'RSA' and 'ECC'. Due to
slower key generation, some users of the 'RSA' SRK may prefer making it
persistent so that the TPM can skip the SRK generation when VAS_EBOOT tries
to unseal the key.
The available persistent handles can be checked with 'tpm2_getcap'.
# tpm2_getcap properties-variable
...
TPM2_PT_HR_PERSISTENT: 0x0
TPM2_PT_HR_PERSISTENT_AVAIL: 0x41
...
In this system, there is no persistent handle. A TPM handle is an
unsigned 32-bit integer, and the persistent handles starts with '0x81'.
Here we choose the well-known persistent handle: '0x81000000'.
# VasEBoot-protect --action=add \
--protector=tpm2 \
--tpm2-pcrs=0,2,4,7 \
--tpm2-asymmetric=RSA \
--tpm2-srk=0x81000000 \
--tpm2key \
--tpm2-keyfile=luks.key \
--tpm2-outfile=/boot/efi/efi/VasEBoot/sealed.tpm
The additional '--tpm2-asymmetric=RSA' and '--tpm2-srk=0x81000000'
options are used to make the key sealed with the RSA SRK and store the
SRK in '0x81000000'.
For the 'tpm2_key_protector_init' command, the additional '-s
0x81000000' informs the TPM2 key protector to fetch the SRK from
'0x81000000'.
VasEBoot> tpm2_key_protector_init -s 0x81000000 -T (hd0,gpt1)/efi/VasEBoot/sealed.tpm
VasEBoot> cryptomount -u <UUID> -P tpm2
After making the SRK handle persistent, we can check the status of
the persistent handles with 'tpm2_getcap'.
# tpm2_getcap properties-variable
...
TPM2_PT_HR_PERSISTENT: 0x1
TPM2_PT_HR_PERSISTENT_AVAIL: 0x40
...
# tpm2_getcap handles-persistent
- 0x81000000
The sealed key can be removed once the user does not want to use the
TPM2 key protector anymore. Here is the command to remove the
persistent SRK handle ('0x81000000') with '--tpm2-srk' and
'--tpm2-evict'.
# VasEBoot-protect --action=remove \
--protector=tpm2 \
--tpm2-srk 0x81000000 \
--tpm2-evict

File: VasEBoot.info, Node: Invoking VasEBoot-script-check, Prev: Invoking VasEBoot-protect, Up: User-space utilities
24.9 Invoking VasEBoot-script-check
===============================
The program 'VasEBoot-script-check' takes a VAS_EBOOT script file (*note
Shell-like scripting::) and checks it for syntax errors, similar to
commands such as 'sh -n'. It may take a PATH as a non-option argument;
if none is supplied, it will read from standard input.
VasEBoot-script-check /boot/VasEBoot/VasEBoot.cfg
'VasEBoot-script-check' accepts the following options:
'--help'
Print a summary of the command-line options and exit.
'--version'
Print the version number of VAS_EBOOT and exit.
'-v'
'--verbose'
Print each line of input after reading it.

File: VasEBoot.info, Node: Obtaining and Building VAS_EBOOT, Next: Reporting bugs, Prev: User-space utilities, Up: Top
Appendix A How to obtain and build VAS_EBOOT
***************************************
*Caution:* VAS_EBOOT requires binutils-2.9.1.0.23 or later because the
GNU assembler has been changed so that it can produce real 16bits
machine code between 2.9.1 and 2.9.1.0.x. See
<https://www.gnu.org/software/binutils/>, to obtain information on
how to get the latest version.
VAS_EBOOT is available from the GNU alpha archive site
<https://ftp.gnu.org/gnu/VasEBoot/> or any of its mirrors. The file will be
named VasEBoot-version.tar.gz. The current version is 2.14, so the file you
should grab is:
<https://ftp.gnu.org/gnu/VasEBoot/VasEBoot-2.14.tar.gz>
To unbundle VAS_EBOOT use the instruction:
zcat VasEBoot-2.14.tar.gz | tar xvf -
which will create a directory called 'VasEBoot-2.14' with all the
sources. You can look at the file 'INSTALL' for detailed instructions
on how to build and install VAS_EBOOT, but you should be able to just do:
cd VasEBoot-2.14
./configure
make install
Also, the latest version is available using Git. See
<https://www.gnu.org/software/VasEBoot/VasEBoot-download.html> for more
information.

File: VasEBoot.info, Node: Reporting bugs, Next: Future, Prev: Obtaining and Building VAS_EBOOT, Up: Top
Appendix B Reporting bugs
*************************
These are the guideline for how to report bugs. Take a look at this
list below before you submit bugs:
1. Before getting unsettled, read this manual through and through.
Also, see the GNU VAS_EBOOT FAQ
(https://www.gnu.org/software/VasEBoot/VasEBoot-faq.html).
2. Always mention the information on your VAS_EBOOT. The version number and
the configuration are quite important. If you build it yourself,
write the options specified to the configure script and your
operating system, including the versions of gcc and binutils.
3. If you have trouble with the installation, inform us of how you
installed VAS_EBOOT. Don't omit error messages, if any. Just 'VAS_EBOOT
hangs up when it boots' is not enough.
The information on your hardware is also essential. These are
especially important: the geometries and the partition tables of
your hard disk drives and your BIOS.
4. If VAS_EBOOT cannot boot your operating system, write down _everything_
you see on the screen. Don't paraphrase them, like 'The foo OS
crashes with VAS_EBOOT, even though it can boot with the bar boot loader
just fine'. Mention the commands you executed, the messages
printed by them, and information on your operating system including
the version number.
5. Explain what you wanted to do. It is very useful to know your
purpose and your wish, and how VAS_EBOOT didn't satisfy you.
6. If you can investigate the problem yourself, please do. That will
give you and us much more information on the problem. Attaching a
patch is even better.
When you attach a patch, make the patch in unified diff format, and
write ChangeLog entries. But, even when you make a patch, don't
forget to explain the problem, so that we can understand what your
patch is for.
7. Write down anything that you think might be related. Please
understand that we often need to reproduce the same problem you
encountered in our environment. So your information should be
sufficient for us to do the same thing--Don't forget that we cannot
see your computer directly. If you are not sure whether to state a
fact or leave it out, state it! Reporting too many things is much
better than omitting something important.
If you follow the guideline above, submit a report to the Bug
Tracking System (https://savannah.gnu.org/bugs/?group=VasEBoot).
Alternatively, you can submit a report via electronic mail to
<bug-VasEBoot@gnu.org>, but we strongly recommend that you use the Bug
Tracking System, because e-mail can be passed over easily.
Once we get your report, we will try to fix the bugs.

File: VasEBoot.info, Node: Future, Next: Copying This Manual, Prev: Reporting bugs, Up: Top
Appendix C Where VAS_EBOOT will go
*****************************
VAS_EBOOT 2 is now quite stable and used in many production systems. We are
currently working on the 2.x series.
If you are interested in the development of VAS_EBOOT 2, take a look at
the homepage (https://www.gnu.org/software/VasEBoot/VasEBoot.html).

File: VasEBoot.info, Node: Copying This Manual, Next: Index, Prev: Future, Up: Top
Appendix D Copying This Manual
******************************
* Menu:
* GNU Free Documentation License:: License for copying this manual.

File: VasEBoot.info, Node: GNU Free Documentation License, Up: Copying This Manual
D.1 GNU Free Documentation License
==================================
Version 1.2, November 2002
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other
functional and useful document "free" in the sense of freedom: to
assure everyone the effective freedom to copy and redistribute it,
with or without modifying it, either commercially or
noncommercially. Secondarily, this License preserves for the
author and publisher a way to get credit for their work, while not
being considered responsible for modifications made by others.
This License is a kind of "copyleft", which means that derivative
works of the document must themselves be free in the same sense.
It complements the GNU General Public License, which is a copyleft
license designed for free software.
We have designed this License in order to use it for manuals for
free software, because free software needs free documentation: a
free program should come with manuals providing the same freedoms
that the software does. But this License is not limited to
software manuals; it can be used for any textual work, regardless
of subject matter or whether it is published as a printed book. We
recommend this License principally for works whose purpose is
instruction or reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work, in any medium,
that contains a notice placed by the copyright holder saying it can
be distributed under the terms of this License. Such a notice
grants a world-wide, royalty-free license, unlimited in duration,
to use that work under the conditions stated herein. The
"Document", below, refers to any such manual or work. Any member
of the public is a licensee, and is addressed as "you". You accept
the license if you copy, modify or distribute the work in a way
requiring permission under copyright law.
A "Modified Version" of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with
modifications and/or translated into another language.
A "Secondary Section" is a named appendix or a front-matter section
of the Document that deals exclusively with the relationship of the
publishers or authors of the Document to the Document's overall
subject (or to related matters) and contains nothing that could
fall directly within that overall subject. (Thus, if the Document
is in part a textbook of mathematics, a Secondary Section may not
explain any mathematics.) The relationship could be a matter of
historical connection with the subject or with related matters, or
of legal, commercial, philosophical, ethical or political position
regarding them.
The "Invariant Sections" are certain Secondary Sections whose
titles are designated, as being those of Invariant Sections, in the
notice that says that the Document is released under this License.
If a section does not fit the above definition of Secondary then it
is not allowed to be designated as Invariant. The Document may
contain zero Invariant Sections. If the Document does not identify
any Invariant Sections then there are none.
The "Cover Texts" are certain short passages of text that are
listed, as Front-Cover Texts or Back-Cover Texts, in the notice
that says that the Document is released under this License. A
Front-Cover Text may be at most 5 words, and a Back-Cover Text may
be at most 25 words.
A "Transparent" copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the
general public, that is suitable for revising the document
straightforwardly with generic text editors or (for images composed
of pixels) generic paint programs or (for drawings) some widely
available drawing editor, and that is suitable for input to text
formatters or for automatic translation to a variety of formats
suitable for input to text formatters. A copy made in an otherwise
Transparent file format whose markup, or absence of markup, has
been arranged to thwart or discourage subsequent modification by
readers is not Transparent. An image format is not Transparent if
used for any substantial amount of text. A copy that is not
"Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain
ASCII without markup, Texinfo input format, LaTeX input format,
SGML or XML using a publicly available DTD, and standard-conforming
simple HTML, PostScript or PDF designed for human modification.
Examples of transparent image formats include PNG, XCF and JPG.
Opaque formats include proprietary formats that can be read and
edited only by proprietary word processors, SGML or XML for which
the DTD and/or processing tools are not generally available, and
the machine-generated HTML, PostScript or PDF produced by some word
processors for output purposes only.
The "Title Page" means, for a printed book, the title page itself,
plus such following pages as are needed to hold, legibly, the
material this License requires to appear in the title page. For
works in formats which do not have any title page as such, "Title
Page" means the text near the most prominent appearance of the
work's title, preceding the beginning of the body of the text.
A section "Entitled XYZ" means a named subunit of the Document
whose title either is precisely XYZ or contains XYZ in parentheses
following text that translates XYZ in another language. (Here XYZ
stands for a specific section name mentioned below, such as
"Acknowledgements", "Dedications", "Endorsements", or "History".)
To "Preserve the Title" of such a section when you modify the
Document means that it remains a section "Entitled XYZ" according
to this definition.
The Document may include Warranty Disclaimers next to the notice
which states that this License applies to the Document. These
Warranty Disclaimers are considered to be included by reference in
this License, but only as regards disclaiming warranties: any other
implication that these Warranty Disclaimers may have is void and
has no effect on the meaning of this License.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the
copyright notices, and the license notice saying this License
applies to the Document are reproduced in all copies, and that you
add no other conditions whatsoever to those of this License. You
may not use technical measures to obstruct or control the reading
or further copying of the copies you make or distribute. However,
you may accept compensation in exchange for copies. If you
distribute a large enough number of copies you must also follow the
conditions in section 3.
You may also lend copies, under the same conditions stated above,
and you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly
have printed covers) of the Document, numbering more than 100, and
the Document's license notice requires Cover Texts, you must
enclose the copies in covers that carry, clearly and legibly, all
these Cover Texts: Front-Cover Texts on the front cover, and
Back-Cover Texts on the back cover. Both covers must also clearly
and legibly identify you as the publisher of these copies. The
front cover must present the full title with all words of the title
equally prominent and visible. You may add other material on the
covers in addition. Copying with changes limited to the covers, as
long as they preserve the title of the Document and satisfy these
conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit
legibly, you should put the first ones listed (as many as fit
reasonably) on the actual cover, and continue the rest onto
adjacent pages.
If you publish or distribute Opaque copies of the Document
numbering more than 100, you must either include a machine-readable
Transparent copy along with each Opaque copy, or state in or with
each Opaque copy a computer-network location from which the general
network-using public has access to download using public-standard
network protocols a complete Transparent copy of the Document, free
of added material. If you use the latter option, you must take
reasonably prudent steps, when you begin distribution of Opaque
copies in quantity, to ensure that this Transparent copy will
remain thus accessible at the stated location until at least one
year after the last time you distribute an Opaque copy (directly or
through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of
the Document well before redistributing any large number of copies,
to give them a chance to provide you with an updated version of the
Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document
under the conditions of sections 2 and 3 above, provided that you
release the Modified Version under precisely this License, with the
Modified Version filling the role of the Document, thus licensing
distribution and modification of the Modified Version to whoever
possesses a copy of it. In addition, you must do these things in
the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title
distinct from that of the Document, and from those of previous
versions (which should, if there were any, be listed in the
History section of the Document). You may use the same title
as a previous version if the original publisher of that
version gives permission.
B. List on the Title Page, as authors, one or more persons or
entities responsible for authorship of the modifications in
the Modified Version, together with at least five of the
principal authors of the Document (all of its principal
authors, if it has fewer than five), unless they release you
from this requirement.
C. State on the Title page the name of the publisher of the
Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications
adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license
notice giving the public permission to use the Modified
Version under the terms of this License, in the form shown in
the Addendum below.
G. Preserve in that license notice the full lists of Invariant
Sections and required Cover Texts given in the Document's
license notice.
H. Include an unaltered copy of this License.
I. Preserve the section Entitled "History", Preserve its Title,
and add to it an item stating at least the title, year, new
authors, and publisher of the Modified Version as given on the
Title Page. If there is no section Entitled "History" in the
Document, create one stating the title, year, authors, and
publisher of the Document as given on its Title Page, then add
an item describing the Modified Version as stated in the
previous sentence.
J. Preserve the network location, if any, given in the Document
for public access to a Transparent copy of the Document, and
likewise the network locations given in the Document for
previous versions it was based on. These may be placed in the
"History" section. You may omit a network location for a work
that was published at least four years before the Document
itself, or if the original publisher of the version it refers
to gives permission.
K. For any section Entitled "Acknowledgements" or "Dedications",
Preserve the Title of the section, and preserve in the section
all the substance and tone of each of the contributor
acknowledgements and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document, unaltered
in their text and in their titles. Section numbers or the
equivalent are not considered part of the section titles.
M. Delete any section Entitled "Endorsements". Such a section
may not be included in the Modified Version.
N. Do not retitle any existing section to be Entitled
"Endorsements" or to conflict in title with any Invariant
Section.
O. Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or
appendices that qualify as Secondary Sections and contain no
material copied from the Document, you may at your option designate
some or all of these sections as invariant. To do this, add their
titles to the list of Invariant Sections in the Modified Version's
license notice. These titles must be distinct from any other
section titles.
You may add a section Entitled "Endorsements", provided it contains
nothing but endorsements of your Modified Version by various
parties--for example, statements of peer review or that the text
has been approved by an organization as the authoritative
definition of a standard.
You may add a passage of up to five words as a Front-Cover Text,
and a passage of up to 25 words as a Back-Cover Text, to the end of
the list of Cover Texts in the Modified Version. Only one passage
of Front-Cover Text and one of Back-Cover Text may be added by (or
through arrangements made by) any one entity. If the Document
already includes a cover text for the same cover, previously added
by you or by arrangement made by the same entity you are acting on
behalf of, you may not add another; but you may replace the old
one, on explicit permission from the previous publisher that added
the old one.
The author(s) and publisher(s) of the Document do not by this
License give permission to use their names for publicity for or to
assert or imply endorsement of any Modified Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under
this License, under the terms defined in section 4 above for
modified versions, provided that you include in the combination all
of the Invariant Sections of all of the original documents,
unmodified, and list them all as Invariant Sections of your
combined work in its license notice, and that you preserve all
their Warranty Disclaimers.
The combined work need only contain one copy of this License, and
multiple identical Invariant Sections may be replaced with a single
copy. If there are multiple Invariant Sections with the same name
but different contents, make the title of each such section unique
by adding at the end of it, in parentheses, the name of the
original author or publisher of that section if known, or else a
unique number. Make the same adjustment to the section titles in
the list of Invariant Sections in the license notice of the
combined work.
In the combination, you must combine any sections Entitled
"History" in the various original documents, forming one section
Entitled "History"; likewise combine any sections Entitled
"Acknowledgements", and any sections Entitled "Dedications". You
must delete all sections Entitled "Endorsements."
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other
documents released under this License, and replace the individual
copies of this License in the various documents with a single copy
that is included in the collection, provided that you follow the
rules of this License for verbatim copying of each of the documents
in all other respects.
You may extract a single document from such a collection, and
distribute it individually under this License, provided you insert
a copy of this License into the extracted document, and follow this
License in all other respects regarding verbatim copying of that
document.
7. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other
separate and independent documents or works, in or on a volume of a
storage or distribution medium, is called an "aggregate" if the
copyright resulting from the compilation is not used to limit the
legal rights of the compilation's users beyond what the individual
works permit. When the Document is included in an aggregate, this
License does not apply to the other works in the aggregate which
are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these
copies of the Document, then if the Document is less than one half
of the entire aggregate, the Document's Cover Texts may be placed
on covers that bracket the Document within the aggregate, or the
electronic equivalent of covers if the Document is in electronic
form. Otherwise they must appear on printed covers that bracket
the whole aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may
distribute translations of the Document under the terms of section
4. Replacing Invariant Sections with translations requires special
permission from their copyright holders, but you may include
translations of some or all Invariant Sections in addition to the
original versions of these Invariant Sections. You may include a
translation of this License, and all the license notices in the
Document, and any Warranty Disclaimers, provided that you also
include the original English version of this License and the
original versions of those notices and disclaimers. In case of a
disagreement between the translation and the original version of
this License or a notice or disclaimer, the original version will
prevail.
If a section in the Document is Entitled "Acknowledgements",
"Dedications", or "History", the requirement (section 4) to
Preserve its Title (section 1) will typically require changing the
actual title.
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document
except as expressly provided for under this License. Any other
attempt to copy, modify, sublicense or distribute the Document is
void, and will automatically terminate your rights under this
License. However, parties who have received copies, or rights,
from you under this License will not have their licenses terminated
so long as such parties remain in full compliance.
10. FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions of
the GNU Free Documentation License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns. See
<http://www.gnu.org/copyleft/>.
Each version of the License is given a distinguishing version
number. If the Document specifies that a particular numbered
version of this License "or any later version" applies to it, you
have the option of following the terms and conditions either of
that specified version or of any later version that has been
published (not as a draft) by the Free Software Foundation. If the
Document does not specify a version number of this License, you may
choose any version ever published (not as a draft) by the Free
Software Foundation.
D.1.1 ADDENDUM: How to use this License for your documents
----------------------------------------------------------
To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and license
notices just after the title page:
Copyright (C) YEAR YOUR NAME.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts. A copy of the license is included in the section entitled ``GNU
Free Documentation License''.
If you have Invariant Sections, Front-Cover Texts and Back-Cover
Texts, replace the "with...Texts." line with this:
with the Invariant Sections being LIST THEIR TITLES, with
the Front-Cover Texts being LIST, and with the Back-Cover Texts
being LIST.
If you have Invariant Sections without Cover Texts, or some other
combination of the three, merge those two alternatives to suit the
situation.
If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of free
software license, such as the GNU General Public License, to permit
their use in free software.

File: VasEBoot.info, Node: Index, Prev: Copying This Manual, Up: Top
Index
*****
[index]
* Menu:
* [: [. (line 6)
* acpi: acpi. (line 6)
* append_add_dbx_cert: append_add_dbx_cert. (line 6)
* append_add_dbx_hash: append_add_dbx_hash. (line 6)
* append_add_db_cert: append_add_db_cert. (line 6)
* append_add_db_hash: append_add_db_hash. (line 6)
* append_list_db: append_list_db. (line 6)
* append_list_dbx: append_list_dbx. (line 6)
* append_verify: append_verify. (line 6)
* authenticate: authenticate. (line 6)
* background_color: background_color. (line 6)
* background_image: background_image. (line 6)
* badram: badram. (line 6)
* blocklist: blocklist. (line 6)
* blscfg: blscfg. (line 6)
* boot: boot. (line 6)
* cat: cat. (line 6)
* chainloader: chainloader. (line 6)
* clear: clear. (line 6)
* CMOS: cmosdump. (line 6)
* cmosclean: cmosclean. (line 6)
* cmostest: cmostest. (line 6)
* cmp: cmp. (line 6)
* configfile: configfile. (line 6)
* cpuid: cpuid. (line 6)
* crc: crc. (line 6)
* cryptocheck: cryptocheck. (line 6)
* cryptomount: cryptomount. (line 6)
* cutmem: cutmem. (line 6)
* date: date. (line 6)
* devicetree: devicetree. (line 6)
* distrust: distrust. (line 6)
* drivemap: drivemap. (line 6)
* echo: echo. (line 6)
* efitextmode: efitextmode. (line 6)
* eval: eval. (line 6)
* export: export. (line 6)
* false: false. (line 6)
* FDL, GNU Free Documentation License: GNU Free Documentation License.
(line 6)
* fdtdump: fdtdump. (line 6)
* file: file. (line 6)
* fwsetup: fwsetup. (line 6)
* gdbinfo: gdbinfo. (line 6)
* gettext: gettext. (line 6)
* gptsync: gptsync. (line 6)
* halt: halt. (line 6)
* hashsum: hashsum. (line 6)
* help: help. (line 6)
* hexdump: hexdump. (line 6)
* initrd: initrd. (line 6)
* initrd16: initrd16. (line 6)
* insmod: insmod. (line 6)
* keystatus: keystatus. (line 6)
* linux: linux. (line 6)
* linux16: linux16. (line 6)
* list_env: list_env. (line 6)
* list_trusted: list_trusted. (line 6)
* loadfont: loadfont. (line 6)
* load_env: load_env. (line 6)
* loopback: loopback. (line 6)
* ls: ls. (line 6)
* lsfonts: lsfonts. (line 6)
* lsfreemem: lsfreemem. (line 6)
* lsmem: lsmem. (line 6)
* lsmemregions: lsmemregions. (line 6)
* lsmod: lsmod. (line 6)
* md5sum: md5sum. (line 6)
* menuentry: menuentry. (line 6)
* module: module. (line 6)
* multiboot: multiboot. (line 6)
* nativedisk: nativedisk. (line 6)
* net_add_addr: net_add_addr. (line 6)
* net_add_dns: net_add_dns. (line 6)
* net_add_route: net_add_route. (line 6)
* net_bootp: net_bootp. (line 6)
* net_del_addr: net_del_addr. (line 6)
* net_del_dns: net_del_dns. (line 6)
* net_del_route: net_del_route. (line 6)
* net_dhcp: net_dhcp. (line 6)
* net_get_dhcp_option: net_get_dhcp_option. (line 6)
* net_ipv6_autoconf: net_ipv6_autoconf. (line 6)
* net_ls_addr: net_ls_addr. (line 6)
* net_ls_cards: net_ls_cards. (line 6)
* net_ls_dns: net_ls_dns. (line 6)
* net_ls_routes: net_ls_routes. (line 6)
* net_nslookup: net_nslookup. (line 6)
* net_set_vlan: net_set_vlan. (line 6)
* normal: normal. (line 6)
* normal_exit: normal_exit. (line 6)
* parttool: parttool. (line 6)
* password: password. (line 6)
* password_pbkdf2: password_pbkdf2. (line 6)
* plainmount: plainmount. (line 6)
* play: play. (line 6)
* probe: probe. (line 6)
* rdmsr: rdmsr. (line 6)
* read: read. (line 6)
* reboot: reboot. (line 6)
* regexp: regexp. (line 6)
* rmmod: rmmod. (line 6)
* save_env: save_env. (line 6)
* search: search. (line 6)
* sendkey: sendkey. (line 6)
* serial: serial. (line 6)
* set: set. (line 6)
* sha1sum: sha1sum. (line 6)
* sha256sum: sha256sum. (line 6)
* sha512sum: sha512sum. (line 6)
* sleep: sleep. (line 6)
* smbios: smbios. (line 6)
* source: source. (line 6)
* stress_big_allocs: stress_big_allocs. (line 6)
* submenu: submenu. (line 6)
* terminal_input: terminal_input. (line 6)
* terminal_output: terminal_output. (line 6)
* terminfo: terminfo. (line 6)
* test: test. (line 6)
* tpm2_dump_pcr: tpm2_dump_pcr. (line 6)
* tpm2_key_protector_clear: tpm2_key_protector_clear.
(line 6)
* tpm2_key_protector_init: tpm2_key_protector_init.
(line 6)
* true: true. (line 6)
* trust: trust. (line 6)
* uki: uki. (line 6)
* unset: unset. (line 6)
* verify_detached: verify_detached. (line 6)
* videoinfo: videoinfo. (line 6)
* wrmsr: wrmsr. (line 6)
* xen_hypervisor: xen_hypervisor. (line 6)
* xen_module: xen_module. (line 6)
Reference in New Issue View Git Blame Copy Permalink