Dave Martin [Tue, 9 Jun 2020 11:30:57 +0000 (13:30 +0200)]
prctl.2: Add PR_PAC_RESET_KEYS (arm64)
Add documentation for the PR_PAC_RESET_KEYS ioctl added in Linux
5.0 for arm64.
Signed-off-by: Dave Martin <Dave.Martin@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Amit Daniel Kachhap <amit.kachhap@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
I've traced this to SELinux policy denying the connection. This is
on a Fedora 23 VM:
$ cat /etc/redhat-release
Fedora release 23 (Twenty Three)
$ uname -a
Linux mako-fedora-01 4.8.13-100.fc23.x86_64 #1 SMP Fri Dec 9 14:51:40
UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
The manpage says this can happen when connecting to a broadcast
address, or when a local firewall rule blocks the connection.
However, the address above is unicast, and using 'wget' from
another account to access the URL works fine.
The context is that we're building an OS image, and this involves
downloading RPMs through a proxy. The proxy (polipo) is labelled
by SELinux, and I guess there is some sort of policy that says
"proxy can only connect to HTTP ports". When trying to connect to
a server listening on a port that is not labeled as an HTTP server
port, I guess SELinux steps in. With 'setenforce 0', the build
works fine. In the kernel sources I see connect() calls
security_socket_connect() (see
https://elixir.bootlin.com/linux/latest/source/net/socket.c#L1855),
which calls whatever security hooks are registered. I see the
SELinux hook getting registered at
https://elixir.bootlin.com/linux/latest/source/security/selinux/hooks.c#L7047,
and setting a perf probe on the call proves that the
selinux_socket_connect function gets called (while
tcp_v4_connect() is not).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Tue, 9 Jun 2020 08:03:04 +0000 (10:03 +0200)]
user_namespaces.7: Clarify "system time"
From an email conversation with Léo Stefanesco:
> In the man7.org version of the man page for user_namespaces(7), it reads:
>
> there are many privileged operations that affect
> resources that are not associated with any namespace type,
> for example, changing the system time
> (governed by CAP_SYS_TIME)
>
> which is not consistent with time_namespaces(7).
In fact, strictly peaking the text still is correct, even after
the arrival of time namespaces.
Time namespaces virtualize only the boot-time and monotonic
clocks, not the "real time" (i.e., calendar time), which is the
time referred in the passage you quote.
That said, the text is perhaps now a little misleading, and
a little clarification would help. I changed the text to:
there are many privileged operations that affect
resources are not associated with any namespace type,
for example, changing the system **(i.e., calendar)** time
(governed by CAP_SYS_TIME)
Reported-by: Léo Stefanesco <leo.lveb@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Thu, 16 Apr 2020 06:28:05 +0000 (08:28 +0200)]
ioctl_list.2: Remove this page
This page was first added more than 20 years ago. Since
that time it has seen hardly any update, and is by now
very much out of date, as reported by Heinrich Schuchardt
and confirmed by Eugene Syromyatnikov.
As Heinrich says:
Man-pages like netdevices.7 or ioctl_fat.2 are what is
needed to help a user who does not want to read through the
kernel code.
If ioctl_list.2 has not been reasonably maintained since
Linux 1.3.27 and hence is not a reliable source of
information, shouldn't it be dropped?
My answer is, yes (but let's move a little info into ioctl(2)).
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reported-by: Eugene Syromyatnikov <evgsyr@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
John Marshall [Mon, 8 Jun 2020 11:04:16 +0000 (12:04 +0100)]
random.3: Change "RAND_MAX" tp "2^31-1"
RAND_MAX is for rand(3). POSIX fixes random()'s range at 2^31-1;
RAND_MAX may be smaller on some platforms (even though with glibc
or musl on Linux they are the same).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Amir Goldstein [Fri, 29 May 2020 09:25:30 +0000 (12:25 +0300)]
fanotify.7, fanotify_mark.2: Clarify FAN_ONDIR in output mask
FAN_ONDIR was an input only flag before introducing
FAN_REPORT_FID. Since the introduction of FAN_REPORT_FID, it can
also be in output mask.
Move the text describing its role in the output mask to fanotify.7
where the other output mask bits are documented.
[mtk: commit message tidy-up]
Reviewed-by: Matthew Bobrowski <mbobrowski@mbobrowski.org> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Amir Goldstein [Fri, 29 May 2020 09:25:29 +0000 (12:25 +0300)]
fanotify_init.2: Move out of place entry FAN_REPORT_FID
It was inserted in the middle of the FAN_CLASS_ multi flags bit
and broke the multi flag documentation.
Reviewed-by: Matthew Bobrowski <mbobrowski@mbobrowski.org> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
FAN_DIR_MODIFY was disabled for v5.7 release by kernel commit f17936993af0 ("fanotify: turn off support for FAN_DIR_MODIFY").
Reviewed-by: Matthew Bobrowski <mbobrowski@mbobrowski.org> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In the few pages where this heading (which is "nonstandard" within
man-pages) is used, it always immediately follows CONFORMING TO
and generally contains information related to standards. Remove
the section heading, thus incorporating AVAILABILITY into
CONFORMING TO.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Thu, 21 May 2020 06:15:46 +0000 (08:15 +0200)]
man-pages.7: Add REPORTING BUGS section
man-pages doesn't have a REPORTING BUGS section in manual pages,
but many other projects do. Make some recommendations about
placement of that section.
Michael Kerrisk [Thu, 21 May 2020 06:00:48 +0000 (08:00 +0200)]
man-pages.7: Mention AUTHORS in summary section list
Although man-pages doesn't use AUTHORS sections, many projects do
use an AUTHORS section in their manual pages, so mention it in
man-pages to suggest some guidance on the position at which
to place that section.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Dave Martin [Tue, 12 May 2020 16:36:56 +0000 (17:36 +0100)]
prctl.2: Add PR_SPEC_DISABLE_NOEXEC for SPECULATION_CTRL prctls
Add the PR_SPEC_DISABLE_NOEXEC mode added in Linux 5.1
for the PR_SPEC_STORE_BYPASS "misfeature" of
PR_SET_SPECULATION_CTRL and PR_GET_SPECULATION_CTRL.
Signed-off-by: Dave Martin <Dave.Martin@arm.com> Cc: Waiman Long <longman@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Dave Martin [Tue, 12 May 2020 16:36:55 +0000 (17:36 +0100)]
prctl.2: Add PR_SPEC_INDIRECT_BRANCH for SPECULATION_CTRL prctls
Add the PR_SPEC_INDIRECT_BRANCH "misfeature" added in Linux 4.20
for PR_SET_SPECULATION_CTRL and PR_GET_SPECULATION_CTRL.
Signed-off-by: Dave Martin <Dave.Martin@arm.com> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Tue, 26 May 2020 10:10:55 +0000 (12:10 +0200)]
y0.3: srcfix: Note on "Range error: result underflow" and FE_UNDERFLOW
The fact that an FE_UNDERFLOW exception is not raised for
"Range error: result underflow" is intended behavior.
See https://www.sourceware.org/bugzilla/show_bug.cgi?id=6806.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
printf.3: Prevent signed integer overflow in example
The function make_message illustrates how to use vsnprintf to
determine the required amount of memory for a specific format and
its arguments.
If make_message is called with a format which will use exactly
INT_MAX characters (excluding '\0'), then the size++ calculation
will overflow the signed integer "size", which is an undefined
behaviour in C.
Since malloc and vsnprintf rightfully take a size_t argument, I
decided to use a size_t variable for size calculation. Therefore,
this patched code uses variables of the same data types as
expected by function arguments.
Proof of concept (tested on Linux/glibc amd64):
int main() { make_message("%647s%2147483000s", "", ""); }
If the code is compiled with address sanitizer (gcc
-fsanitize=address) you can see the following line, assuming that
a signed integer overflow simply leads to INT_MIN:
==3094==WARNING: AddressSanitizer failed to allocate 0xffffffff80000000 bytes
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Mon, 25 May 2020 13:15:14 +0000 (15:15 +0200)]
pow.3: Minor tweak to BUGS
Remove the text ("rare)" after a note from Vincent Lefèvre:
Subject: [Bug math/13932] dbl-64 pow unexpectedly slow for some inputs
Date: Sat, 23 May 2020 21:31:52 +0000
From: vincent-srcware at vinc17 dot net <sourceware-bugzilla@sourceware.org>
To: mtk.manpages@gmail.com
--- Comment #26 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> ---
(In reply to Michael Kerrisk from comment #25)
> Fix documented for man-pages-5.07.
[...]
> -On 64-bits,
> +Before glibc 2.28,
> .\"
> .\" https://sourceware.org/bugzilla/show_bug.cgi?id=13932
> +on some architectures (e.g., x86-64)
> .BR pow ()
> may be more than 10,000 times slower for some (rare) inputs
> than for other nearby inputs.
[...]
The problematic values are uncommon, but not so rare, in the sense
that they are close to simple values, i.e. are likely to occur in
practice. An example given above: pow(0.999999999999999889, 1.5)
1 and 1.5 are very simple values, which are more likely to occur
in practice than some fixed random value. Then it suffices to have
a small rounding error on 1...
For instance, this is very different from hard-to-round cases of
exp, which are also very slow IMHO, but unless one writes a
specific program for them, no-one should notice the slowness
because such a case would typically occur only once among billions
(I don't remember the accuracy before the slowest path in this
library).
Reported-by: Vincent Lefèvre <vincent-srcware@vinc17.net> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Wed, 20 May 2020 12:45:23 +0000 (14:45 +0200)]
standards.7: Remove mention of bogus "POSIX" names
The terms POSIX.1-{2003,2004,2013,2016} were inventions of
my imagination, as confirmed by consulting Geoff Clare of
The Open Group. Remove these names.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Avoid implying that use of IFUNC is the only way to produce a
symbol with NULL value. Give more scenarios how a symbol may get
NULL value, but explain that in those scenarios dlsym() will fail
with Glibc's ld.so due to an implementation inconsistency.
Signed-off-by: Alexander Monakov <amonakov@ispras.ru> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Devin J. Pohly [Mon, 18 May 2020 20:58:28 +0000 (15:58 -0500)]
veth.4: Add a more direct example
iproute2 allows you to specify the netns for either side of a veth
interface at creation time. Add an example of this to veth(4) so
it doesn't sound like you have to move the interfaces in a
separate step.
Verified with commands:
# ip netns add alpha
# ip netns add bravo
# ip link add foo netns alpha type veth peer bar netns bravo
# ip -n alpha link show
# ip -n bravo link show
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
projects / thirdparty / man-pages.git / log
