From: Hauke Mehrtens <hauke@hauke-m.de>
To: musl@lists.openwall.com, Rich Felker <dalias@libc.org>
Subject: Re: [PATCH v2] Add getrandom syscall wrapper and getentropy function
Date: Sun, 21 Jan 2018 14:22:56 +0100 [thread overview]
Message-ID: <64831ed9-fd78-281b-b522-fc581b0d4587@hauke-m.de> (raw)
In-Reply-To: <20180109184813.GD1627@brightrain.aerifal.cx>
On 01/09/2018 07:48 PM, Rich Felker wrote:
> On Sat, Jan 06, 2018 at 11:08:09PM +0100, Hauke Mehrtens wrote:
>> This syscall is available since Linux 3.17 and was also implemented in
>> glibc in version 2.25 using the same interfaces.
>> The getrandom function is a pure syscall wrapper liker glibc does it.
>> getentropy is implemented on top of the getrandom syscall and fills the
>> buffer.
>>
>> Currently no fallback is implemented this could be possible by using
>> AT_RANDOM in the future.
>> ---
>> include/sys/random.h | 21 +++++++++++++++++++++
>> src/linux/getentropy.c | 29 +++++++++++++++++++++++++++++
>> src/linux/getrandom.c | 7 +++++++
>> 3 files changed, 57 insertions(+)
>> create mode 100644 include/sys/random.h
>> create mode 100644 src/linux/getentropy.c
>> create mode 100644 src/linux/getrandom.c
>>
>> diff --git a/include/sys/random.h b/include/sys/random.h
>> new file mode 100644
>> index 00000000..5b09e394
>> --- /dev/null
>> +++ b/include/sys/random.h
>> @@ -0,0 +1,21 @@
>> +#ifndef _SYS_RANDOM_H
>> +#define _SYS_RANDOM_H
>> +#ifdef __cplusplus
>> +extern "C" {
>> +#endif
>> +
>> +#define __NEED_size_t
>> +#define __NEED_ssize_t
>> +#include <bits/alltypes.h>
>> +
>> +#define GRND_NONBLOCK 0x0001
>> +#define GRND_RANDOM 0x0002
>> +
>> +ssize_t getrandom(void *buf, size_t buflen, unsigned int flags);
>> +
>> +int getentropy(void *buffer, size_t length);
>
> Needs to drop namespace pollution in arg lists; just don't use names
> here.
Will do that.
>
>> +#ifdef __cplusplus
>> +}
>> +#endif
>> +#endif
>> diff --git a/src/linux/getentropy.c b/src/linux/getentropy.c
>> new file mode 100644
>> index 00000000..48ca3d51
>> --- /dev/null
>> +++ b/src/linux/getentropy.c
>> @@ -0,0 +1,29 @@
>> +#include <sys/random.h>
>> +#include <errno.h>
>> +#include "syscall.h"
>> +
>> +int getentropy(void *buffer, size_t length)
>> +{
>> + int ret;
>> + char *pos = buffer;
>> + size_t rem = length;
>> +
>> + if (length > 256) {
>> + return __syscall_ret(-EIO);
>> + }
>> +
>> + while (rem) {
>> + ret = __syscall_cp(SYS_getrandom, pos, rem, 0);
>
> My understanding was that the glibc choice was not to make getentropy
> a cancellation point. If that's correct, is there a reason you want to
> do it differently?
Ok I will change this, glibc made getentropy no cancellation point, but
getrandom is a cancellation point I will do it the same way here.
From glibc documentation:
> The @code{getentropy} function is not a cancellation point. A call to
> @code{getentropy} can block if the system has just booted and the
> kernel entropy pool has not yet been initialized. In this case, the
> function will keep blocking even if a signal arrives, and return only
> after the entropy pool has been initialized.
> The @code{getrandom} function is a cancellation point.
Source:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=92dcaa3e2f7bf0f7f1c04cd2fb6a317df1a4e225
>
>> + if (ret == -EINTR) {
>> + continue;
>
> This in particular seems inconsistent with making it cancellable, but
> maybe the idea is to avoid issues where the caller does not check the
> return.
>
>> + } else if (ret == -EFAULT || ret == -ENOSYS) {
>> + return __syscall_ret(ret);
>> + } else if (ret <= 0) {
>> + return __syscall_ret(-EIO);
>> + }
>
> Is there a reason for collapsing some possible error conditions but
> not others?
The man page said that getentropy only returns, EFAULT, EIO or ENOSYS.
Should I forward all errors?
>> +
>> + pos += ret;
>> + rem -= ret;
>> + }
>> + return 0;
>> +}
>
> Overall, my leaning for getentropy would be to implement it as a
> wrapper around getrandom using the public interfaces (e.g.
> pthread_setcancelstate if cancellation is to be blocked, and errno
> rather than -EFOO stuff), with the idea that it should not need to be
> changed if we later implement fallbacks for getrandom and that it be a
> "generic" file that not depend on musl internals.
In glibc it is not a cancellation point, so should I call the syscall
directly with no cancellation point or should I call the getrandom())
function which has a cancellation point?
>> diff --git a/src/linux/getrandom.c b/src/linux/getrandom.c
>> new file mode 100644
>> index 00000000..795b932c
>> --- /dev/null
>> +++ b/src/linux/getrandom.c
>> @@ -0,0 +1,7 @@
>> +#include <sys/random.h>
>> +#include "syscall.h"
>> +
>> +ssize_t getrandom(void *buf, size_t buflen, unsigned int flags)
>> +{
>> + return syscall_cp(SYS_getrandom, buf, buflen, flags);
>> +}
>
> This part looks fine, I think.
>
> Rich
>
Hauke
prev parent reply other threads:[~2018-01-21 13:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-06 22:08 Hauke Mehrtens
2018-01-08 22:06 ` William Pitcock
2018-01-09 18:48 ` Rich Felker
2018-01-21 13:22 ` Hauke Mehrtens [this message]
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=64831ed9-fd78-281b-b522-fc581b0d4587@hauke-m.de \
--to=hauke@hauke-m.de \
--cc=dalias@libc.org \
--cc=musl@lists.openwall.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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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 NNTP newsgroup(s).