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 ('') 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 | | ] 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 , or holding down 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_''_dhcp_hostname' (*note net__hostname::) to the value of option. '15 (Domain Name)' Sets environment variable 'net_''_dhcp_domain' (*note net__domain::) to the value of option. '17 (Root Path)' Sets environment variable 'net_''_dhcp_rootpath' (*note net__rootpath::) to the value of option. '18 (Extensions Path)' Sets environment variable 'net_''_dhcp_extensionspath' (*note net__extensionspath::) to the value of option. '66 (TFTP Server Name)' Sets environment variable 'net_''_dhcp_server_name' (*note net__dhcp_server_name::) to the value of option. '67 (Filename)' Sets environment variable 'net_''_boot_file' (*note net__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 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 -P tpm2 There are two programs to create the sealed key for SRK mode: 'VasEBoot-protect' and '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 --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 () 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 --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 -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 -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 -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 , to obtain information on how to get the latest version. VAS_EBOOT is available from the GNU alpha archive site 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: 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 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 , 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 . 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)