lkml.org 
[lkml]   [2014]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH, RFC] random: introduce getrandom(2) system call
    From
    Date
    Hi,

    I am wondering if we could improve the design of the system call a bit
    to prevent programming errors.
    Right now, EINVAL is returned in case of invalid flags (or in the older
    version of getrandom() also if buflen is too large), EFAULT if buf is an
    invalid address and EAGAIN if there is not enough entropy.

    However, of course no programmer is save against programming errors.
    Everybody *should* check the return value of syscalls, but sometimes it
    is forgotten, and theoretically you must be stoned to death for that.

    Still, we should think about how we could prevent these errors. Here is
    a list of possible modifications of getrandom() and pros and cons:

    1. memset(buf, 0x0, buflen) in case of an error
    pros:
    - it is more obvious to the userspace programmer that the content of
    buffer does *not* contain random bytes
    cons:
    - in case even the zero-ed buf is not noticed by the programmer, she/he
    might end up using a 100% predictable string of "random bytes". In
    contrast if zero-ing the buf is ommitted, you would at least end up
    using some (not-cryptographically) random bytes from somewhere in RAM.

    I am aware that this memset() call should theoretically be superfluous
    but it would only be executed in very rare cases where the programmer
    misuses getrandom().


    2. int getrandom(void **buf, size_t buflen, unsigned int flags)
    ^^
    If flags, are fine, return a pointer to a buffer of random bytes,
    otherwise return a pointer to NULL.

    pros:
    - it would ensure that an error in a getrandom() call cannot be
    ignored.
    cons:
    - not sure if a syscall should allocate memory in the name of a
    userspace program
    - not a very unix-like syscall signature
    - anytime getrandom() is called, it will allocate a new buffer which
    might end up in decreased performance (however, getrandom() should not
    be called multiple times)


    3. send a signal to the userland process that (by default) leads to an
    abnormal termination of the process
    Essentially an error in getrandom() could be seen as critical as a
    division by 0.

    pros:
    - the userspace programmer is forced to handle this error (otherwise
    the signal would terminate the program)
    cons:
    - adds more complexity to the userspace program that might lead to new
    programming errors


    These are three possibilities. Maybe one of you is more creative and can
    come up with a much better idea. At the moment, I like option 2 the
    best, because it forces the programmer to deal with these errors, but
    probably one of you has a good point why this is not a good idea.
    Handling the NULL pointer would be much easier than using signals
    (option 3). However, it lead to a syscall signature that is different
    from, let's say read(), because the syscall itself would allocate its
    buffer.

    Again, I am aware that you must always check return values, but
    programming errors happen. E.g. everybody knows that you cannot trust
    data that you received via network, yet heartbleed happened.
    Here we have the chance to eradicate a critical programming error by
    improving the syscall design and I think we should spend some time
    thinking about that.


    Best,

    Manuel




    \
     
     \ /
      Last update: 2014-07-23 11:21    [W:7.739 / U:1.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site