public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Zack Weinberg <zackw@panix.com>
To: Florian Weimer <fweimer@redhat.com>, Torvald Riegel <triegel@redhat.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH v9] Add getentropy, getrandom, <sys/random.h> [BZ #17252]
Date: Tue, 06 Dec 2016 13:41:00 -0000	[thread overview]
Message-ID: <90908be7-c7db-46f2-a635-27dc5604e47f@panix.com> (raw)
In-Reply-To: <680d0bed-b164-b809-d672-e0278fe08d7e@redhat.com>

On 12/06/2016 07:55 AM, Florian Weimer wrote:
> On 12/02/2016 05:47 PM, Torvald Riegel wrote:
>> On Wed, 2016-11-30 at 17:15 +0100, Florian Weimer wrote:
>>> On 11/30/2016 02:33 PM, Florian Weimer wrote:
>>>> This iteration of the patch implements both getrandom and getentropy at
>>>> the same time.
>>
>> This basically looks good to me (though I'm no expert on the actual
>> syscall etc.).
> 
> Thanks.
> 
> Zack, would you comment as well, please?

The 256-byte limit is unfortunate but I see why we want it.

I think you should remove this assertion:

+      /* The Linux implementation never returns zero if the length
+         argument is not zero, and does not perform a short read for
+         sizes <= 256.  */
+      assert (bytes == length);

it strikes me as Knowing Too Much about the kernel interface.

My only other remaining concern is the name mangling, and unfortunately
we really do have to resolve that before this can be committed, because
we'll be stuck with whatever decision we make here forever.

I still don't really understand what problems you are trying to solve by
mangling names, I still think that ad-hoc addition of mangled names with
forcible redirection in the headers is unlikely to be the *correct* fix
to whatever the problems actually are, and most importantly of all, I
still don't understand why you are convinced *these particular symbols*
need "interposition protection".  You said

> getentropy definitely needs interposition protection because it is
> frequently redefined.  We'll need to rebuild a distribution to see if
> the current approach is sufficient.  For consistency, I also added
> interposition protection for getrandom.

and this makes absolutely no sense at all to me.  Is it not the case
that people are defining getentropy and/or getrandom *because* libc
doesn't?  Won't their build systems notice (via AC_REPLACE_FUNCS or
equivalent) that libc is now defining them, and stop?

A concrete example of a real program or combination of programs, that
will break if we don't do this, would be really helpful to me.  Not a
demo, please, something that already exists in the wild.

zw

  reply	other threads:[~2016-12-06 13:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-30 13:33 [PATCH v8] " Florian Weimer
2016-11-30 16:15 ` [PATCH v9] " Florian Weimer
2016-12-02 16:47   ` Torvald Riegel
2016-12-06 12:55     ` Florian Weimer
2016-12-06 13:41       ` Zack Weinberg [this message]
2016-12-06 14:03         ` Florian Weimer
2016-12-06 17:11           ` Zack Weinberg
2016-12-06 18:42             ` Zack Weinberg
2016-12-07 11:18               ` Florian Weimer
2016-12-07 14:47                 ` Zack Weinberg
2016-12-06 16:42         ` Joseph Myers
2016-12-06 16:51           ` Zack Weinberg
2016-12-06 16:55             ` Joseph Myers
2016-12-06 16:59               ` Florian Weimer
2016-12-06 17:02                 ` Joseph Myers
2016-12-07 10:52                   ` Florian Weimer
2016-12-06 17:14               ` 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=90908be7-c7db-46f2-a635-27dc5604e47f@panix.com \
    --to=zackw@panix.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=triegel@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).