Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1255910

Re: Getrandom wrapper

From Florian Weimer <fweimer@redhat.com>
Newsgroups linux.kernel
Subject Re: Getrandom wrapper
Date 2015-10-26 14:40 +0100
Message-ID <qnQae-mF-19@gated-at.bofh.it> (permalink)
References (6 earlier) <qnr29-1Dl-7@gated-at.bofh.it> <qnr2a-1Dl-23@gated-at.bofh.it> <qns7U-2xF-3@gated-at.bofh.it> <qntnj-3sA-1@gated-at.bofh.it> <qntQl-3Cr-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 10/25/2015 02:40 PM, Theodore Ts'o wrote:
> On Sun, Oct 25, 2015 at 02:17:23PM +0100, Florian Weimer wrote:
>>
>> I think we can reach consensus for an implementation which makes this code
>>
>>   unsigned char session_key[32];
>>   getrandom (session_key, sizeof (session_key), 0);
>>   install_session_key (session_key);
>>
>> correct.  That is, no error handling code for ENOMEM, ENOSYS, EINTR,
>> ENOMEM or short reads is necessary.  It seems that several getrandom
>> wrappers currently built into applications do not get this completely right.
> 
> The only error handling code that is necessary is a fallback for
> ENOSYS.  getrandom(2) won't return ENOMEM, and if the number of bytes
> requested is less than or equal to 256 bytes, it won't return EINTR
> either.

Not even during early boot?  The code suggests that you can get EINTR if
the non-blocking pool isn't initialized yet.  With VMs, that
initialization can happen quite some time after boot, when the userland
is well under way.

> As far as ENOSYS is concerned, a fallback gets tricky; you could try
> to open /dev/urandom, and read from it, but that can fail due to
> EMFILE, ENFILE, ENOENT (if they are chrooted and /dev wasn't properly
> populated).  So attempting a fallback for ENOSYS can actually expand
> the number of potential error conditions for the userspace application
> to (fail to) handle.  I suppose you could attempt the fallback and
> call abort(2) if the fallback fails, which is probably the safe and
> secure thing to do, but applications might not appreciate getting
> terminated without getting a chance to do something (but if the
> something is just calling random(3), maybe not giving them a chance to
> do something insane is the appropriate thing to do....)

I'm more worried that the fallback code could be triggered
unexpectedly on some obscure code path that is not tested regularly, and
runs into a failure.  I suspect a high-quality implementation of
getrandom would have to open /dev/random and /devurandom when the
getrandom symbol is resolved, and report failure at that point, to avoid
late surprises.

Florian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Tejun Heo <tj@kernel.org> - 2015-10-24 00:30 +0200
  Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-10-24 06:40 +0200
    Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Tejun Heo <tj@kernel.org> - 2015-10-25 03:20 +0100
      Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-10-25 04:50 +0100
        Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Tejun Heo <tj@kernel.org> - 2015-10-27 04:20 +0100
          Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-10-27 06:50 +0100
            Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Tejun Heo <tj@kernel.org> - 2015-10-27 06:50 +0100
              Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-10-27 07:00 +0100
                Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Tejun Heo <tj@kernel.org> - 2015-10-27 07:10 +0100
                Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Mike Galbraith <umgwanakikbuti@gmail.com> - 2015-10-27 07:10 +0100
      Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy Linus Torvalds <torvalds@linux-foundation.org> - 2015-10-25 05:00 +0100
        Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Ingo Molnar <mingo@kernel.org> - 2015-10-25 10:40 +0100
          Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Theodore Ts'o <tytso@mit.edu> - 2015-10-25 11:50 +0100
            Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Florian Weimer <fweimer@redhat.com> - 2015-10-25 11:50 +0100
              Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Theodore Ts'o <tytso@mit.edu> - 2015-10-25 13:00 +0100
                Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Florian Weimer <fweimer@redhat.com> - 2015-10-25 14:20 +0100
                Getrandom wrapper Theodore Ts'o <tytso@mit.edu> - 2015-10-25 14:50 +0100
                Re: Getrandom wrapper Florian Weimer <fweimer@redhat.com> - 2015-10-26 14:40 +0100
                Re: [PATCH 3/3] sched: Implement interface for cgroup unified  hierarchy Peter Zijlstra <peterz@infradead.org> - 2015-10-26 15:20 +0100

csiph-web