NOTE: This is possibly an incompatible change as it changes text output.
Since the support of --sector-size option, the description "sectors"
became ambiguous as it usually means 512-byte sectors (device-mapper unit).
Major confusion occurs when the sector size is 4096 bytes while units display
is in 512-bytes.
Unfortunately, there is no clear compatible way, so this patch adds
[512-byte units] marker and also additional byte size value.
All other fields that display units are changed to use the "[units]" format.
The integrity format is also unified with the common style with ':' as a separator.
Fixes: #884.
This patch implement support for setting specific integrity key size
option in dm-crypt, available since dm-crypt version 1.28.0.
This can be used for setting non-standard HMAC key length.
Mostly based on code from Ingo Franzki <ifranzki@linux.ibm.com>
This patch switches code to SPDX one-line license identifiers according to
https://spdx.dev/learn/handling-license-info/
and replacing long license text headers.
I used C++ format on the first line in style
// SPDX-License-Identifier: <id>
except exported libcryptsetup.h, when only C comments are used.
The only additional changes are:
- switch backend utf8.c from LGPL2+ to LGPL2.1+ (as in systemd)
- add some additional formatting lines.
For broken metadata BITLK format parsing can cause crash or out of memory
on several places.
Add better size checks to avoid parsing such a metadata.
Also be aware that entry_size can be smalle (so minus operation can underflow).
Also fix memory leak if FVEK entry is more than once in metadata
(just use the first entry and ignore others).
For broken metadata BITLK format parsing can cause crash or out of memory
on several places.
Add better size checks to avoid parsing such a metadata.
Fixes OSS-fuzz bug 54548,54553,54559.
Ths will allow automatic scan of known formats.
Errors are printed only if something is wrong with already detected metadata.
This change means that it is responsibility of the caller to print an error
message if needed.
Also fix some places without a message.
Fixes: #642
Bitlocker compatible mode uses dm-zero to mask metadata area,
device cannot be activated if dm-zero is not available.
Just add zero target check to device-mapper backend and
if activation fails, print a better error message here.
Fixes: #722
This should silence similar warnings like
warning: cast from 'char *' to 'struct xyz *' increases required alignment from 1 to X
when we try to calclulate byte pointer offsets in a buffer.
Windows 11 now includes the BitLocker volume GUID in the BEK file
metadata entries. This was previously not included so cryptsetup
refused to open the file because there was an unknown metadata
entry in the startup key.
Fixes: #690
This fixes multiple issues found by coverity in the startup key
code and also makes the parsing less complicated -- we don't need
to loop through all metadata entries in the BEK file if we are
expecting only one metadata entry of a specific type.
It makes more sense to return "real" key sizes, e.g. 256 bit for
AES-XTS 128 and 256/512 bit for AES-CBC with Elephant which has
a separate key for the Elephant mode.
The return value of malloc vmk and params->fvek is not
checked. Here we add checking.
Signed-off-by: Lixiaokeng <lixiaokeng@huawei.com>
Signed-off-by: Linfeilong <linfeilong@huawei.com>
Both BitLocker version 1 and NTFS have the same bootcode eb 52 90
so when trying to open an NTFS device user will get error message
saying that BitLocker version 1 is not supported. This patch
switches to check the superblock first to inform user that the
device is not a BITLK device.
We can't easily distinguish between a passphrase and other
protectors like recovery passphrase or startup key during
activation so we can't stop when attempted passphrase activation
fails because a binary startup key can't be conveted to UTF-16
during KDF.
We've assumed that first 4 bytes of the decrypted key data is the
size of the key + metadata. Looks like this isn't true and only
first two bytes contain the size and the other two bytes are
unknown data, possibly related to reencryption and/or passphrase
change.
Fixes: #575
