From: Zack Weinberg <zackw@panix.com>
To: libc-alpha@sourceware.org
Cc: carlos@redhat.com, fweimer@redhat.com
Subject: [PATCH 0/3] explicit_bzero v5
Date: Tue, 15 Nov 2016 15:55:00 -0000 [thread overview]
Message-ID: <20161115155509.12692-1-zackw@panix.com> (raw)
I would really like to get this into 2.25, and I believe that I have
addressed all substantive objections. Please review.
The core implementation strategy is the same as for the previous
iteration. Changes since then are:
* All of the ABI-affecting changes appear in patch 1/3 to minimize
clutter. (The plan is still to squash all three commits into one
for landing.)
* libc.so now exports __explicit_bzero as well as explicit_bzero; the
implementation-namespace symbol is used by libcrypt.so, and the
user-namespace symbol is weak. (Requested by Joseph, iirc.)
The impl-namespace symbol is versioned GLIBC_2.25 instead of
GLIBC_PRIVATE, because that seems to be what was done for other
impl-namespace aliases for string functions. I wasn't able to find
anything definitive about when GLIBC_PRIVATE should be used.
* tst-xbzero-opt.c has been tightened up a bit.
* The interaction between bits/string2.h and bits/string3.h should
now be more robust.
* The documentation has been revised per Paul Eggert's comments.
Paul Eggert also observed that a call to explicit_bzero might expose
the _address_ of a buffer containing sensitive data, and perhaps
another thread could exfiltrate the data before it was erased.
I thought about it and I have concluded that this, like the other
remaining problems with this API, needs to be addressed in the
compiler; there's nothing glibc can reasonably do about it.
Clobbering all caller-save registers and incoming argument space is
the best thing we _could_ do about it, but that would have to happen
_after_ the memset, so it doesn't actually help.
zw
Zack Weinberg (3):
New string function explicit_bzero (from OpenBSD).
Add fortification and inline optimization of explicit_bzero.
Use explicit_bzero where appropriate
crypt/crypt-entry.c | 11 +
crypt/md5-crypt.c | 8 +-
crypt/sha256-crypt.c | 14 +-
crypt/sha512-crypt.c | 14 +-
debug/tst-chk1.c | 28 ++
include/string.h | 12 +
manual/string.texi | 124 ++++++++
string/Makefile | 12 +-
string/Versions | 10 +
string/bits/string2.h | 11 +
string/bits/string3.h | 8 +
string/explicit_bzero.c | 33 ++
string/read_memory.c | 41 +++
string/string.h | 9 +
string/test-explicit_bzero.c | 20 ++
string/test-memset.c | 10 +-
string/tst-xbzero-opt.c | 348 +++++++++++++++++++++
sysdeps/arm/nacl/libc.abilist | 3 +
sysdeps/unix/sysv/linux/aarch64/libc.abilist | 3 +
sysdeps/unix/sysv/linux/alpha/libc.abilist | 3 +
sysdeps/unix/sysv/linux/arm/libc.abilist | 3 +
sysdeps/unix/sysv/linux/hppa/libc.abilist | 3 +
sysdeps/unix/sysv/linux/i386/libc.abilist | 3 +
sysdeps/unix/sysv/linux/ia64/libc.abilist | 3 +
sysdeps/unix/sysv/linux/m68k/coldfire/libc.abilist | 3 +
sysdeps/unix/sysv/linux/m68k/m680x0/libc.abilist | 3 +
sysdeps/unix/sysv/linux/microblaze/libc.abilist | 3 +
.../unix/sysv/linux/mips/mips32/fpu/libc.abilist | 3 +
.../unix/sysv/linux/mips/mips32/nofpu/libc.abilist | 3 +
.../unix/sysv/linux/mips/mips64/n32/libc.abilist | 3 +
.../unix/sysv/linux/mips/mips64/n64/libc.abilist | 3 +
sysdeps/unix/sysv/linux/nios2/libc.abilist | 3 +
.../sysv/linux/powerpc/powerpc32/fpu/libc.abilist | 3 +
.../linux/powerpc/powerpc32/nofpu/libc.abilist | 3 +
.../sysv/linux/powerpc/powerpc64/libc-le.abilist | 3 +
.../unix/sysv/linux/powerpc/powerpc64/libc.abilist | 3 +
sysdeps/unix/sysv/linux/s390/s390-32/libc.abilist | 3 +
sysdeps/unix/sysv/linux/s390/s390-64/libc.abilist | 3 +
sysdeps/unix/sysv/linux/sh/libc.abilist | 3 +
sysdeps/unix/sysv/linux/sparc/sparc32/libc.abilist | 3 +
sysdeps/unix/sysv/linux/sparc/sparc64/libc.abilist | 3 +
.../sysv/linux/tile/tilegx/tilegx32/libc.abilist | 3 +
.../sysv/linux/tile/tilegx/tilegx64/libc.abilist | 3 +
sysdeps/unix/sysv/linux/tile/tilepro/libc.abilist | 3 +
sysdeps/unix/sysv/linux/x86_64/64/libc.abilist | 3 +
sysdeps/unix/sysv/linux/x86_64/x32/libc.abilist | 3 +
46 files changed, 778 insertions(+), 22 deletions(-)
create mode 100644 string/explicit_bzero.c
create mode 100644 string/read_memory.c
create mode 100644 string/test-explicit_bzero.c
create mode 100644 string/tst-xbzero-opt.c
--
2.10.2
next reply other threads:[~2016-11-15 15:55 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-15 15:55 Zack Weinberg [this message]
2016-11-15 15:55 ` [PATCH 1/3] New string function explicit_bzero (from OpenBSD) Zack Weinberg
2016-11-15 15:55 ` [PATCH 2/3] Add fortification and inline optimization of explicit_bzero Zack Weinberg
2016-11-15 15:55 ` [PATCH 3/3] Use explicit_bzero where appropriate Zack Weinberg
2016-11-16 18:38 ` [PATCH 1/3] New string function explicit_bzero (from OpenBSD) Michael Kerrisk (man-pages)
2016-11-15 16:20 ` [PATCH 0/3] explicit_bzero v5 Paul Eggert
2016-11-15 17:46 ` Zack Weinberg
2016-11-15 18:02 ` Paul Eggert
2016-11-15 18:42 ` Florian Weimer
2016-11-15 18:54 ` Zack Weinberg
2016-11-15 19:35 ` Paul Eggert
2016-11-16 14:56 ` Zack Weinberg
2016-11-16 21:38 ` Paul Eggert
2016-11-16 18:34 ` Michael Kerrisk (man-pages)
2016-11-15 19:35 ` Paul Eggert
2016-11-16 14:58 ` Zack Weinberg
2016-11-15 21:12 ` Richard Henderson
2016-11-16 14:45 ` Zack Weinberg
2016-11-16 14:58 ` Andreas Schwab
2016-11-16 15:00 ` Zack Weinberg
2016-11-16 15:09 ` Andreas Schwab
2016-11-16 15:14 ` Zack Weinberg
2016-11-16 15:22 ` Andreas Schwab
2016-11-16 20:06 ` Richard Henderson
2016-11-16 2:03 ` Joseph Myers
2016-11-16 15:06 ` Zack Weinberg
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=20161115155509.12692-1-zackw@panix.com \
--to=zackw@panix.com \
--cc=carlos@redhat.com \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
/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).