Return type of getrandom(2)

Return type of getrandom(2)

[Florian Weimer]

The manual page says the return type of getrandom(2) is int, but
ssize_t would be more natural (see read(2) for comparison).  The
kernel uses ssize_t internally, which is converted to long on the
system call boundary.

The difference does not currently matter because the return value is
limited to much less than INT_MAX in the implementation.

Should we use int or ssize_t in the glibc system call wrapper?

Re: Return type of getrandom(2)

[Theodore Ts'o]

On Sat, Oct 08, 2016 at 02:28:27PM +0200, Florian Weimer wrote:
> The manual page says the return type of getrandom(2) is int, but
> ssize_t would be more natural (see read(2) for comparison).  The
> kernel uses ssize_t internally, which is converted to long on the
> system call boundary.
> 
> The difference does not currently matter because the return value is
> limited to much less than INT_MAX in the implementation.
> 
> Should we use int or ssize_t in the glibc system call wrapper?

I'd suggest keeping it as an int since (a) OpenBSD's getentropy(2)
returns an int, and part of the orignal design goal is to be able to
emulate OpenBSD's getentropy(2) system call via:

int getentropy(void *buf, size_t buflen)
{
	return getrandom(buf, buflen, 0);
}

and (b) the maximum number of bytes returned will *always* be well
under INT_MAX.  I can't forsee at any point in any future or alternate
universe where getrandom() would need to return anywhere near
SHORT_MAX, let alone INT_MAX.

Cheers,

					- Ted

Re: Return type of getrandom(2)

[Florian Weimer]

* Theodore Ts'o:

> On Sat, Oct 08, 2016 at 02:28:27PM +0200, Florian Weimer wrote:
>> The manual page says the return type of getrandom(2) is int, but
>> ssize_t would be more natural (see read(2) for comparison).  The
>> kernel uses ssize_t internally, which is converted to long on the
>> system call boundary.
>> 
>> The difference does not currently matter because the return value is
>> limited to much less than INT_MAX in the implementation.
>> 
>> Should we use int or ssize_t in the glibc system call wrapper?
>
> I'd suggest keeping it as an int since (a) OpenBSD's getentropy(2)
> returns an int, and part of the orignal design goal is to be able to
> emulate OpenBSD's getentropy(2) system call via:
>
> int getentropy(void *buf, size_t buflen)
> {
> 	return getrandom(buf, buflen, 0);
> }

But this implementation is quite wrong.  It has to look like something
like this:

int
getentropy (void *buf, size_t buflen)
{
  ssize_t ret = getrandom (buf, buflen, 0)
  if (ret < 0)
    return -1;
  if (ret < buflen)
    {
      errno = EIO;
      return -1;
    }
  return 0;
}

The ssize_t return would hint to the fact that such a wrapper is
required because the interfaces are somewhat different.

> and (b) the maximum number of bytes returned will *always* be well
> under INT_MAX.  I can't forsee at any point in any future or alternate
> universe where getrandom() would need to return anywhere near
> SHORT_MAX, let alone INT_MAX.

Right, that's true for the Linux implementation.  The question is
whether it applies to other implementations as well.  Solaris appears
to have an even lower limit.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Return type of getrandom(2)

[Andy Lutomirski]

On Oct 8, 2016 4:17 PM, "Theodore Ts'o" <tytso-3s7WtUTddSA@public.gmane.org> wrote:
>
> On Sat, Oct 08, 2016 at 02:28:27PM +0200, Florian Weimer wrote:
> > The manual page says the return type of getrandom(2) is int, but
> > ssize_t would be more natural (see read(2) for comparison).  The
> > kernel uses ssize_t internally, which is converted to long on the
> > system call boundary.
> >
> > The difference does not currently matter because the return value is
> > limited to much less than INT_MAX in the implementation.
> >
> > Should we use int or ssize_t in the glibc system call wrapper?

I think it should be ssize_t.  Having the types mismatched across the
syscall boundary is just confusing.

(b) the maximum number of bytes returned will *always* be well
> under INT_MAX.

I would argue that this particular ship sailed when the len parameter
was given the type size_t.  The door is open for requests bigger than
2GiB.  Even if Linux will never honor those requests, I see no reason
to make their return value have a nonsensical type.

--Andy

Re: Return type of getrandom(2)

[Florian Weimer]

* Andy Lutomirski:

> On Oct 8, 2016 4:17 PM, "Theodore Ts'o" <tytso-3s7WtUTddSA@public.gmane.org> wrote:
>>
>> On Sat, Oct 08, 2016 at 02:28:27PM +0200, Florian Weimer wrote:
>> > The manual page says the return type of getrandom(2) is int, but
>> > ssize_t would be more natural (see read(2) for comparison).  The
>> > kernel uses ssize_t internally, which is converted to long on the
>> > system call boundary.
>> >
>> > The difference does not currently matter because the return value is
>> > limited to much less than INT_MAX in the implementation.
>> >
>> > Should we use int or ssize_t in the glibc system call wrapper?
>
> I think it should be ssize_t.  Having the types mismatched across the
> syscall boundary is just confusing.
>
>> (b) the maximum number of bytes returned will *always* be well
>> under INT_MAX.
>
> I would argue that this particular ship sailed when the len parameter
> was given the type size_t.  The door is open for requests bigger than
> 2GiB.  Even if Linux will never honor those requests, I see no reason
> to make their return value have a nonsensical type.

Thanks for your input.  I'm leaning towards ssize_t now as well.
Ted's getentropy example was helpful as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html