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.
The content of LUKS header is not a key material, no need
to lock memory for possibly big header and big memory area locks.
Just ensure we wipe buffer before release of memory.
This patch locks all memory ranges in safe allocations.
While crypto backend can have some secure memory calls,
it is usually limited by intitial config.
For our use is enough to keep keys in memory and prevent
swapping it out.
If the lock fails (because of limits) we quietly
stay with plain malloc.
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.
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.
