public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Zack Weinberg <zackw@panix.com>
Cc: <libc-alpha@sourceware.org>, <carlos@redhat.com>, <fweimer@redhat.com>
Subject: Re: [PATCH 0/3] explicit_bzero v5
Date: Wed, 16 Nov 2016 02:03:00 -0000	[thread overview]
Message-ID: <alpine.DEB.2.20.1611160154380.2244@digraph.polyomino.org.uk> (raw)
In-Reply-To: <20161115155509.12692-1-zackw@panix.com>

On Tue, 15 Nov 2016, Zack Weinberg wrote:

>  * 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.)

Requested by Florian (together with header pieces to cause normal calls to 
explicit_bzero to end up calling the implementation-namespace version) 
because of concerns about interposition.

>    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.

We need an implementation-namespace export for libcrypt use for namespace 
reasons [*].

If it's only for libcrypt use, GLIBC_PRIVATE would suffice.  If we want to 
support it for other libraries limiting the namespace they use, with or 
without header pieces to protect against accidental interposition, a 
GLIBC_2.25 export is needed.


[*] I had thought libcrypt was irrelevant for linknamespace issues, but 
actually I just missed that it should be included in the linknamespace 
tests because I took the list of libraries to consider there from the 
POSIX rules for which functions require which libraries for linking with 
the POSIX c99 utility.  glibc has separate libdl and libcrypt libraries 
for some POSIX functions, although POSIX does not mention such libraries, 
so a correct implementation of that utility with glibc would need to 
handle linking with those libraries automatically.  The only existing 
namespace bug I see on x86_64 or x86 when adding libcrypt / libdl to the 
libraries checked in the linknamespace tests is use of snprintf in crypt 
functions when not reserved by XPG3/XPG4; I'll deal with that before 
committing the linknamespace support.  crypt.h is indeed non-POSIX, but 
XSI POSIX has the functions in unistd.h.

> Zack Weinberg (3):
>   New string function explicit_bzero (from OpenBSD).
>   Add fortification and inline optimization of explicit_bzero.
>   Use explicit_bzero where appropriate

I'd expect a NEWS entry to be included somewhere in the patch series.

-- 
Joseph S. Myers
joseph@codesourcery.com

  parent reply	other threads:[~2016-11-16  2:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-15 15:55 Zack Weinberg
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 [this message]
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=alpine.DEB.2.20.1611160154380.2244@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=carlos@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=zackw@panix.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).