These are false positives and gcc internal detection of this
pattern seems to be broken again.
In this path we must avoid memcpy the whole buffer, it can contain
some bytes after null char, so use MIN/strlen here.
We cannot trust possibly broken keyslots metadata here through LUKS_keyslots_offset().
Expect first keyslot is aligned, if not, then manual repair is neccessary.
(This situation happen if partition table signarture overwrites slot 4 area).
Also, if keyslot order is different, current repair code does not work properly
(this can happen only with downconverting LUKS2 device).
This patch adds support for Linux kernel (since version 5.11) dm-integrity
fixes that disables integrity recalculation if keyed algorithms (HMAC) is used.
Original dm-integrity superblock version <=4 is recalculation offset
field not protected by HMAC. An attacker can move this pointer and force
the kernel to recalculate the data area, ignoring original HMAC tags.
N.B. dm-integrity was not intended to protect against intentional changes.
Better use authenticated encryption (AEAD) in combination with dm-crypt.
It is designed to protect against random data corruption caused by hardware
or storage medium faults.
Despite that, we try to keep the system secure if keyed algorithms are used.
There are two possible keyed algorithms in dm-integrity - algorithm used
to protect journal and superblock (--journal-integrity) and algorithms
for protecting data (--integrity).
The dm-integrity superblock is guarded by --journal-integrity, so if you want
to protect data with HMAC, you should always also use HMAC for --journal-integrity.
The keys are independent. If HMAC is used for data but not for the journal,
recalculation is disabled by default.
For new kernel dm-integrity, the HMAC option also uses salt in superblock
to avoid an easy way to distinguish that the HMAC key is the same for two devices
(if data are the same).
The new HMAC and superblock are enabled automatically if the kernel supports it
(you can see superblock version 5 and fix_hmac flag in dump command).
If you need to use (insecure) backward compatibility, then two new integritysetup
options are introduced:
Use --integrity-legacy-recalc (instead of --integrity-recalc) to allow recalculation
on legacy devices.
Use --integrity-legacy-hmac in format action to force old insecure version
format (with HMAC).
Libcryptsetup API also introduces flags
CRYPT_COMPAT_LEGACY_INTEGRITY_HMAC and
CRYPT_COMPAT_LEGACY_INTEGRITY_RECALC
to set these through crypt_set_compatibility() call.
All POPT_ARG_STRING pointers must be free'd manually
in calling application. This is unfortunately not documented
well behaviour of popt and we were having memory leaks due to
it.
This is part of effort to eliminate all memory leaks related
to options parsing in popt but for that to work we must avoid
passing constant strings to free().
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.
* Rename "BASIC COMMANDS" to "BASIC ACTIONS"
* Changed a sentence saying that luksFormat would work on unmapped luks containers, only.
* Insert 6 examples of using cryptsetup for luks containers
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 zero data parts of the test images to make them as small as
possible and for the latest startup key image I deleted bigger
portion of the NTFS header by accident which caused older blkid
on CentOS/RHEL 6 to not identify the NTFS filesystem on the
cleartext device.
