From: Szabolcs Nagy <szabolcs.nagy@arm.com>
To: Mikulas Patocka <mpatocka@redhat.com>, libc-alpha@sourceware.org
Cc: Zdenek Kabelac <zkabelac@redhat.com>,
Ondrej Kozina <okozina@redhat.com>,
Milan Broz <gmazyland@gmail.com>,
dm-devel@lists.linux.dev
Subject: Re: memcpy is leaking secret data through ZMM vector registers
Date: Mon, 22 Apr 2024 10:33:30 +0100 [thread overview]
Message-ID: <ZiYu6laGnTGbkRCS@arm.com> (raw)
In-Reply-To: <a139443-d6de-7be1-c59b-c099b0b32884@redhat.com>
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
>
prev parent reply other threads:[~2024-04-22 9:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-19 14:07 memcpy is leaking secret data through ZMM vector registers Mikulas Patocka
2024-04-19 14:19 ` H.J. Lu
2024-04-19 14:24 ` Mikulas Patocka
2024-04-19 14:37 ` H.J. Lu
2024-04-19 18:04 ` Mikulas Patocka
2024-04-19 18:45 ` Paul Eggert
2024-04-19 18:47 ` Zack Weinberg
2024-04-19 18:53 ` Alexander Monakov
2024-04-19 19:11 ` Zack Weinberg
2024-04-19 20:15 ` Mikulas Patocka
2024-04-19 20:31 ` Zack Weinberg
2024-04-19 21:11 ` Mikulas Patocka
2024-04-19 23:27 ` Florian Weimer
2024-04-20 3:29 ` Zack Weinberg
2024-04-21 1:20 ` Andreas K. Huettel
2024-04-22 9:33 ` Szabolcs Nagy [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZiYu6laGnTGbkRCS@arm.com \
--to=szabolcs.nagy@arm.com \
--cc=dm-devel@lists.linux.dev \
--cc=gmazyland@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=mpatocka@redhat.com \
--cc=okozina@redhat.com \
--cc=zkabelac@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).