From: Mikulas Patocka <mpatocka@redhat.com>
To: 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: memcpy is leaking secret data through ZMM vector registers
Date: Fri, 19 Apr 2024 16:07:50 +0200 (CEST) [thread overview]
Message-ID: <a139443-d6de-7be1-c59b-c099b0b32884@redhat.com> (raw)
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.
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
next reply other threads:[~2024-04-19 14:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-19 14:07 Mikulas Patocka [this message]
2024-04-19 14:19 ` memcpy is leaking secret data through ZMM vector registers 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
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=a139443-d6de-7be1-c59b-c099b0b32884@redhat.com \
--to=mpatocka@redhat.com \
--cc=dm-devel@lists.linux.dev \
--cc=gmazyland@gmail.com \
--cc=libc-alpha@sourceware.org \
--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).