The 04/19/2024 16:07, Mikulas Patocka wrote:
> Hi
>
> As a part of LVM2, we are developing the libdevmapper library. The library
> may be used to load cryptographic keys to the kernel, so it avoids leaking
> the data to kernel memory and to the swap partition.
>
> After the use of cryptographic data, the libdevmapper library clears them
> with memset and frees them afterwards. It executes __asm__ volatile("" :::
> "memory") to thwart some compiler optimization regarding writing to
> to-be-freed memory.
instead of
crypto_foo(key);
dont_optimize_me_memset(key, 0, sizeof key);
can you do
crypto_foo(key);
memcpy(key, dummykey, sizeof key);
crypto_foo(key);
memcpy(key, dummykey, sizeof key);
if there is no sensitive data based conditional in
the code (which there should not be in crypto logic
nor in memcpy) the exact same registers and
instructions should be exercised twice. i.e. you
clobber all state in a portable way, no arch
specific magic hack is needed nor new compiler flag.
technically this can still leak information in all
sorts of ways (c is a high level language, internally
the implementation can do whatever with the secrets),
but this is pretty much how far you can go within c
(pretending otherwise with random weird compiler or
libc extensions is a mistake imho).
>
> We have a test "dmsecuretest.sh" that loads cryptographic keys into the
> kernel, dumps a core, the core file is analyzed and if it contains the
> key, the test fails.
>
> This test fails on AMD Zen 4 - the reason for the failure is that the
> "memcpy" function uses ZMM registers for data copying. When memcpy exits,
> the encryption key is present in the ZMM registers and the key remains
> there even after both source and destination buffers of memcpy were
> cleared.
>
> When we perform dynamic symbol lookup, the ZMM registers are spilled on
> the stack and they remain there forever - this is the reason why the core
> file contains the encryption key and the test fails.
>
> I'd like to ask what to do with it? We could use LD_BIND_NOW=1 (or
> -Wl,-z,now) - it mostly works, but not entirely - the key may still be
> present on the stack even if we use LD_BIND_NOW=1.
>
> When I hack the file glibc/sysdeps/x86_64/multiarch/ifunc-memmove.h so
> that it always selects the ERMS variant of memcpy, the problem goes away.
>
> Could it be possible to add some switch to glibc, that could be turned on
> by security-sensitive programs and that would prevent glibc from using the
> vector registers? Or, do you suggest another solution?
>
> Mikulas
>
