Mike Frysinger [Sun, 27 Nov 2016 03:31:37 +0000 (22:31 -0500)]
elf(5): document notes
Document the Elf{32,64}_Nhdr structure, the sections/segments that
contain notes, and how to interpret them. I've been lazy and only
included the GNU extensions here, especially as others are not
defined in the elf.h header file as shipped by glibc.
I've mostly used binutils, glibc, breakpad, and the GABI ELF spec
as sources of data for these fields.
Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Sun, 20 Nov 2016 09:03:52 +0000 (10:03 +0100)]
random.7: Remove recommendation against consuming large amounts of randomness
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.
Darrick J. Wong [Wed, 23 Nov 2016 04:48:16 +0000 (20:48 -0800)]
fideduperange.2: Fix the discussion of maximum sizes
Fix the discussion of the limitations on the dest_count and
src_length parameters to the fideduperange ioctl() to reflect
what's actually in the kernel.
Reviewed-by: Omar Sandoval <osandov@fb.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Mike Frysinger [Thu, 17 Nov 2016 14:34:27 +0000 (09:34 -0500)]
elf(5): Add subsection headers at major points
The current pages dumps all the content into one big DESCRIPTION
with no real visual break up between logically independent
sections. Add some subsection headers to make it easier to
read and scan.
In Linux 4.8 (through a series of commits, 93e35efb8de45393c
being the actual reordering on x86), the order of
PTRACE_EVENT_SECCOMP and syscall-entry-stops was reversed.
Document both behaviors and their interaction with the
various forms of restart.
Michael Kerrisk [Fri, 11 Nov 2016 10:15:27 +0000 (11:15 +0100)]
getrandom.2: Clarify that getrandom() is not "reading" from /dev/{random,urandom}
The existing text is a little confusing, since it somewhat
suggests that getrandom() "reads" from the /dev/random and
/dev/urandom devices. Rather, it is drawing from the same
pools as those devices. Reword the text to clarify that.
Plus a few other wording improvements.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Thu, 10 Nov 2016 14:10:04 +0000 (15:10 +0100)]
getrandom.2, random.4: Consolidate and improve discussion on usage of randomness
Currently, recommendations on how to consume randomness are
spread across both getrandom(2) and random(4) and the general
opinion seems to be that the text in getrandom(2) does a
somewhat better job. Consolidate the discussion to a single
page (getrandom(2)) and address some of the concerns
expressed about the existing text in random(4).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Thu, 10 Nov 2016 13:37:33 +0000 (14:37 +0100)]
random.4: Improve discussion of /dev/urandom, blocking reads, and signals
The text currently states that O_NONBLOCK has no effect for
/dev/urandom, which is true. It also says that reads from
/dev/urandom are nonblocking. This is at the least confusing.
If one attempts large reads (say 10MB) from /dev/urandom
there is an appreciable delay, and interruption by a signal
handler will result in a short read. Amend the text to
reflect this.
projects / thirdparty / man-pages.git / log
