See https://bugzilla.kernel.org/show_bug.cgi?id=25292
And there will likely be future changes as well.
Quoting http://www.opengroup.org/austin/aardvark/latest/xshbug3.txt:
COMMENT Enhancement Request Number 15
rajani.g.k:xxxxxx Defect in XSH 2.4.3 (rdvk# 6)
{GKRFORK012009} Thu, 8 Jan 2009 07:41:10 GMT
[...]
As per this section, XSH P1529, L49389-49402, it is possible
that multithreaded libraries could be used by single threaded
applications. In which case, atfork handlers are essential for
the libraries to protect their internal state during fork. As
explained further P1530, L49403-49404, pthread_atfork
functions are mainly required to acquire/release mutex locks,
for protecting the applications/libraries from fork() calls.
C-library needs to as well have an atfork handler which
acquires all the required locks to protect its memory state
across fork().
The acquire/release mutex calls themselves are aync-signal
unsafe operations. Use of them makes pthread_atfork handlers
async-signal unsafe which in turn makes fork() async-signal
unsafe when called by an application which is multi threaded,
or which is linked to a library which is multi threaded.
Action:
Need clarification with respect to
1. Is it correct to list fork as an async-signal safe
interface, in a multi threaded scenario?
2. Can the implementation be allowed to not call the atfor
handlers, when fork is called from a signal handler? If the
atfork handlers are not going to be called when fork is called
in the signal handler, then they can not be called, even if
fork is called in the newly created child before exec.
3. If only async-signal safe functions are to be called from
pthread_atfork handlers, then how will multi-threaded librarie
protect themselves by the fork calls, made by single threaded
applications linked to them?
Reported-by: KASAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Also:
* add more detail on changes across standards
* provide proper section cross references in function references
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The FDs returned by NS_GET_USERNS and NS_GET_PAREENT must be
tested by comparing to both the 'st_dev' and 'st_ino' fields
returned by fstat(2).
Reported-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This section material in the user_namespaces(7) page was written
before the creation of the mount_namespaces(7) manual page.
Nowadays, this material properly belongs in the newer page.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[mtk] I did a little code spelunking and found the following:
1. In glibc 1.09 (tagged 1995-03-02 in the git history),
__USE_REENTRANT, _THREAD_SAFE, and _REENTRANT do not appear.
2. In glibc-1.93 (tagged 1996-08-29 in the git history),
__USE_REENTRANT governs the exposure of some "_r()"
functions from about a dozen header files. However, it is
defined in <features.h> via
#if defined (__USE_GNU) || defined (__USE_MISC)
#define __USE_REENTRANT 1
#endif
_REENTRANT and _THREAD_SAFE solely govern declarations in
<stdio.h>, where they expose declarations of a few "unlocked"
stdio functions and use #define to redirect a few stdio
function names to "locked" versions.
3. THREAD_SAFE and _REENTRANT first appear in the git logs
1996-05-09.
4. About 9 months later, glibc 2.0.1 arrives on 1997-02-04
(timestamp and tarball taken from
https://ftp.gnu.org/gnu/libc/, since there is no tag in the
git history; casual inspection of the logs suggests the
glibc 2.0 release was about a week earlier.
By now we have the following in <features.h>:
#if defined _REENTRANT || defined _THREAD_SAFE
#define __USE_REENTRANT 1
#endif
And _THREAD_SAFE, and _REENTRANT do not appear appear in
other headers. However, by now, __USE_REENTRANT governs only
the declarations of tmpnam_r() and getlogin_r()
In other words, the window of time where _REENTRANT and
_THREAD_SAFE did anything much in glibc was quite short, IIUC.
Cowritten-by: Zack Weinberg <zackw@panix.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Essentially to fix a formatting issue, where the list head
item wrapped past the 80-column limit when rendered.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Co-authored-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Remove the text saying that setting the autogroup nice value
always lowers the group's priority. That was actually a
bug introduced in Linux 4.7.
Also make it clearer that the autogroup nice value has the same
meaning as the nice value set by setpriority(2).
Reported-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It's not the norm to name developers of particular features
in each man page. No need for an exception here.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
From the email discussion:
> > Usage recommendations
> > The kernel random-number generator relies on entropy gathered
> > from device drivers and other sources of environmental noise.
> > It is designed to produce a small amount of high-quality seed
> > material to seed a cryptographically secure pseudorandom number
> > generator (CSPRNG). It is designed for security, not speed,
> > and is poorly suited to generating large amounts of crypto‐
> > graphic random data. Users should be economical in the amount
> > of seed material that they consume via getrandom(2), /dev/uran‐
> > dom, and /dev/random.
> >
> > ┌─────────────────────────────────────────────────────┐
> > │FIXME │
> > ├─────────────────────────────────────────────────────┤
> > │Is it really necessary to avoid consuming large │
> > │amounts from /dev/urandom? Various sources linked to │
> > │by https://bugzilla.kernel.org/show_bug.cgi?id=71211 │
> > │suggest it is not. │
> > │ │
> > │And: has the answer to the previous question changed │
> > │across kernel versions? │
> > └─────────────────────────────────────────────────────┘
> > Consuming unnecessarily large quantities of data via these
> > interfaces will have a negative impact on other consumers of
> > randomness.
[Ted T'so:]
> So "poorly suited" is definitely true. Also true is that urandom is
> not engineered for use for non-cryptographic uses. It's always going
> to be faster to use random(3) for those purposes.
>
> As far as whether or not it has a negative impact, it depends on how
> much you trust the underlying cryptographic algorithms. If the CSPRNG
> is seeded correctly with at least 256 bits of entropy that can't be
> guessed by the attacker, and if the underlying cryptographic
> primitives are secure, then it won't matter. But *if* there is an
> unknown vulnerability in the underlying primitive, and *if* large
> amounts of data generated by the CSPRNG would help exploit that
> vulnerability, and *if* that bulk amount of CSPRNG output is made
> available to an attacker with the capability to break the underlying
> cryptographic vulnerability, then there would be a problem.
>
> Obviously, no one knows of such a vulnerability, and I'm fairly
> confident that there won't be such a vulnerability across the
> different ways we've used to generate the urandom source --- but some
> people are professional paranoids, and would argue that we shouldn't
> make bulk output of the CSPRNG available for no good reason, just in
> case.
[Nikos Mavrogiannopoulos:]
The above is certainly accurate, however, I think that such a
discussion or text, when reflected to a man-page is going to
cause problems. The audience of a man-page are not crypto people,
and seeing such text would create confusion rather than clarify
how these devices/apis should be used. The *if* part is not put
into a perspective, suggesting that such an *if* is possible.
However, if one clarifies, i.e., in that case, your TLS or SSH
connection is most likely broken as well, and not because of any
attack on /dev/urandom, then one can see that we are heading
towards a theoretical discussion.
My suggestion, on that particular text would be to remove it,
but make it explicit somewhere in the text that all the
assurances for the devices depend on the crypto primitives,
rather than describing risks that may arise on particular
usage patterns *if* primitives are broken.
Reviewed-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
Reported-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add a lot more detail on /proc/sys/fs/pipe-max-size and
/proc/sys/fs/pipe-user-pages-{soft,hard}.
Reviewed-by: Willy Tarreau <w@1wt.eu>
Reviewed-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk