Provide a function which can detect a LUKS partition. Add a test, using
mmc11
Series-to: concept
Cover-letter:
luks: Provide basic support for unlocking a LUKS1 partition
With full-disk encryption (FDE) it is traditional to unlock a LUKS
partition within userspace as part of the initial ramdisk passed to
Linux. The user is prompted for a passphrase and then the disk is
unlocked.
This works well but does have some drawbacks:
- firmware has no way of knowing whether the boot will success
- the 'passphrase' prompt comes quite late in the boot, which can be
confusing for the user
- specifically it is not possible to provide an integrated 'boot' UI in
firmware where the user can enter the passphrase
- in a VM environment, the key may be known in advance, but there is no
way to take advantage of this
- it is not possible to use an encryted disk unless also using a ramdisk
This series makes a small step towards improving U-Boot in this area. It
allows a passphrase to be checked against a LUKS1-encrypted partition.
It also provides read-only access to the unencrypted data, so that files
can be read.
END
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a new 'luks unlock' command which can unlock a LUKS1 partition,
given a passphrase.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add the logic to unlock a partition and set up a blkmap for use with it.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Enhance blkmap to support decrypting a partition encrypted with LUKS
version 1. This will allow filesystems to access files on the parition.
This will be tested once filesystems support is plumbed in.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Extract the full information for version 2, which is JSON format. Show
this with the 'luks info' command.
Use the mmc12 disk to check this.
Require the JSON for LUKS.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new mmc12 image which has a LUKS2-encrypted ext4 partition.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
LUKS version 2 uses JSON as a means of communicating the key
information. Add a simple library which can print JSON in a
human-readable format.
Note that it does not fully parse the JSON fragment. That may be
considered later, if needed.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a 'luks' command which allows querying a partition to see if it is
encrypted using LUKS, as well as showing information about a LUKS
partition.
Provide some documentation and a test.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Linux Unified Key Setup (LUKS) provides a way to encryption a disk
partition with a a key an later unlock it. There are two versions (1 and
2).
Add a definition of the main structures and the ability to detect a LUKS
partition.
Enable this for the sandbox board.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
If requested, use cryptsetup to encrypt a partition with the provided
passphrase.
This requires use of sudo since there doesn't seem to be any other way
to write files into a filesystem on an encrypted disk.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the GitLab CI Docker image to use the new build with cryptsetup
support for LUKS testing.
This appears to require use of sudo, so add a comment about that.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add cryptsetup to the CI Docker image to enable LUKS encryption tests.
This is needed to create test images.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a parameter to indicate the size of the root partition so that it
can have space for the LUTS metadata.
Move the import of gzip to the top of the file while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the partition size is always the same as the filesystem
within it. Add a way to specify a larger size, to make space for LUTS
tables needed for full-disk encryption.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a few Kconfig options to allow PKCS#5 (PBKDF2) to be used within
U-Boot
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
The mbedtls hashing has not been integrated into U-Boot's hash API. As a
first step, add the mbedtls hash type into struct hash_algo and provide
the values. This allows looking up the type by its name.
Signed-off-by: Simon Glass <sjg@chromium.org>
There are quite a few media devices in test.dts which are not enabled by
default, so are not bound on startup. Sometimes it is useful to be able
to use these from the command line.
Add 'sb devon' and 'sb devoff' subcommands to enable and disable devices
from the device tree. For example, running sandbox with -T, then
'sb devon mmc11' enables the mmc11 device mentioned in test.dts
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
For sandbox it normally doesn't make sense to reset when a panic occurs,
since presumably it will just happen again. Add an option to power off
instead.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new log_debug_hex() macro which can log a a buffer as a hex
string, e.g. for showing a hash value.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
This command lacks documentation in the normal place. Add it.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the aes_get_rounds() and aes_get_keycols() functions compare
the key_len parameter (in bits) directly against AES*_KEY_LENGTH
constants (in bytes), causing incorrect round and column counts for
non-128-bit keys.
Additionally, aes_expand_key() uses key_len as a byte count in memcpy(),
copying far more data than intended and causing buffer overflows.
Specifically, for AES-256 (256-bit key) it comparies 256 (bits) against
32 (bytes), failing the comparison. This causes AES-256 to use AES-128
parameters (10 rounds instead of 14) and the memcpy() to copy 256 bytes
instead of 32.
Fix by converting key_len from bits to bytes before comparisons and in
memcpy. With this we get:
- AES-128 (128 bits / 16 bytes): 10 rounds, 4 key columns
- AES-192 (192 bits / 24 bytes): 12 rounds, 6 key columns
- AES-256 (256 bits / 32 bytes): 14 rounds, 8 key columns
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 8302d1708a ("aes: add support of aes192 and aes256")
Provide a -T/--tkey option to enable access to a USB-attached Tillitis
TKey.
Series-to: concept
Series-cc: heinrich
Series-links: 1:54
Series-version: 2
Cover-letter:
Bootstage and script enhancements
This series collects together a few improvements to the bootstage
subsystem, principally some new tests.
It also adds support for ACPI FPDT which is a way of passing timing
information to the OS.
A bug fix is provided for mouse clicks with expo.
Finally the series includes some new options for the build-efi script
for networking, spice, etc.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Complete writing of any output before running QEMU, since otherwise it
does not always appear until QEMU exits (e.g. with 'tee')
Signed-off-by: Simon Glass <sjg@chromium.org>
Update the FPDT boot performance record's ebs_entry and ebs_exit
fields in bootm_final() to record the time when we're about to
hand off to the operating system.
The timing is recorded just before we start the kernel, after all
device cleanup and before interrupts are disabled, which corresponds
to the ExitBootServices phase in UEFI.
If EFI is used to boot, a further update could be made, but that is
left for later.
Avoid including asm/acpi_table.h on platforms without ACPI. Ad a special
case for the QEMU RISC-V ACPI board.
Series-changes: 2
- Depend on ACPIGEN instead of GENERATE_ACPI_TABLE
- Avoid including asm/acpi_table.h on platforms without ACPI
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add an ACPI writer to automatically generate the FPDT table with boot
timing information when ACPI tables are created.
This allows the OS to read firmware boot-timing metrics from the FPDT
table.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add ACPI FPDT support to report firmware boot timing information to
the OS. The FPDT table contains timing data for firmware phases from
reset through OS handoff.
Add some functions to enable generation of this table.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
There is already a Python test. Add a few C tests as well, for bootstage
itself and for the 'bootstage' command.
Add helpers to access the internal state. Be careful to zero records
when removing them, since if the record is later reused, bootstage
expects the time to be zero.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Move struct bootstage_record to the header file so it can be used from
tests.
Add some more comments for the struct, while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Due to a missing return in bootflow_menu_poll() a click on any object is
handled as if it were a click on the settings object. Fix this by
returning the correct error code for unrecognised clicks.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: e94de63e6c ("expo: Add a way to select settings")
Add a sandbox TKey driver that enables communication with physical TKey
devices via serial port (/dev/ttyACM0). This allows testing TKey
functionality in sandbox with real hardware.
The driver:
- Opens the configured device path from device tree
- Configures TTY parameters using os_tty_set_params()
- Implements read/write operations for TKey protocol
- Supports both read() and read_all() operations
Device tree configuration:
tkey-test {
compatible = "sandbox,tkey";
sandbox,device-path = "/dev/ttyACM0";
};
Series-to: concept
Cover-letter:
tkey: Provide basic support for Tillitis TKey
This device provides a way to sign data using an internal, unique key.
It can be useful for features such as unlocking an encrypted disk.
This series provides basic support for the Tkey, with a uclass, two
sandbox drivers (emulator and serial), a simple command some tests.
END
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add os_tty_set_params() function to configure terminal devices for
serial communication with TKey devices:
- Custom baud rate of 62500 using termios2
- 8n1 configuration (8 data bits, no parity, 1 stop bit)
- Raw mode for binary communication
- Appropriate timeouts for frame-based protocols
This is needed for serial-based TKey communication on sandbox, allowing
U-Boot to communicate with TKey security tokens via a serial port.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new 'tkey' command that provides an interface to interact with
Tillitis TKey security tokens. Subcommands include:
- info: Display device information (UDI, name, version, mode)
- load: Load and run applications on the TKey
- pubkey: Get the public key from a signer app
- getkey: Derive disk encryption keys with password and USS
This command enables U-Boot to use TKey devices for secure key
derivation for full-disk encryption.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a simple emulator which can handle the TKey operations. Add a
test which uses it.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
The TKey is a USB device which can run ephemeral firmware and perform
cyrptographic operations.
Add a uclass for the communication layer.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
The TKey User-Supplied Secret (USS) feature requires blake2s hashing
to derive app-specific secrets. Add blake2s implementation alongside
the existing blake2b support.
The blake2s implementation is ported from the reference BLAKE2
implementation at https://github.com/BLAKE2/BLAKE2
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for a 'skip-init' property in the device tree that preserves
UART settings from a previous boot phase.
This is useful when the UART is already configured by firmware (e.g.,
EFI firmware on x86 platforms) and changing the settings would disrupt
console output or cause communication issues.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
We don't need to enable USB or i8042 for the app. Enable only serial for
now.
Series-to: concept
Cover-letter:
bootctl: Expand bootctl to include a new UI
The current bootctl UI is fairly basic, just supporting a keyboard menu
with text.
Now that expo supports a mouse, add a more interesting UI, with more
graphical elements. Provide a way to switch between this and the simple
UI.
This series also includes some small test improvements, along with a
patch to remove a blob from a bloblist.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Adjust the configuration to support truetype fonts, more bitmap formats,
VIDEO_COPY (for smoother display) and bloblist for ACPI tables.
Disable the pager since it can be confusing when using bootctl.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a test which switches between the simple and the mouse-based UI.
For now the tests are not enabled, due to an integration problem which
causes bootflow_efi() to detect and invalid free()
Signed-off-by: Simon Glass <sjg@chromium.org>
