This reverts mostly these commits:
42692418c2a985c12659
The library was ment to export common functions shared by
all cryptsetup tools and planned LUKS2 tokens plugins.
It is no longer needed.
crypt_header_is_detached checks if initialized LUKS context uses detached header
(LUKS header located on a different device than data.)
This is a runtime attribute, it does not say if a LUKS device requires detached header.
If user knows which particular PBKDF2 hash or cipher is used for
True/VeraCrypt container, using --hash of --cipher option in tcryptDump
and tcryptOpen can scan only these variants.
Note for the cipher it means substring (all cipher chains containing
the cipher are tried).
For example, you can use
cryptsetup tcryptDump --hash sha512 <container>
Note: for speed up, usually the hash option matters, cipher variants
are scanned very quickly.
Use witch care, in a script it can reveal some sensitive attribute
of the container.
Fixes#608.
Writing into allocated memory right before calling free can be optimized
away by smart compilers. To prevent this, a volatile access must be
performed. This happens already in crypt_safe_memzero.
It was difficult to provoke GCC to remove the assignment, but I was able
to find a way to prove the theory:
* Build cryptsetup with: CFLAGS="-flto -O3 -g" ./configure --enable-static
* Create main.c:
#include <libcryptsetup.h>
int
main(void) {
char *x = crypt_safe_alloc(64);
crypt_safe_free(x);
return 0;
}
* Build the program with: gcc -O3 -flto -static -o main main.c -lcryptsetup
* Disassemble: objdump -d main
My output on an amd64 system is:
0000000000401670 <main>:
401670: 41 54 push %r12
401672: bf f0 03 00 00 mov $0x3f0,%edi
401677: 55 push %rbp
401678: 48 83 ec 08 sub $0x8,%rsp
40167c: e8 ff 4d 01 00 callq 416480 <__libc_malloc>
401681: 48 85 c0 test %rax,%rax
401684: 74 2f je 4016b5 <main+0x45>
401686: 48 c7 00 e8 03 00 00 movq $0x3e8,(%rax)
40168d: 4c 8d 60 08 lea 0x8(%rax),%r12
401691: 48 89 c5 mov %rax,%rbp
401694: be e8 03 00 00 mov $0x3e8,%esi
401699: 4c 89 e7 mov %r12,%rdi
40169c: e8 4f 76 01 00 callq 418cf0 <explicit_bzero>
4016a1: 48 8b 75 00 mov 0x0(%rbp),%rsi
4016a5: 4c 89 e7 mov %r12,%rdi
4016a8: e8 43 76 01 00 callq 418cf0 <explicit_bzero>
4016ad: 48 89 ef mov %rbp,%rdi
4016b0: e8 3b 54 01 00 callq 416af0 <__free>
4016b5: 48 83 c4 08 add $0x8,%rsp
4016b9: 31 c0 xor %eax,%eax
4016bb: 5d pop %rbp
4016bc: 41 5c pop %r12
4016be: c3 retq
4016bf: 90 nop
You can see that the memory allocation and explicit_bzero calls were not
optimized away. But the size assignment disappeared.
Compiling without -O3 or without -flto does not inline the calls and
keeps the assignment. Also the shared library shipped with my
distribution has the assignment.
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.
There is a memory leak when PBKDF2_temp > UINT32_MAX. Here,
we change return to goto out to free key.
Signed-off-by: Lixiaokeng <lixiaokeng@huawei.com>
Signed-off-by: Linfeilong <linfeilong@huawei.com>
The value of h may be NULL. Check it vefore visiting its
memeber to avoid segfault.
Signed-off-by: Lixiaokeng <lixiaokeng@huawei.com>
Signed-off-by: Linfeilong <linfeilong@huawei.com>
The value of vk may be NULL in _keyslot_repair. It will
be dereferenced in LUKS_generate_phdr. Check it to avoid
segfault.
Signed-off-by: Lixiaokeng <lixiaokeng@huawei.com>
Signed-off-by: Linfeilong <linfeilong@huawei.com>
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.
More data about the new IOCTL is here:
https://lwn.net/Articles/818870/
We see 200-500ms boot speed improvement on our platform.
Prefer to define IOCTL when kernel is older version. Also eliminate
duplication since as a result of introduced ifdef.
Signed-off-by: Sinan Kaya <sinan.kaya@microsoft.com>
Right now, cryptsetup makes an attempt to include the correct
definitions in all of its header files, allowing the headers to
compile regardless of the context in which they are included.
A few files were missed, this change fixes them by adding the minimal
set of #includes needed to get them to compile.
Signed-off-by: Joe Richey <joerichey@google.com>
TrueCrypt/VeraCrypt supports backup header, it seems to have
the same format as normal header.
Let's use --header option here, it can be used to unlock data partition
with header backup (open and dump commands).
Fixes: #587.
cipher[31] and cipher_mode[31] buffers were passed to
crypt_parse_name_and_mode() routine where sscanf(s, "%31[^-]-%31s",
cipher, cipher_mode) was called.
In corner case it could cause terminating 0 byte written beyond
respective arrays.
Keep it simple. If there's not enough memory we can't validate
segments. The LUKS2 specification does not recommend to continue
processing LUKS2 metadata if it can not be properly validated.
In case LUKS2 backup segment creates gap in between last regular
segment and backup segment report invalid metadata imediately. We stop
on first error so there's no need to allocate large memory on heap
(we may ran with mlock(MCL_FUTURE) set).
Example:
- total segments count is 3
- regular segments have keys "0" and "1"
- first backup segment has key "42"
Segments are validated in hdr_validate_segments. Gaps in segment keys
are detected when collecting offsets. But if an invalid segment is very
large, larger than count, it could happen that cryptsetup is unable to
allocate enough memory, not giving a clue about what actually is the
problem.
Therefore check for gaps even if not enough memory is available. This
gives much more information with debug output enabled.
Obviously cryptsetup still fails if segments are perfectly fine but not
enough RAM available. But at that stage, the user knows that it's the
fault of the system, not of an invalid segment.
These performance options, introduced in kernel 5.9, configures
dm-crypt to bypass read or write workqueues and run encryption
synchronously.
Also support persistent storage of these flags for LUKS2.
