Some blkmap slices (like blkmap_crypt) don't support writes and have
their write function set to NULL. The blkmap_blk_write_slice() function
calls the write function without checking if it's NULL, causing a crash
when attempting to write to such slices.
Add a NULL check before calling the write function. When the slice
doesn't support writes, return 0 to indicate no blocks were written.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
This algorithm can use a lot of memory, so add a check for this condition
and return the correct error.
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Update luks_unlock() to support a pre-derived key, such as that obtained
from a TKey. This must match the key_size of the LUKS partition,
otherwise it will fail to unlock.
Signed-off-by: Simon Glass <simon.glass@canonical.com>
In some cases we may wish to provide a pre-derived key, e.g. obtained
from a TKey. Provide an option for this with LUKSv2. For now it is not
exported.
Improve the error-return documentation while we are here.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
In some cases we may wish to provide a pre-derived key, e.g. obtained
from a TKey. Provide an option for this with LUKSv1. For now it is not
exported.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Move the LUKSv1-specific unlock logic from luks_unlock() into a new
unlock_luks1() function, lining up with the structure used for LUKSv2.
Also update unlock_luks1() to use a local key_size variable and only
set the output parameter on success.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Move the derive_key_pbkdf2() call from inside try_keyslot() to the
caller, luks_unlock()
With this change luks_unlock() deals with key derivation and
try_keyslot() only handles the decryption part, using a supplied
derived key.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Create a new derive_key_pbkdf2() function to handle key derivation, to
allow this be called from other places and to reduce the size of
try_keyslot()
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Update luks_unlock() to accept a binary passphrase, to match the LUKS2
implementation.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Update unlock_luks2() and related functions to accept a binary
passphrase instead of a string passphrase. This will allow unlocking
using hashed data.
For now this is internal to the luks implementation.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
In preparation for supporting unlock using binary data, update
try_keyslot() to accept an array of bytes instead of a string.
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Name the derived key as such to avoid confusion. Fix a typo in nearby
log_debug() statement.
Update essiv_decrypt() to have a const * for its first argument.
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Both luks.c and luks2.c have similar implementations of essiv_decrypt().
Drop the version in the later to reduce code duplication.
Drop the duplicate function comments while we are here, since exported
functions should have the information in the header file.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Add support for AES-XTS cipher mode in addition to the existing
AES-CBC-ESSIV support. This is the default cipher for LUKS2 volumes.
The cipher mode (CBC/XTS) is obtained from the LUKS1 cipher_mode or
LUKS2 encryption metadata.
XTS mode uses 512-byte block numbers for IV generation (plain64),
matching dm-crypt behavior. LUKS2 typically uses 4096-byte sectors
for XTS encryption but the IV is based on 512-byte block numbers.
Fix the blkmap-size calculation to exclude the LUKS header/payload
offset.
Update the LUKSv2 test to check reading a file.
Series-to: concept
Cover-letter:
luks: Support the AES-XTS cipher mode
This series finishes off the implementation of LUKSv2, adding support
for the common cipher mode and testing that files can be read from the
disk.
It includes a fix for using the correct size when mapping the crypt, as
well as some refactoring to split up the code a little better.
END
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
In preparation for adding support for a new algorithm, move the
decryption part of blkmap_crypt_read() into its own function.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Create a new blkmap_crypt.c file to hold the LUKS code, since it is
fairly large. Add an internal header for blkmap as well.
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Fix the blkmap-size calculation to exclude the LUKS header/payload
offset. This was missed in the initial implementation.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Fixes: 0cbfb2d490 ("luks: Provide a way to unlock and map encrypted..")
Add supports for luks v2 which is a more common version used on modern
systems.
This makes use of Argon2 and also the JSON->FDT parser.
Enable this feature for sandbox, tidying up the defconfig while we are
here.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
In preparation for luks v2, make a few code-style tweaks:
- shorter vars in some cases
- 80cols in a few places
- drop an unwanted blank line
- use 'pass' instead of 'passphrase'
- unnecessary assignments to NULL
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Provide this function through an internal header, so that luks2 will be
able to use it.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
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 '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>
The logic for part_init() is not ideal, since it silently ignores read
errors. Each partition type tries to read the disk and presumably fails
as well. No error is reported, however, so there is no indication that
anything is wrong.
Update the function to return an error, and update each of the probe
functions to do the same, trying to minimise changes.
Signed-off-by: Simon Glass <sjg@chromium.org>
Support standard boot on a host device by adding a bootdev. This allows
booting from disk images using sandbox.
Signed-off-by: Simon Glass <sjg@chromium.org>
The current name of 'efi_media' is annoying in that it must be given
with 'bootflow scan'. We would prefer to use 'bootflow scan efi', for
example.
Rename the driver to 'efi'.
Signed-off-by: Simon Glass <sjg@chromium.org>
The generic name 'EFI' would be more useful for common EFI features. At
present it just refers to the EFI app and stub, which is confusing.
Rename it to EFI_CLIENT
Signed-off-by: Simon Glass <sjg@chromium.org>
The BLK symbol has a few meanings, one of which is that it controls the
driver model portion of a "block device". Rather than having this hidden
symbol be "default y if ..." it should be select'd by the various block
subsystems. Symbols such as PVBLOCK which already select'd BLK are
unchanged".
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.
Signed-off-by: Tom Rini <trini@konsulko.com>
There are no users of the blk_create_device() function outside the uclass.
Let's make it static. This will ensure that new block drivers will use
blk_create_devicef().
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
By using blk_create_devicef() instead of blk_create_devicef() the driver
can be simplified and brought into line with other block device drivers.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tested-by: Johan Jonker <jbx6244@gmail.com>
Simon Glass <sjg@chromium.org> says:
When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL
Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.
For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:
#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.
This series starts a change in terminology and usage to resolve the
above issues:
- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_
It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.
This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.
The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
Use PHASE_ as the symbol to select a particular XPL build. This means
that SPL_TPL_ is no-longer set.
Update the comment in bootstage to refer to this symbol, instead of
SPL_
Signed-off-by: Simon Glass <sjg@chromium.org>
When SPL_FS_LOADER is set to y and FS_LOADER is not enabled, the SPL build
fails with the following errors:
AR spl/boot/built-in.o
LD spl/u-boot-spl
arm-none-linux-gnueabihf-ld.bfd: drivers/misc/fs_loader.o: in function
`fw_get_filesystem_firmware':
/u-boot/drivers/misc/fs_loader.c:162: undefined reference to
`fs_set_blk_dev'
arm-none-linux-gnueabihf-ld.bfd: /home/frh/tdx/src/u-boot/drivers/misc/
fs_loader.c:185: undefined reference to `fs_read'
arm-none-linux-gnueabihf-ld.bfd: drivers/misc/fs_loader.o: in function
`select_fs_dev':
/u-boot/drivers/misc/fs_loader.c:89: undefined reference to
`fs_set_blk_dev_with_part'
make[1]: *** [scripts/Makefile.spl:527: spl/u-boot-spl] Error 1
make: *** [Makefile:2055: spl/u-boot-spl] Error 2
Fix it by replacing the FS_LOADER with SPL_FS_LOADER in the Makefile, so
the fs.c with the necessary function definitions are compiled.
Fixes: b071a07743 ("drivers: misc: Makefile: Enable fs_loader compilation at SPL Level")
Suggested-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
The existing API for these functions is different from the rest of
U-Boot, in that any error code must be obtained from the errno variable
on failure. This variable is part of the C library, so accessing it
outside of the special 'sandbox' shim-functions is not ideal.
Adjust the API to return an error code, to avoid this. Update existing
uses to check for any negative value, rather than just -1.
Signed-off-by: Simon Glass <sjg@chromium.org>
UBI block is an virtual device, that runs on top
of the MTD layer. The blocks are UBI volumes.
Intended to be used in combination with other MTD
drivers.
Despite the fact that it, like mtdblock abstraction,
it used with UCLASS_MTD, they can be used together
on the system without conflicting. For example,
using bcb command:
# Trying to load bcb via mtdblock:
$ bcb load mtd 0 mtd_partition_name
# Trying to load bcb via UBI block:
$ bcb load ubi 1 ubi_volume_name
User always must attach UBI layer (for example, using
ubi_part()) before using UBI block device.
Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Acked-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
MTD block - abstraction over MTD subsystem, allowing
to read and write in blocks using BLK UCLASS.
Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
At this point in the DM migration, all platforms enable DM. BLK requires
DM. Make BLK "def_bool y" in the cases it had been "default y" to make
this clearer. Now remove the symbol requirement from other places as it
is redundant here.
Signed-off-by: Tom Rini <trini@konsulko.com>
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d, reversing
changes made to 2ee6f3a5f7.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
