[Bug libc/17252] getrandom and getentropy syscall

["fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17252

--- Comment #2 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Cristian Rodríguez from comment #0)
> Ideally, if the system call is not found in the running kernel, fallback to
> emulation by reading /dev/urandom in the default case or /dev/random if 
> GRND_RANDOM is used.

If GRND_NONBLOCK is not set and the buffer is proper, the system call cannot
fail.  It is impossible to achieve that with emulation.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-25986-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sat Aug 16 22:19:28 2014
Return-Path: <glibc-bugs-return-25986-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 11857 invoked by alias); 16 Aug 2014 22:19:28 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 11812 invoked by uid 48); 16 Aug 2014 22:19:23 -0000
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug nptl/13165] pthread_cond_wait() can consume a signal that was sent before it started waiting
Date: Sat, 16 Aug 2014 22:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: nptl
X-Bugzilla-Version: 2.14
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bugdal at aerifal dot cx
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: triegel at redhat dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-13165-131-2qZOKapRcv@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-13165-131@http.sourceware.org/bugzilla/>
References: <bug-13165-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-08/txt/msg00069.txt.bz2
Content-length: 879

https://sourceware.org/bugzilla/show_bug.cgi?id\x13165

--- Comment #38 from Rich Felker <bugdal at aerifal dot cx> ---
I just read the source for pthread_cond_wait and the cause of the bug is
obvious: the mutex is being unlocked before the current thread acquires the
internal lock in the cond var and adds itself as a waiter. Simply moving the
mutex unlock to somewhere after this point (e.g. right before the futex wait
loop) should fix the problem. This is necessary to meet the requirement that
formally becoming a waiter is atomic with unlocking of the mutex, rather than
happening at some time after unlocking the mutex with a race window in between.

If someone else could test this fix, I would appreciate it since I don't have
an environment setup for building and testing new glibc builds.

--
You are receiving this mail because:
You are on the CC list for the bug.