From: Florian Weimer <fweimer@redhat.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Zack Weinberg <zack@owlfolio.org>,
Alexander Monakov <amonakov@ispras.ru>,
Paul Eggert <eggert@cs.ucla.edu>,
"H . J . Lu" <hjl.tools@gmail.com>,
GNU libc development <libc-alpha@sourceware.org>,
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: Sat, 20 Apr 2024 01:27:57 +0200 [thread overview]
Message-ID: <878r196igy.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <c5ac58cf-3e2e-3cc4-5a18-32c9acdef82d@redhat.com> (Mikulas Patocka's message of "Fri, 19 Apr 2024 23:11:54 +0200 (CEST)")
* Mikulas Patocka:
> On Fri, 19 Apr 2024, Zack Weinberg wrote:
>
>> On Fri, Apr 19, 2024, at 4:15 PM, Mikulas Patocka wrote:
>> > On Fri, 19 Apr 2024, Zack Weinberg wrote:
>> >> ... the copy
>> >> of round_keys in the vector registers *won't* get erased -- the exact
>> >> problem being discussed in this thread.
>> >
>> > On the SYSV ABI, all the vector registers are volatile, so you can erase
>> > them in explicit_bzero.
>> >
>> > On Windows 64-bit ABI, it is more problematic, because some of the vector
>> > registers must be preserved.
>>
>> Oh, huh. Yes, that would work.
>
> I've just realized that this wouldn't work - if the function
> explicit_bzero is lazily resolved, the dynamic linker would spill the
> vector registers to the stack prior to calling explicit_bzero.
No, the dynamic linker makes a tail call to explicit_bzero. There's no
register restore on the return path, all that happens before the tail
call.
Thanks,
Florian
next prev parent reply other threads:[~2024-04-19 23:28 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 [this message]
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=878r196igy.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=amonakov@ispras.ru \
--cc=dm-devel@lists.linux.dev \
--cc=eggert@cs.ucla.edu \
--cc=gmazyland@gmail.com \
--cc=hjl.tools@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=mpatocka@redhat.com \
--cc=okozina@redhat.com \
--cc=zack@owlfolio.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.