* Re: [PATCH 1/2] posixoptions.7: Expand XSI Options groups.
From: Michael Kerrisk (man-pages) @ 2018-04-14 5:37 UTC (permalink / raw)
To: Rical Jasan
Cc: Carlos O'Donell, linux-man@vger.kernel.org, Florian Weimer,
GNU C Library, Zack Weinberg
In-Reply-To: <4d8d0ca1-a612-b3bf-563c-49d0d61856ed@2c3t.io>
On 14 April 2018 at 06:43, Rical Jasan <rj@2c3t.io> wrote:
> On 04/12/2018 12:05 PM, Carlos O'Donell wrote:
>> +.B _POSIX_TRACE_INHERIT
>> +options and defined to 200112L.
>
> "are defined"?
>
>> +The option may imply the
>> +.B Encryption (_XOPEN_CRYPT),
>> +.B Realtime (_XOPEN_REALTIME),
>> +.B Advanced Raltime (ADB),
>
> "Realtime"
Yup. Both already found and fixed.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* Re: [PATCH 1/2] posixoptions.7: Expand XSI Options groups.
From: Rical Jasan @ 2018-04-14 4:43 UTC (permalink / raw)
To: Carlos O'Donell, linux-man@vger.kernel.org, Michael Kerrisk
Cc: Florian Weimer, GNU C Library, Zack Weinberg
In-Reply-To: <2d6c47e9-0f34-c828-916e-a45fbf90f837@redhat.com>
On 04/12/2018 12:05 PM, Carlos O'Donell wrote:
> +.B _POSIX_TRACE_INHERIT
> +options and defined to 200112L.
"are defined"?
> +The option may imply the
> +.B Encryption (_XOPEN_CRYPT),
> +.B Realtime (_XOPEN_REALTIME),
> +.B Advanced Raltime (ADB),
"Realtime"
Rical
^ permalink raw reply
* Re: [PATCH 2/2] crypt.3, encrypt.3: Add notes about _XOPEN_CRYPT.
From: Rical Jasan @ 2018-04-14 4:43 UTC (permalink / raw)
To: Carlos O'Donell, linux-man@vger.kernel.org, Michael Kerrisk
Cc: Florian Weimer, Zack Weinberg, GNU C Library
In-Reply-To: <6d9a7e45-5d31-efbd-78ad-2808d492eb21@redhat.com>
On 04/12/2018 12:05 PM, Carlos O'Donell wrote:
> diff --git a/man3/crypt.3 b/man3/crypt.3
> index 3e6552ad8..58c62d93d 100644
> --- a/man3/crypt.3
> +++ b/man3/crypt.3
> @@ -188,8 +188,26 @@ POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD.
> .BR crypt_r ()
> is a GNU extension.
> .SH NOTES
> -.SS Glibc notes
> -The glibc2 version of this function supports additional
> +.SS Availability in glibc
> +The
> +.BR crypt (),
> +.BR encrypt (),
> +and
> +.BR setkey ()
> +functions are part of the POSIX.1-2008 XSI Options Group for Encryption
> +and are optional. If the interfaces are not available then the symbolic
> +constant
> +.BR _XOPEN_CRYPT
> +is either not defined or defined to -1, and can be checked at runtime with
> +.BR sysconf ().
> +This may be the case if the downstream distribution has switched from glibc
> +crypt to libxcrypt. When recompiling applications in such distributions the
> +user must detect if
> +.BR _XOPEN_CRPYT
"CRYPT"
(Looks like this was caught already.)
> +is not available and include crypt.h for the function prototypes; otherwise
> +libxcrypt is a ABI compatible drop-in replacement.
"an ABI"
I would also hyphenate "ABI-compatible".
(The same issues were also in encrypt.3 but it sounds like the content
was deduplicated already.)
Rical
^ permalink raw reply
* Re: [PATCH 24/24] debugfs: Restrict debugfs when the kernel is locked down
From: Pavel Machek @ 2018-04-13 20:22 UTC (permalink / raw)
To: David Howells
Cc: torvalds, linux-man, linux-api, jmorris, linux-kernel,
linux-security-module
In-Reply-To: <152346403637.4030.15247096217928429102.stgit@warthog.procyon.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]
On Wed 2018-04-11 17:27:16, David Howells wrote:
> Disallow opening of debugfs files that might be used to muck around when
> the kernel is locked down as various drivers give raw access to hardware
> through debugfs. Given the effort of auditing all 2000 or so files and
> manually fixing each one as necessary, I've chosen to apply a heuristic
> instead. The following changes are made:
>
> (1) chmod and chown are disallowed on debugfs objects (though the root dir
> can be modified by mount and remount, but I'm not worried about that).
This has nothing to do with the lockdown goals, right? I find chown of
such files quite nice, to allow debugging without doing sudo all the time.
> (2) When the kernel is locked down, only files with the following criteria
> are permitted to be opened:
>
> - The file must have mode 00444
> - The file must not have ioctl methods
> - The file must not have mmap
Dunno. Would not it be nicer to go through the debugfs files and split
them into safe/unsafe varieties?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 07/24] hibernate: Disable when the kernel is locked down
From: Pavel Machek @ 2018-04-13 20:22 UTC (permalink / raw)
To: David Howells
Cc: torvalds, linux-man, linux-api, jmorris, linux-kernel,
linux-security-module
In-Reply-To: <152346392521.4030.5108539377959227838.stgit@warthog.procyon.org.uk>
[-- Attachment #1: Type: text/plain, Size: 624 bytes --]
On Wed 2018-04-11 17:25:25, David Howells wrote:
> From: Josh Boyer <jwboyer@fedoraproject.org>
>
> There is currently no way to verify the resume image when returning
> from hibernate. This might compromise the signed modules trust model,
> so until we can work with signed hibernate images we disable it when the
> kernel is locked down.
I'd rather see hibernation fixed than disabled like this.
I believe Jiri Kosina may have some patches for that?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 02/24] Add a SysRq option to lift kernel lockdown
From: Pavel Machek @ 2018-04-13 20:22 UTC (permalink / raw)
To: David Howells
Cc: torvalds, linux-man, linux-api, jmorris, linux-kernel,
linux-security-module
In-Reply-To: <152346389240.4030.11187964053014260180.stgit@warthog.procyon.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]
On Wed 2018-04-11 17:24:52, David Howells wrote:
> From: Kyle McMartin <kyle@redhat.com>
>
> Make an option to provide a sysrq key that will lift the kernel lockdown,
> thereby allowing the running kernel image to be accessed and modified.
>
> On x86 this is triggered with SysRq+x, but this key may not be available on
> all arches, so it is set by setting LOCKDOWN_LIFT_KEY in asm/setup.h.
> Since this macro must be defined in an arch to be able to use this facility
> for that arch, the Kconfig option is restricted to arches that support it.
>
> Signed-off-by: Kyle McMartin <kyle@redhat.com>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: x86@kernel.org
Is that good idea? Magic sysrq was meant for debugging, not for
toggling options like that. Distros are expected to turn it off.
It also works over serial consoles etc, being able to toggle security
options from serial is surprising...
> --- a/drivers/tty/sysrq.c
> +++ b/drivers/tty/sysrq.c
> @@ -487,6 +487,7 @@ static struct sysrq_key_op *sysrq_key_table[36] = {
> /* x: May be registered on mips for TLB dump */
> /* x: May be registered on ppc/powerpc for xmon */
> /* x: May be registered on sparc64 for global PMU dump */
> + /* x: May be registered on x86_64 for disabling secure boot */
> NULL, /* x */
What about x86-32?
> +static struct sysrq_key_op lockdown_lift_sysrq_op = {
> + .handler = sysrq_handle_lockdown_lift,
> + .help_msg = "unSB(x)",
> + .action_msg = "Disabling Secure Boot restrictions",
> + .enable_mask = SYSRQ_DISABLE_USERSPACE,
> +};
I'd remove secure boot mentions here.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] crypt.3, encrypt.3: Add notes about _XOPEN_CRYPT.
From: Michael Kerrisk (man-pages) @ 2018-04-13 19:24 UTC (permalink / raw)
To: Carlos O'Donell, linux-man@vger.kernel.org
Cc: mtk.manpages, Florian Weimer, Zack Weinberg, Rical Jasan,
GNU C Library, Nikos Mavrogiannopoulos
In-Reply-To: <baa666d2-b369-c472-2bde-c3b94312341a@redhat.com>
On 04/13/2018 05:10 PM, Carlos O'Donell wrote:
> On 04/12/2018 02:05 PM, Carlos O'Donell wrote:
>> +.BR _XOPEN_CRPYT
>
> s/CRPYT/CRYPT/g
>
> Which I missed in the spell checker due to my overzealous use of ignore.
>
> Caught by Nikos Mavrogiannopoulos <nmavrogi@redhat.com> during review.
Thanks. Fixed!
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* Re: [RFC bpf-next v2 4/8] bpf: add documentation for eBPF helpers (23-32)
From: Quentin Monnet @ 2018-04-13 18:18 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: daniel, ast, netdev, oss-drivers, linux-doc, linux-man
In-Reply-To: <20180413002838.atu7shp5cuubx32p@ast-mbp.dhcp.thefacebook.com>
2018-04-12 17:28 UTC-0700 ~ Alexei Starovoitov
<alexei.starovoitov@gmail.com>
> On Tue, Apr 10, 2018 at 03:41:53PM +0100, Quentin Monnet wrote:
>> Add documentation for eBPF helper functions to bpf.h user header file.
>> This documentation can be parsed with the Python script provided in
>> another commit of the patch series, in order to provide a RST document
>> that can later be converted into a man page.
>>
>> The objective is to make the documentation easily understandable and
>> accessible to all eBPF developers, including beginners.
>>
>> This patch contains descriptions for the following helper functions, all
>> written by Daniel:
>>
>> - bpf_get_prandom_u32()
>> - bpf_get_smp_processor_id()
>> - bpf_get_cgroup_classid()
>> - bpf_get_route_realm()
>> - bpf_skb_load_bytes()
>> - bpf_csum_diff()
>> - bpf_skb_get_tunnel_opt()
>> - bpf_skb_set_tunnel_opt()
>> - bpf_skb_change_proto()
>> - bpf_skb_change_type()
>>
>> Cc: Daniel Borkmann <daniel@iogearbox.net>
>> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
>> ---
>> include/uapi/linux/bpf.h | 125 +++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 125 insertions(+)
>>
>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>> index f3ea8824efbc..d147d9dd6a83 100644
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
[...]
>> @@ -604,6 +612,13 @@ union bpf_attr {
>> * Return
>> * 0 on success, or a negative error in case of failure.
>> *
>> + * u32 bpf_get_cgroup_classid(struct sk_buff *skb)
>> + * Description
>> + * Retrieve the classid for the current task, i.e. for the
>> + * net_cls (network classifier) cgroup to which *skb* belongs.
>
> please add that kernel should be configured with CONFIG_NET_CLS_CGROUP=y|m
> and mention Documentation/cgroup-v1/net_cls.txt
Ok.
> Otherwise 'network classifier' is way too generic.
I am not so familiar with cgroups. What would you suggest instead?
> I'd also mention that placing a task into net_cls controller
> disables all of cgroup-bpf.
Could you please explain a bit more? Placing a task into the controller
is using:
echo <task_pid> > /sys/fs/cgroup/<my_cgroup_name>/tasks
correct? Then if I do this, it disables all of cgroup-bpf. Does this
mean that I loose the possibility to use or add BPF programs to all
cgroup-related attach points for this cgroup? I think I missed something
here.
>> + * Return
>> + * The classid, or 0 for the default unconfigured classid.
>> + *
>> * int bpf_skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci)
>> * Description
>> * Push a *vlan_tci* (VLAN tag control information) of protocol
I have no particular comments on the other items you reported on this
patch, I will fix them. Thanks!
Quentin
^ permalink raw reply
* Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved
From: Jann Horn @ 2018-04-13 16:17 UTC (permalink / raw)
To: Michal Hocko
Cc: Michael Kerrisk (man-pages), John Hubbard, linux-man,
Andrew Morton, Linux-MM, lkml, Linux API
In-Reply-To: <CAG48ez3-xtmAt2EpRFR8GNKKPcsDsyg7XdwQ=D5w3Ym6w4Krjw@mail.gmail.com>
On Fri, Apr 13, 2018 at 6:05 PM, Jann Horn <jannh@google.com> wrote:
> On Fri, Apr 13, 2018 at 6:04 PM, Michal Hocko <mhocko@kernel.org> wrote:
>> On Fri 13-04-18 17:04:09, Jann Horn wrote:
>>> On Fri, Apr 13, 2018 at 8:49 AM, Michal Hocko <mhocko@kernel.org> wrote:
>>> > On Fri 13-04-18 08:43:27, Michael Kerrisk wrote:
>>> > [...]
>>> >> So, you mean remove this entire paragraph:
>>> >>
>>> >> For cases in which the specified memory region has not been
>>> >> reserved using an existing mapping, newer kernels (Linux
>>> >> 4.17 and later) provide an option MAP_FIXED_NOREPLACE that
>>> >> should be used instead; older kernels require the caller to
>>> >> use addr as a hint (without MAP_FIXED) and take appropriate
>>> >> action if the kernel places the new mapping at a different
>>> >> address.
>>> >>
>>> >> It seems like some version of the first half of the paragraph is worth
>>> >> keeping, though, so as to point the reader in the direction of a remedy.
>>> >> How about replacing that text with the following:
>>> >>
>>> >> Since Linux 4.17, the MAP_FIXED_NOREPLACE flag can be used
>>> >> in a multithreaded program to avoid the hazard described
>>> >> above.
>>> >
>>> > Yes, that sounds reasonable to me.
>>>
>>> But that kind of sounds as if you can't avoid it before Linux 4.17,
>>> when actually, you just have to call mmap() with the address as hint,
>>> and if mmap() returns a different address, munmap() it and go on your
>>> normal error path.
>>
>> This is still racy in multithreaded application which is the main point
>> of the whole section, no?
>
> No, it isn't.
mmap() with a hint (without MAP_FIXED) will always non-racily allocate
a memory region for you or return an error code. If it does allocate a
memory region, it belongs to you until you deallocate it. It might be
at a different address than you requested - in that case you can
emulate MAP_FIXED_NOREPLACE by calling munmap() and treating it as an
error; or you can do something else with it.
MAP_FIXED_NOREPLACE is just a performance optimization.
^ permalink raw reply
* Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved
From: Jann Horn @ 2018-04-13 16:05 UTC (permalink / raw)
To: Michal Hocko
Cc: Michael Kerrisk (man-pages), John Hubbard, linux-man,
Andrew Morton, Linux-MM, lkml, Linux API
In-Reply-To: <20180413160435.GA17484@dhcp22.suse.cz>
On Fri, Apr 13, 2018 at 6:04 PM, Michal Hocko <mhocko@kernel.org> wrote:
> On Fri 13-04-18 17:04:09, Jann Horn wrote:
>> On Fri, Apr 13, 2018 at 8:49 AM, Michal Hocko <mhocko@kernel.org> wrote:
>> > On Fri 13-04-18 08:43:27, Michael Kerrisk wrote:
>> > [...]
>> >> So, you mean remove this entire paragraph:
>> >>
>> >> For cases in which the specified memory region has not been
>> >> reserved using an existing mapping, newer kernels (Linux
>> >> 4.17 and later) provide an option MAP_FIXED_NOREPLACE that
>> >> should be used instead; older kernels require the caller to
>> >> use addr as a hint (without MAP_FIXED) and take appropriate
>> >> action if the kernel places the new mapping at a different
>> >> address.
>> >>
>> >> It seems like some version of the first half of the paragraph is worth
>> >> keeping, though, so as to point the reader in the direction of a remedy.
>> >> How about replacing that text with the following:
>> >>
>> >> Since Linux 4.17, the MAP_FIXED_NOREPLACE flag can be used
>> >> in a multithreaded program to avoid the hazard described
>> >> above.
>> >
>> > Yes, that sounds reasonable to me.
>>
>> But that kind of sounds as if you can't avoid it before Linux 4.17,
>> when actually, you just have to call mmap() with the address as hint,
>> and if mmap() returns a different address, munmap() it and go on your
>> normal error path.
>
> This is still racy in multithreaded application which is the main point
> of the whole section, no?
No, it isn't.
^ permalink raw reply
* Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved
From: Michal Hocko @ 2018-04-13 16:04 UTC (permalink / raw)
To: Jann Horn
Cc: Michael Kerrisk (man-pages), John Hubbard, linux-man,
Andrew Morton, Linux-MM, lkml, Linux API
In-Reply-To: <CAG48ez2w+3FDh9LM3+P2EHowicjM2Xw6giR6uq=26JfWHYsTAQ@mail.gmail.com>
On Fri 13-04-18 17:04:09, Jann Horn wrote:
> On Fri, Apr 13, 2018 at 8:49 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > On Fri 13-04-18 08:43:27, Michael Kerrisk wrote:
> > [...]
> >> So, you mean remove this entire paragraph:
> >>
> >> For cases in which the specified memory region has not been
> >> reserved using an existing mapping, newer kernels (Linux
> >> 4.17 and later) provide an option MAP_FIXED_NOREPLACE that
> >> should be used instead; older kernels require the caller to
> >> use addr as a hint (without MAP_FIXED) and take appropriate
> >> action if the kernel places the new mapping at a different
> >> address.
> >>
> >> It seems like some version of the first half of the paragraph is worth
> >> keeping, though, so as to point the reader in the direction of a remedy.
> >> How about replacing that text with the following:
> >>
> >> Since Linux 4.17, the MAP_FIXED_NOREPLACE flag can be used
> >> in a multithreaded program to avoid the hazard described
> >> above.
> >
> > Yes, that sounds reasonable to me.
>
> But that kind of sounds as if you can't avoid it before Linux 4.17,
> when actually, you just have to call mmap() with the address as hint,
> and if mmap() returns a different address, munmap() it and go on your
> normal error path.
This is still racy in multithreaded application which is the main point
of the whole section, no?
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH 2/2] crypt.3, encrypt.3: Add notes about _XOPEN_CRYPT.
From: Carlos O'Donell @ 2018-04-13 15:10 UTC (permalink / raw)
To: linux-man@vger.kernel.org, Michael Kerrisk
Cc: Florian Weimer, Zack Weinberg, Rical Jasan, GNU C Library
In-Reply-To: <6d9a7e45-5d31-efbd-78ad-2808d492eb21@redhat.com>
On 04/12/2018 02:05 PM, Carlos O'Donell wrote:
> +.BR _XOPEN_CRPYT
s/CRPYT/CRYPT/g
Which I missed in the spell checker due to my overzealous use of ignore.
Caught by Nikos Mavrogiannopoulos <nmavrogi@redhat.com> during review.
> +is not available and include crypt.h for the function prototypes; otherwise
> +libxcrypt is a ABI compatible drop-in replacement.
--
Cheers,
Carlos.
^ permalink raw reply
* Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved
From: Jann Horn @ 2018-04-13 15:04 UTC (permalink / raw)
To: Michal Hocko
Cc: Michael Kerrisk (man-pages), John Hubbard, linux-man,
Andrew Morton, Linux-MM, lkml, Linux API
In-Reply-To: <20180413064917.GC17484@dhcp22.suse.cz>
On Fri, Apr 13, 2018 at 8:49 AM, Michal Hocko <mhocko@kernel.org> wrote:
> On Fri 13-04-18 08:43:27, Michael Kerrisk wrote:
> [...]
>> So, you mean remove this entire paragraph:
>>
>> For cases in which the specified memory region has not been
>> reserved using an existing mapping, newer kernels (Linux
>> 4.17 and later) provide an option MAP_FIXED_NOREPLACE that
>> should be used instead; older kernels require the caller to
>> use addr as a hint (without MAP_FIXED) and take appropriate
>> action if the kernel places the new mapping at a different
>> address.
>>
>> It seems like some version of the first half of the paragraph is worth
>> keeping, though, so as to point the reader in the direction of a remedy.
>> How about replacing that text with the following:
>>
>> Since Linux 4.17, the MAP_FIXED_NOREPLACE flag can be used
>> in a multithreaded program to avoid the hazard described
>> above.
>
> Yes, that sounds reasonable to me.
But that kind of sounds as if you can't avoid it before Linux 4.17,
when actually, you just have to call mmap() with the address as hint,
and if mmap() returns a different address, munmap() it and go on your
normal error path.
^ permalink raw reply
* Re: [PATCH 2/2] crypt.3, encrypt.3: Add notes about _XOPEN_CRYPT.
From: Carlos O'Donell @ 2018-04-13 13:22 UTC (permalink / raw)
To: Michael Kerrisk (man-pages), linux-man@vger.kernel.org
Cc: Florian Weimer, Zack Weinberg, Rical Jasan, GNU C Library
In-Reply-To: <adb4d22e-f0b9-584d-5a61-c4290038b03b@gmail.com>
On 04/13/2018 04:34 AM, Michael Kerrisk (man-pages) wrote:
> On 04/12/2018 09:05 PM, Carlos O'Donell wrote:
>> The distribution may choose not to support _XOPEN_CRYPT in the
>> case that the distribution has transitioned from glibc crypt to
>> libxcrypt.
>>
>> Signed-off-by: Carlos O'Donell <carlos@redhat.com>
>
> Thanks, Carlos. I applied the patch, but rather than having the
> exact same text in both pages, I simply added a cross reference
> in encrypt(3).
That makes sense. I thought about exactly the same thing, but
decided that I'd let you use your liberty as editor to make that
decision upon review.
Thanks for applying the fixes.
Consider my fixes to posixoptions.7 as penance for complicating
encrypt.3. We have users going through that transition now for
us in Fedora (libcrypt -> libxcrypt), and we wanted to provide
some kind of note about the APIs moving. The changes are not
yet in upstream glibc, but may eventually go there, at which
point the note will still be valid.
We will need similar notes I think for our SunRPC -> TIRPC
transition, touching the various RPC man pages and explaining
any differences.
--
Cheers,
Carlos.
^ permalink raw reply
* Re: [PATCH 2/2] crypt.3, encrypt.3: Add notes about _XOPEN_CRYPT.
From: Michael Kerrisk (man-pages) @ 2018-04-13 9:34 UTC (permalink / raw)
To: Carlos O'Donell, linux-man@vger.kernel.org
Cc: mtk.manpages, Florian Weimer, Zack Weinberg, Rical Jasan,
GNU C Library
In-Reply-To: <6d9a7e45-5d31-efbd-78ad-2808d492eb21@redhat.com>
On 04/12/2018 09:05 PM, Carlos O'Donell wrote:
> The distribution may choose not to support _XOPEN_CRYPT in the
> case that the distribution has transitioned from glibc crypt to
> libxcrypt.
>
> Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Thanks, Carlos. I applied the patch, but rather than having the
exact same text in both pages, I simply added a cross reference
in encrypt(3).
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* Re: [PATCH 1/2] posixoptions.7: Expand XSI Options groups.
From: Michael Kerrisk (man-pages) @ 2018-04-13 9:33 UTC (permalink / raw)
To: Carlos O'Donell, linux-man@vger.kernel.org
Cc: mtk.manpages, Florian Weimer, GNU C Library, Zack Weinberg,
Rical Jasan
In-Reply-To: <2d6c47e9-0f34-c828-916e-a45fbf90f837@redhat.com>
On 04/12/2018 09:05 PM, Carlos O'Donell wrote:
> We define in detail the X/Open System Interfaces i.e. _XOPEN_UNIX
> and all of the X/Open System Interfaces (XSI) Options Groups.
>
> The XSI options groups include encryption, realtime, advanced
> realtime, realtime threads, advanced realtime threads, tracing,
> streams, and leagcy interfaces.
>
> Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Thanks, Carlos. Patch applied.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved
From: Michal Hocko @ 2018-04-13 6:49 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: John Hubbard, Jann Horn, linux-man, Andrew Morton, Linux-MM, lkml,
Linux API
In-Reply-To: <9c714917-fc29-4d12-b5e8-cff28761a2c1@gmail.com>
On Fri 13-04-18 08:43:27, Michael Kerrisk wrote:
[...]
> So, you mean remove this entire paragraph:
>
> For cases in which the specified memory region has not been
> reserved using an existing mapping, newer kernels (Linux
> 4.17 and later) provide an option MAP_FIXED_NOREPLACE that
> should be used instead; older kernels require the caller to
> use addr as a hint (without MAP_FIXED) and take appropriate
> action if the kernel places the new mapping at a different
> address.
>
> It seems like some version of the first half of the paragraph is worth
> keeping, though, so as to point the reader in the direction of a remedy.
> How about replacing that text with the following:
>
> Since Linux 4.17, the MAP_FIXED_NOREPLACE flag can be used
> in a multithreaded program to avoid the hazard described
> above.
Yes, that sounds reasonable to me.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved
From: Michael Kerrisk (man-pages) @ 2018-04-13 6:43 UTC (permalink / raw)
To: John Hubbard, Jann Horn
Cc: mtk.manpages, linux-man, Michal Hocko, Andrew Morton, Linux-MM,
lkml, Linux API
In-Reply-To: <cfbbbe06-5e63-e43c-fb28-c5afef9e1e1d@nvidia.com>
On 04/12/2018 09:24 PM, John Hubbard wrote:
> On 04/12/2018 12:18 PM, Jann Horn wrote:
>> On Thu, Apr 12, 2018 at 8:59 PM, John Hubbard <jhubbard@nvidia.com> wrote:
>>> On 04/12/2018 11:49 AM, Jann Horn wrote:
>>>> On Thu, Apr 12, 2018 at 8:37 PM, Michael Kerrisk (man-pages)
>>>> <mtk.manpages@gmail.com> wrote:
>>>>> Hi John,
>>>>>
>>>>> On 12 April 2018 at 20:33, John Hubbard <jhubbard@nvidia.com> wrote:
>>>>>> On 04/12/2018 08:39 AM, Jann Horn wrote:
>>>>>>> Clarify that MAP_FIXED is appropriate if the specified address range has
>>>>>>> been reserved using an existing mapping, but shouldn't be used otherwise.
>>>>>>>
>>>>>>> Signed-off-by: Jann Horn <jannh@google.com>
>>>>>>> ---
>>>>>>> man2/mmap.2 | 19 +++++++++++--------
>>>>>>> 1 file changed, 11 insertions(+), 8 deletions(-)
>>>>>>>
>>>>>>> diff --git a/man2/mmap.2 b/man2/mmap.2
>>>> [...]
>>>>>>> .IP
>>>>>>> For example, suppose that thread A looks through
>>>>>>> @@ -284,13 +285,15 @@ and the PAM libraries
>>>>>>> .UR http://www.linux-pam.org
>>>>>>> .UE .
>>>>>>> .IP
>>>>>>> -Newer kernels
>>>>>>> -(Linux 4.17 and later) have a
>>>>>>> +For cases in which the specified memory region has not been reserved using an
>>>>>>> +existing mapping, newer kernels (Linux 4.17 and later) provide an option
>>>>>>> .B MAP_FIXED_NOREPLACE
>>>>>>> -option that avoids the corruption problem; if available,
>>>>>>> -.B MAP_FIXED_NOREPLACE
>>>>>>> -should be preferred over
>>>>>>> -.BR MAP_FIXED .
>>>>>>> +that should be used instead; older kernels require the caller to use
>>>>>>> +.I addr
>>>>>>> +as a hint (without
>>>>>>> +.BR MAP_FIXED )
>>>>>>
>>>>>> Here, I got lost: the sentence suddenly jumps into explaining non-MAP_FIXED
>>>>>> behavior, in the MAP_FIXED section. Maybe if you break up the sentence, and
>>>>>> possibly omit non-MAP_FIXED discussion, it will help.
>>>>>
>>>>> Hmmm -- true. That piece could be a little clearer.
>>>>
>>>> How about something like this?
>>>>
>>>> For cases in which MAP_FIXED can not be used because
>>>> the specified memory
>>>> region has not been reserved using an existing mapping,
>>>> newer kernels
>>>> (Linux 4.17 and later) provide an option
>>>> MAP_FIXED_NOREPLACE that
>>>> should be used instead. Older kernels require the
>>>> caller to use addr as a hint and take appropriate action if
>>>> the kernel places the new mapping at a different address.
>>>>
>>>> John, Michael, what do you think?
>>>
>>>
>>> I'm still having difficulty with it, because this is in the MAP_FIXED section,
>>> but I think you're documenting the behavior that you get if you do *not*
>>> specify MAP_FIXED, right? Also, the hint behavior is true of both older and
>>> new kernels...
>>
>> The manpage patch you and mhocko wrote mentioned MAP_FIXED_NOREPLACE
>> in the MAP_FIXED section - I was trying to avoid undoing a change you
>> had just explicitly made.
>
> heh. So I've succeeding in getting my own wording removed, then? Progress! :)
>
>>
>>> So, if that's your intent (you want to sort of document by contrast to what
>>> would happen if this option were not used), then how about something like this:
>>>
>>>
>>> Without the MAP_FIXED option, the kernel would treat addr as a hint, rather
>>> than a requirement, and the caller would need to take appropriate action
>>> if the kernel placed the mapping at a different address. (For example,
>>> munmap and try again.)
>>
>> I'd be fine with removing the paragraph. As you rightly pointed out,
>> it doesn't really describe MAP_FIXED.
>>
>
> OK, that's probably the simplest fix.
So, you mean remove this entire paragraph:
For cases in which the specified memory region has not been
reserved using an existing mapping, newer kernels (Linux
4.17 and later) provide an option MAP_FIXED_NOREPLACE that
should be used instead; older kernels require the caller to
use addr as a hint (without MAP_FIXED) and take appropriate
action if the kernel places the new mapping at a different
address.
It seems like some version of the first half of the paragraph is worth
keeping, though, so as to point the reader in the direction of a remedy.
How about replacing that text with the following:
Since Linux 4.17, the MAP_FIXED_NOREPLACE flag can be used
in a multithreaded program to avoid the hazard described
above.
?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
^ permalink raw reply
* Re: [RFC bpf-next v2 4/8] bpf: add documentation for eBPF helpers (23-32)
From: Alexei Starovoitov @ 2018-04-13 0:28 UTC (permalink / raw)
To: Quentin Monnet; +Cc: daniel, ast, netdev, oss-drivers, linux-doc, linux-man
In-Reply-To: <20180410144157.4831-5-quentin.monnet@netronome.com>
On Tue, Apr 10, 2018 at 03:41:53PM +0100, Quentin Monnet wrote:
> Add documentation for eBPF helper functions to bpf.h user header file.
> This documentation can be parsed with the Python script provided in
> another commit of the patch series, in order to provide a RST document
> that can later be converted into a man page.
>
> The objective is to make the documentation easily understandable and
> accessible to all eBPF developers, including beginners.
>
> This patch contains descriptions for the following helper functions, all
> written by Daniel:
>
> - bpf_get_prandom_u32()
> - bpf_get_smp_processor_id()
> - bpf_get_cgroup_classid()
> - bpf_get_route_realm()
> - bpf_skb_load_bytes()
> - bpf_csum_diff()
> - bpf_skb_get_tunnel_opt()
> - bpf_skb_set_tunnel_opt()
> - bpf_skb_change_proto()
> - bpf_skb_change_type()
>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
> ---
> include/uapi/linux/bpf.h | 125 +++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 125 insertions(+)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index f3ea8824efbc..d147d9dd6a83 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -473,6 +473,14 @@ union bpf_attr {
> * The number of bytes written to the buffer, or a negative error
> * in case of failure.
> *
> + * u32 bpf_prandom_u32(void)
> + * Return
> + * A random 32-bit unsigned value.
there is no such helper.
It's called bpf_get_prandom_u32().
I'd also add a note that it's using its own random state and cannot be
used to infer seed of other random functions in the kernel.
> + *
> + * u32 bpf_get_smp_processor_id(void)
> + * Return
> + * The SMP (Symmetric multiprocessing) processor id.
probably worth adding a note to explain that all bpf programs run
with preemption disabled, so processor id is stable for the run of the program.
> + *
> * int bpf_skb_store_bytes(struct sk_buff *skb, u32 offset, const void *from, u32 len, u64 flags)
> * Description
> * Store *len* bytes from address *from* into the packet
> @@ -604,6 +612,13 @@ union bpf_attr {
> * Return
> * 0 on success, or a negative error in case of failure.
> *
> + * u32 bpf_get_cgroup_classid(struct sk_buff *skb)
> + * Description
> + * Retrieve the classid for the current task, i.e. for the
> + * net_cls (network classifier) cgroup to which *skb* belongs.
please add that kernel should be configured with CONFIG_NET_CLS_CGROUP=y|m
and mention Documentation/cgroup-v1/net_cls.txt
Otherwise 'network classifier' is way too generic.
I'd also mention that placing a task into net_cls controller
disables all of cgroup-bpf.
> + * Return
> + * The classid, or 0 for the default unconfigured classid.
> + *
> * int bpf_skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci)
> * Description
> * Push a *vlan_tci* (VLAN tag control information) of protocol
> @@ -703,6 +718,14 @@ union bpf_attr {
> * are **TC_ACT_REDIRECT** on success or **TC_ACT_SHOT** on
> * error.
> *
> + * u32 bpf_get_route_realm(struct sk_buff *skb)
> + * Description
> + * Retrieve the realm or the route, that is to say the
> + * **tclassid** field of the destination for the *skb*.
Similarly this only works if CONFIG_IP_ROUTE_CLASSID is on.
> + * Return
> + * The realm of the route for the packet associated to *sdb*, or 0
> + * if none was found.
> + *
> * int bpf_perf_event_output(struct pt_reg *ctx, struct bpf_map *map, u64 flags, void *data, u64 size)
> * Description
> * Write perf raw sample into a perf event held by *map* of type
> @@ -779,6 +802,21 @@ union bpf_attr {
> * Return
> * 0 on success, or a negative error in case of failure.
> *
> + * int bpf_skb_load_bytes(const struct sk_buff *skb, u32 offset, void *to, u32 len)
> + * Description
> + * This helper was provided as an easy way to load data from a
> + * packet. It can be used to load *len* bytes from *offset* from
> + * the packet associated to *skb*, into the buffer pointed by
> + * *to*.
> + *
> + * Since Linux 4.7, this helper is deprecated in favor of
> + * "direct packet access", enabling packet data to be manipulated
> + * with *skb*\ **->data** and *skb*\ **->data_end** pointing
> + * respectively to the first byte of packet data and to the byte
> + * after the last byte of packet data.
I wouldn't call it deprecated.
It's still useful when programmer wants to read large quantities of
data from the packet
> + * Return
> + * 0 on success, or a negative error in case of failure.
> + *
> * int bpf_get_stackid(struct pt_reg *ctx, struct bpf_map *map, u64 flags)
> * Description
> * Walk a user or a kernel stack and return its id. To achieve
> @@ -814,6 +852,93 @@ union bpf_attr {
> * The positive or null stack id on success, or a negative error
> * in case of failure.
> *
> + * s64 bpf_csum_diff(__be32 *from, u32 from_size, __be32 *to, u32 to_size, __wsum seed)
> + * Description
> + * Compute a checksum difference, from the raw buffer pointed by
> + * *from*, of length *from_size* (that must be a multiple of 4),
> + * towards the raw buffer pointed by *to*, of size *to_size*
> + * (same remark). An optional *seed* can be added to the value.
> + *
> + * This is flexible enough to be used in several ways:
> + *
> + * * With *from_size* == 0, *to_size* > 0 and *seed* set to
> + * checksum, it can be used when pushing new data.
> + * * With *from_size* > 0, *to_size* == 0 and *seed* set to
> + * checksum, it can be used when removing data from a packet.
> + * * With *from_size* > 0, *to_size* > 0 and *seed* set to 0, it
> + * can be used to compute a diff. Note that *from_size* and
> + * *to_size* do not need to be equal.
> + * Return
> + * The checksum result, or a negative error code in case of
> + * failure.
> + *
> + * int bpf_skb_get_tunnel_opt(struct sk_buff *skb, u8 *opt, u32 size)
> + * Description
> + * Retrieve tunnel options metadata for the packet associated to
> + * *skb*, and store the raw tunnel option data to the buffer *opt*
> + * of *size*.
> + * Return
> + * The size of the option data retrieved.
> + *
> + * int bpf_skb_set_tunnel_opt(struct sk_buff *skb, u8 *opt, u32 size)
> + * Description
> + * Set tunnel options metadata for the packet associated to *skb*
> + * to the option data contained in the raw buffer *opt* of *size*.
> + * Return
> + * 0 on success, or a negative error in case of failure.
> + *
> + * int bpf_skb_change_proto(struct sk_buff *skb, __be16 proto, u64 flags)
> + * Description
> + * Change the protocol of the *skb* to *proto*. Currently
> + * supported are transition from IPv4 to IPv6, and from IPv6 to
> + * IPv4. The helper takes care of the groundwork for the
> + * transition, including resizing the socket buffer. The eBPF
> + * program is expected to fill the new headers, if any, via
> + * **skb_store_bytes**\ () and to recompute the checksums with
> + * **bpf_l3_csum_replace**\ () and **bpf_l4_csum_replace**\
> + * ().
> + *
> + * Internally, the GSO type is marked as dodgy so that headers are
> + * checked and segments are recalculated by the GSO/GRO engine.
> + * The size for GSO target is adapted as well.
> + *
> + * All values for *flags* are reserved for future usage, and must
> + * be left at zero.
> + *
> + * A call to this helper is susceptible to change data from the
> + * packet. Therefore, at load time, all checks on pointers
> + * previously done by the verifier are invalidated and must be
> + * performed again.
> + * Return
> + * 0 on success, or a negative error in case of failure.
> + *
> + * int bpf_skb_change_type(struct sk_buff *skb, u32 type)
> + * Description
> + * Change the packet type for the packet associated to *skb*. This
> + * comes down to setting *skb*\ **->pkt_type** to *type*, except
> + * the eBPF program does not have a write access to *skb*\
> + * **->pkt_type** beside this helper. Using a helper here allows
> + * for graceful handling of errors.
> + *
> + * The major use case is to change incoming *skb*s to
> + * **PACKET_HOST** in a programmatic way instead of having to
> + * recirculate via **redirect**\ (..., **BPF_F_INGRESS**), for
> + * example.
> + *
> + * Note that *type* only allows certain values. At this time, they
> + * are:
> + *
> + * **PACKET_HOST**
> + * Packet is for us.
> + * **PACKET_BROADCAST**
> + * Send packet to all.
> + * **PACKET_MULTICAST**
> + * Send packet to group.
> + * **PACKET_OTHERHOST**
> + * Send packet to someone else.
> + * Return
> + * 0 on success, or a negative error in case of failure.
> + *
> * u64 bpf_get_current_task(void)
> * Return
> * A pointer to the current task struct.
> --
> 2.14.1
>
^ permalink raw reply
* Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved
From: John Hubbard @ 2018-04-12 19:24 UTC (permalink / raw)
To: Jann Horn
Cc: Michael Kerrisk-manpages, linux-man, Michal Hocko, Andrew Morton,
Linux-MM, lkml, Linux API
In-Reply-To: <CAG48ez085cASur3kZTRkdJY20dFZ4Yqc1KVOHxnCAn58_NtW8w@mail.gmail.com>
On 04/12/2018 12:18 PM, Jann Horn wrote:
> On Thu, Apr 12, 2018 at 8:59 PM, John Hubbard <jhubbard@nvidia.com> wrote:
>> On 04/12/2018 11:49 AM, Jann Horn wrote:
>>> On Thu, Apr 12, 2018 at 8:37 PM, Michael Kerrisk (man-pages)
>>> <mtk.manpages@gmail.com> wrote:
>>>> Hi John,
>>>>
>>>> On 12 April 2018 at 20:33, John Hubbard <jhubbard@nvidia.com> wrote:
>>>>> On 04/12/2018 08:39 AM, Jann Horn wrote:
>>>>>> Clarify that MAP_FIXED is appropriate if the specified address range has
>>>>>> been reserved using an existing mapping, but shouldn't be used otherwise.
>>>>>>
>>>>>> Signed-off-by: Jann Horn <jannh@google.com>
>>>>>> ---
>>>>>> man2/mmap.2 | 19 +++++++++++--------
>>>>>> 1 file changed, 11 insertions(+), 8 deletions(-)
>>>>>>
>>>>>> diff --git a/man2/mmap.2 b/man2/mmap.2
>>> [...]
>>>>>> .IP
>>>>>> For example, suppose that thread A looks through
>>>>>> @@ -284,13 +285,15 @@ and the PAM libraries
>>>>>> .UR http://www.linux-pam.org
>>>>>> .UE .
>>>>>> .IP
>>>>>> -Newer kernels
>>>>>> -(Linux 4.17 and later) have a
>>>>>> +For cases in which the specified memory region has not been reserved using an
>>>>>> +existing mapping, newer kernels (Linux 4.17 and later) provide an option
>>>>>> .B MAP_FIXED_NOREPLACE
>>>>>> -option that avoids the corruption problem; if available,
>>>>>> -.B MAP_FIXED_NOREPLACE
>>>>>> -should be preferred over
>>>>>> -.BR MAP_FIXED .
>>>>>> +that should be used instead; older kernels require the caller to use
>>>>>> +.I addr
>>>>>> +as a hint (without
>>>>>> +.BR MAP_FIXED )
>>>>>
>>>>> Here, I got lost: the sentence suddenly jumps into explaining non-MAP_FIXED
>>>>> behavior, in the MAP_FIXED section. Maybe if you break up the sentence, and
>>>>> possibly omit non-MAP_FIXED discussion, it will help.
>>>>
>>>> Hmmm -- true. That piece could be a little clearer.
>>>
>>> How about something like this?
>>>
>>> For cases in which MAP_FIXED can not be used because
>>> the specified memory
>>> region has not been reserved using an existing mapping,
>>> newer kernels
>>> (Linux 4.17 and later) provide an option
>>> MAP_FIXED_NOREPLACE that
>>> should be used instead. Older kernels require the
>>> caller to use addr as a hint and take appropriate action if
>>> the kernel places the new mapping at a different address.
>>>
>>> John, Michael, what do you think?
>>
>>
>> I'm still having difficulty with it, because this is in the MAP_FIXED section,
>> but I think you're documenting the behavior that you get if you do *not*
>> specify MAP_FIXED, right? Also, the hint behavior is true of both older and
>> new kernels...
>
> The manpage patch you and mhocko wrote mentioned MAP_FIXED_NOREPLACE
> in the MAP_FIXED section - I was trying to avoid undoing a change you
> had just explicitly made.
heh. So I've succeeding in getting my own wording removed, then? Progress! :)
>
>> So, if that's your intent (you want to sort of document by contrast to what
>> would happen if this option were not used), then how about something like this:
>>
>>
>> Without the MAP_FIXED option, the kernel would treat addr as a hint, rather
>> than a requirement, and the caller would need to take appropriate action
>> if the kernel placed the mapping at a different address. (For example,
>> munmap and try again.)
>
> I'd be fine with removing the paragraph. As you rightly pointed out,
> it doesn't really describe MAP_FIXED.
>
OK, that's probably the simplest fix.
thanks,
--
John Hubbard
NVIDIA
^ permalink raw reply
* Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved
From: Jann Horn @ 2018-04-12 19:18 UTC (permalink / raw)
To: John Hubbard
Cc: Michael Kerrisk-manpages, linux-man, Michal Hocko, Andrew Morton,
Linux-MM, lkml, Linux API
In-Reply-To: <13801e2a-c44d-e940-f872-890a0612a483@nvidia.com>
On Thu, Apr 12, 2018 at 8:59 PM, John Hubbard <jhubbard@nvidia.com> wrote:
> On 04/12/2018 11:49 AM, Jann Horn wrote:
>> On Thu, Apr 12, 2018 at 8:37 PM, Michael Kerrisk (man-pages)
>> <mtk.manpages@gmail.com> wrote:
>>> Hi John,
>>>
>>> On 12 April 2018 at 20:33, John Hubbard <jhubbard@nvidia.com> wrote:
>>>> On 04/12/2018 08:39 AM, Jann Horn wrote:
>>>>> Clarify that MAP_FIXED is appropriate if the specified address range has
>>>>> been reserved using an existing mapping, but shouldn't be used otherwise.
>>>>>
>>>>> Signed-off-by: Jann Horn <jannh@google.com>
>>>>> ---
>>>>> man2/mmap.2 | 19 +++++++++++--------
>>>>> 1 file changed, 11 insertions(+), 8 deletions(-)
>>>>>
>>>>> diff --git a/man2/mmap.2 b/man2/mmap.2
>> [...]
>>>>> .IP
>>>>> For example, suppose that thread A looks through
>>>>> @@ -284,13 +285,15 @@ and the PAM libraries
>>>>> .UR http://www.linux-pam.org
>>>>> .UE .
>>>>> .IP
>>>>> -Newer kernels
>>>>> -(Linux 4.17 and later) have a
>>>>> +For cases in which the specified memory region has not been reserved using an
>>>>> +existing mapping, newer kernels (Linux 4.17 and later) provide an option
>>>>> .B MAP_FIXED_NOREPLACE
>>>>> -option that avoids the corruption problem; if available,
>>>>> -.B MAP_FIXED_NOREPLACE
>>>>> -should be preferred over
>>>>> -.BR MAP_FIXED .
>>>>> +that should be used instead; older kernels require the caller to use
>>>>> +.I addr
>>>>> +as a hint (without
>>>>> +.BR MAP_FIXED )
>>>>
>>>> Here, I got lost: the sentence suddenly jumps into explaining non-MAP_FIXED
>>>> behavior, in the MAP_FIXED section. Maybe if you break up the sentence, and
>>>> possibly omit non-MAP_FIXED discussion, it will help.
>>>
>>> Hmmm -- true. That piece could be a little clearer.
>>
>> How about something like this?
>>
>> For cases in which MAP_FIXED can not be used because
>> the specified memory
>> region has not been reserved using an existing mapping,
>> newer kernels
>> (Linux 4.17 and later) provide an option
>> MAP_FIXED_NOREPLACE that
>> should be used instead. Older kernels require the
>> caller to use addr as a hint and take appropriate action if
>> the kernel places the new mapping at a different address.
>>
>> John, Michael, what do you think?
>
>
> I'm still having difficulty with it, because this is in the MAP_FIXED section,
> but I think you're documenting the behavior that you get if you do *not*
> specify MAP_FIXED, right? Also, the hint behavior is true of both older and
> new kernels...
The manpage patch you and mhocko wrote mentioned MAP_FIXED_NOREPLACE
in the MAP_FIXED section - I was trying to avoid undoing a change you
had just explicitly made.
> So, if that's your intent (you want to sort of document by contrast to what
> would happen if this option were not used), then how about something like this:
>
>
> Without the MAP_FIXED option, the kernel would treat addr as a hint, rather
> than a requirement, and the caller would need to take appropriate action
> if the kernel placed the mapping at a different address. (For example,
> munmap and try again.)
I'd be fine with removing the paragraph. As you rightly pointed out,
it doesn't really describe MAP_FIXED.
^ permalink raw reply
* [PATCH 2/2] crypt.3, encrypt.3: Add notes about _XOPEN_CRYPT.
From: Carlos O'Donell @ 2018-04-12 19:05 UTC (permalink / raw)
To: linux-man@vger.kernel.org, Michael Kerrisk
Cc: Florian Weimer, Zack Weinberg, Rical Jasan, GNU C Library
[-- Attachment #1: Type: text/plain, Size: 210 bytes --]
The distribution may choose not to support _XOPEN_CRYPT in the
case that the distribution has transitioned from glibc crypt to
libxcrypt.
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
--
Cheers,
Carlos.
[-- Attachment #2: 0002-crypt.3-encrypt.3-Add-notes-about-_XOPEN_CRYPT.patch --]
[-- Type: text/x-patch, Size: 2621 bytes --]
>From d099bd9550d28da19dd082d27491f49bd8c721e9 Mon Sep 17 00:00:00 2001
From: Carlos O'Donell <carlos@systemhalted.org>
Date: Thu, 12 Apr 2018 13:58:27 -0500
Subject: [PATCH 2/2] crypt.3, encrypt.3: Add notes about _XOPEN_CRYPT.
The distribution may choose not to support _XOPEN_CRYPT in the
case that the distribution has transitioned from glibc crypt to
libxcrypt.
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
---
man3/crypt.3 | 22 ++++++++++++++++++++--
man3/encrypt.3 | 19 +++++++++++++++++++
2 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/man3/crypt.3 b/man3/crypt.3
index 3e6552ad8..58c62d93d 100644
--- a/man3/crypt.3
+++ b/man3/crypt.3
@@ -188,8 +188,26 @@ POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD.
.BR crypt_r ()
is a GNU extension.
.SH NOTES
-.SS Glibc notes
-The glibc2 version of this function supports additional
+.SS Availability in glibc
+The
+.BR crypt (),
+.BR encrypt (),
+and
+.BR setkey ()
+functions are part of the POSIX.1-2008 XSI Options Group for Encryption
+and are optional. If the interfaces are not available then the symbolic
+constant
+.BR _XOPEN_CRYPT
+is either not defined or defined to -1, and can be checked at runtime with
+.BR sysconf ().
+This may be the case if the downstream distribution has switched from glibc
+crypt to libxcrypt. When recompiling applications in such distributions the
+user must detect if
+.BR _XOPEN_CRPYT
+is not available and include crypt.h for the function prototypes; otherwise
+libxcrypt is a ABI compatible drop-in replacement.
+.SS Features in glibc
+The glibc version of this function supports additional
encryption algorithms.
.PP
If
diff --git a/man3/encrypt.3 b/man3/encrypt.3
index 3a1cf9598..3df4870c3 100644
--- a/man3/encrypt.3
+++ b/man3/encrypt.3
@@ -147,6 +147,25 @@ and
.BR setkey_r ()
are GNU extensions.
.SH NOTES
+.SS Availability in glibc
+The
+.BR crypt (),
+.BR encrypt (),
+and
+.BR setkey ()
+functions are part of the POSIX.1-2008 XSI Options Group for Encryption
+and are optional. If the interfaces are not available then the symbolic
+constant
+.BR _XOPEN_CRYPT
+is either not defined or defined to -1, and can be checked at runtime with
+.BR sysconf ().
+This may be the case if the downstream distribution has switched from glibc
+crypt to libxcrypt. When recompiling applications in such distributions the
+user must detect if
+.BR _XOPEN_CRPYT
+is not available and include crypt.h for the function prototypes; otherwise
+libxcrypt is a ABI compatible drop-in replacement.
+.SS Features in glibc
In glibc 2.2, these functions use the DES algorithm.
.SH EXAMPLE
.EX
--
2.14.3
^ permalink raw reply related
* [PATCH 1/2] posixoptions.7: Expand XSI Options groups.
From: Carlos O'Donell @ 2018-04-12 19:05 UTC (permalink / raw)
To: linux-man@vger.kernel.org, Michael Kerrisk
Cc: Florian Weimer, GNU C Library, Zack Weinberg, Rical Jasan
[-- Attachment #1: Type: text/plain, Size: 359 bytes --]
We define in detail the X/Open System Interfaces i.e. _XOPEN_UNIX
and all of the X/Open System Interfaces (XSI) Options Groups.
The XSI options groups include encryption, realtime, advanced
realtime, realtime threads, advanced realtime threads, tracing,
streams, and leagcy interfaces.
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
--
Cheers,
Carlos.
[-- Attachment #2: 0001-posixoptions.7-Expand-XSI-Options-groups.patch --]
[-- Type: text/x-patch, Size: 4636 bytes --]
>From eb192289fb958f427904dd2588aa0419e050bd6a Mon Sep 17 00:00:00 2001
From: Carlos O'Donell <carlos@systemhalted.org>
Date: Thu, 12 Apr 2018 13:33:00 -0500
Subject: [PATCH 1/2] posixoptions.7: Expand XSI Options groups.
We define in detail the X/Open System Interfaces i.e. _XOPEN_UNIX
and all of the X/Open System Interfaces (XSI) Options Groups.
The XSI options groups include encryption, realtime, advanced
realtime, realtime threads, advanced realtime threads, tracing,
streams, and leagcy interfaces.
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
---
man7/posixoptions.7 | 137 +++++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 130 insertions(+), 7 deletions(-)
diff --git a/man7/posixoptions.7 b/man7/posixoptions.7
index 7e912beae..2c3f2fe96 100644
--- a/man7/posixoptions.7
+++ b/man7/posixoptions.7
@@ -779,13 +779,136 @@ The following functions are present:
Always present (probably 0).
Value to set a changeable special control
character to indicate that it is disabled.
-.SH XOPEN EXTENSIONS
-.BR _XOPEN_CRYPT ,
-.BR _XOPEN_LEGACY ,
-.BR _XOPEN_REALTIME ,
-.BR _XOPEN_REALTIME_THREADS ,
-.BR _XOPEN_UNIX .
-.\" To be described.
+.SH X/OPEN SYSTEM INTERFACES EXTENSIONS
+.SS XSI - _XOPEN_CRYPT - _SC_XOPEN_CRYPT
+The following functions are present:
+.PP
+.nf
+.in +4n
+.IR crypt (),
+.IR encrypt (),
+.IR setkey ()
+.SS XSI - _XOPEN_REALTIME - _SC_XOPEN_REALTIME
+This option implies the
+.B _POSIX_ASYNCHRONOUS_IO == 200112L,
+.B _POSIX_FSYNC,
+.B _POSIX_MAPPED_FILES,
+.B _POSIX_MEMLOCK == 200112L,
+.B _POSIX_MEMLOCK_RANGE == 200112L,
+.B _POSIX_MEMORY_PROTECTION,
+.B _POSIX_MESSAGE_PASSING == 200112L,
+.B _POSIX_PRIORITIZED_IO,
+.B _POSIX_PRIORITY_SCHEDULING == 200112L,
+.B _POSIX_REALTIME_SIGNALS == 200112L,
+.B _POSIX_SEMAPHORES == 200112L,
+.B _POSIX_SHARED_MEMORY_OBJECTS == 200112L,
+.B _POSIX_SYNCHRONIZED_IO == 200112L,
+and
+.B _POSIX_TIMERS == 200112L
+options.
+.SS ADV - --- - ---
+The Advanced Realtime option group implies the
+.B _POSIX_ADVISORY_INFO,
+.B _POSIX_CLOCK_SELECTION (implies _POSIX_TIMERS),
+.B _POSIX_CPUTIME (implies _POSIX_TIMERS),
+.B _POSIX_MONOTONIC_CLOCK (implies _POSIX_TIMERS),
+.B _POSIX_SPAWN,
+.B _POSIX_SPORADIC_SERVER (implies _POSIX_PRIORITY_SCHEDULING),
+.B _POSIX_TIMEOUTS,
+and
+.B _POSIX_TYPED_MEMORY_OBJECTS
+options are all defined to 200112L.
+.SS XSI - _XOPEN_REALTIME_THREADS - _SC_XOPEN_REALTIME_THREADS
+This option implies the
+.B _POSIX_THREAD_PRIO_INHERIT,
+.B _POSIX_THREAD_PRIO_PROTECT,
+and
+.B _POSIX_THREAD_PRIORITY_SCHEDULING
+options are all defined to 200112L.
+.SS ADVANCED REALTIME THREADS - --- - ---
+The option implies the
+.B _POSIX_BARRIERS (implies _POSIX_THREADS, _POSIX_THREAD_SAFE_FUNCTIONS),
+.B _POSIX_SPIN_LOCKS (implies _POSIX_THREADS, _POSIX_THREAD_SAFE_FUNCTIONS),
+.B _POSIX_THREAD_CPUTIME (implies _POSIX_TIMERS),
+and
+.B _POSIX_THREAD_SPORADIC_SERVER (implies _POSIX_THREAD_PRIORITY_SCHEDULING)
+options are all defined to 200112L.
+.SS TRACING - --- - ---
+The option implies the
+.B _POSIX_TRACE,
+.B _POSIX_TRACE_EVENT_FILTER,
+.B _POSIX_TRACE_LOG,
+and
+.B _POSIX_TRACE_INHERIT
+options and defined to 200112L.
+.SS STREAMS - _XOPEN_STREAMS - _SC_XOPEN_STREAMS
+The following functions are present:
+.PP
+.nf
+.in +4n
+.IR fattach ()
+.IR fdetach ()
+.IR getmsg ()
+.IR getpmsg ()
+.IR ioctl ()
+.IR iastream ()
+.IR putmsg ()
+.IR putpmsg ()
+.SS XSI - _XOPEN_LEGACY - _SC_XOPEN_LEGACY
+Functions included in the legacy option group were previously mandatory,
+but are now optional in this version.
+The following functions are present:
+.PP
+.nf
+.in +4n
+.IR bcmp (),
+.IR bcopy (),
+.IR bzero (),
+.IR ecvt (),
+.IR fcvt (),
+.IR ftime (),
+.IR gcvt (),
+.IR getcwd (),
+.IR index (),
+.IR mktemp (),
+.IR rindex (),
+.IR utimes (),
+.IR wcswcs ()
+.SS XSI - _XOPEN_UNIX - _SC_XOPEN_UNIX
+The following functions are present:
+.PP
+.nf
+.in +4n
+.IR mmap (),
+.IR munmap (),
+and
+.IR msync.
+.in -4n
+.fi
+.PP
+The option implies the
+.B _POSIX_FSYNC,
+.B _POSIX_MAPPED_FILES,
+.B _POSIX_MEMORY_PROTECTION,
+.B _POSIX_THREAD_ATTR_STACKADDR,
+.B _POSIX_THREAD_ATTR_STACKSIZE,
+.B _POSIX_THREAD_PROCESS_SHARED,
+.B _POSIX_THREAD_SAFE_FUNCTIONS,
+and
+.B _POSIX_THREADS
+options.
+.PP
+The option may imply the
+.B Encryption (_XOPEN_CRYPT),
+.B Realtime (_XOPEN_REALTIME),
+.B Advanced Raltime (ADB),
+.B Realtime Threads (_XOPEN_REALTIME_THREADS),
+.B Advanced Realtime Threads (ADVANCED REALTIME THREADS),
+.B Tracing (TRACING),
+.B XSI Streams (STREAMS),
+and
+.B Legacy (_XOPEN_LEGACY)
+options from the XSI option groups.
.SH SEE ALSO
.BR sysconf (3),
.BR standards (7)
--
2.14.3
^ permalink raw reply related
* Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved
From: John Hubbard @ 2018-04-12 18:59 UTC (permalink / raw)
To: Jann Horn, Michael Kerrisk-manpages
Cc: linux-man, Michal Hocko, Andrew Morton, Linux-MM, lkml, Linux API
In-Reply-To: <CAG48ez2NtCr8+HqnKJTFBcLW+kCKUa=2pz=7HD9p9u1p-MfJqw@mail.gmail.com>
On 04/12/2018 11:49 AM, Jann Horn wrote:
> On Thu, Apr 12, 2018 at 8:37 PM, Michael Kerrisk (man-pages)
> <mtk.manpages@gmail.com> wrote:
>> Hi John,
>>
>> On 12 April 2018 at 20:33, John Hubbard <jhubbard@nvidia.com> wrote:
>>> On 04/12/2018 08:39 AM, Jann Horn wrote:
>>>> Clarify that MAP_FIXED is appropriate if the specified address range has
>>>> been reserved using an existing mapping, but shouldn't be used otherwise.
>>>>
>>>> Signed-off-by: Jann Horn <jannh@google.com>
>>>> ---
>>>> man2/mmap.2 | 19 +++++++++++--------
>>>> 1 file changed, 11 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/man2/mmap.2 b/man2/mmap.2
> [...]
>>>> .IP
>>>> For example, suppose that thread A looks through
>>>> @@ -284,13 +285,15 @@ and the PAM libraries
>>>> .UR http://www.linux-pam.org
>>>> .UE .
>>>> .IP
>>>> -Newer kernels
>>>> -(Linux 4.17 and later) have a
>>>> +For cases in which the specified memory region has not been reserved using an
>>>> +existing mapping, newer kernels (Linux 4.17 and later) provide an option
>>>> .B MAP_FIXED_NOREPLACE
>>>> -option that avoids the corruption problem; if available,
>>>> -.B MAP_FIXED_NOREPLACE
>>>> -should be preferred over
>>>> -.BR MAP_FIXED .
>>>> +that should be used instead; older kernels require the caller to use
>>>> +.I addr
>>>> +as a hint (without
>>>> +.BR MAP_FIXED )
>>>
>>> Here, I got lost: the sentence suddenly jumps into explaining non-MAP_FIXED
>>> behavior, in the MAP_FIXED section. Maybe if you break up the sentence, and
>>> possibly omit non-MAP_FIXED discussion, it will help.
>>
>> Hmmm -- true. That piece could be a little clearer.
>
> How about something like this?
>
> For cases in which MAP_FIXED can not be used because
> the specified memory
> region has not been reserved using an existing mapping,
> newer kernels
> (Linux 4.17 and later) provide an option
> MAP_FIXED_NOREPLACE that
> should be used instead. Older kernels require the
> caller to use addr as a hint and take appropriate action if
> the kernel places the new mapping at a different address.
>
> John, Michael, what do you think?
I'm still having difficulty with it, because this is in the MAP_FIXED section,
but I think you're documenting the behavior that you get if you do *not*
specify MAP_FIXED, right? Also, the hint behavior is true of both older and
new kernels...
So, if that's your intent (you want to sort of document by contrast to what
would happen if this option were not used), then how about something like this:
Without the MAP_FIXED option, the kernel would treat addr as a hint, rather
than a requirement, and the caller would need to take appropriate action
if the kernel placed the mapping at a different address. (For example,
munmap and try again.)
thanks,
--
John Hubbard
NVIDIA
^ permalink raw reply
* Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved
From: Jann Horn @ 2018-04-12 18:49 UTC (permalink / raw)
To: Michael Kerrisk-manpages, John Hubbard
Cc: linux-man, Michal Hocko, Andrew Morton, Linux-MM, lkml, Linux API
In-Reply-To: <CAKgNAkgcJ2kCTff0=7=D3zPFwpJt-9EM8yis6-4qDjfvvb8ukw@mail.gmail.com>
On Thu, Apr 12, 2018 at 8:37 PM, Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
> Hi John,
>
> On 12 April 2018 at 20:33, John Hubbard <jhubbard@nvidia.com> wrote:
>> On 04/12/2018 08:39 AM, Jann Horn wrote:
>>> Clarify that MAP_FIXED is appropriate if the specified address range has
>>> been reserved using an existing mapping, but shouldn't be used otherwise.
>>>
>>> Signed-off-by: Jann Horn <jannh@google.com>
>>> ---
>>> man2/mmap.2 | 19 +++++++++++--------
>>> 1 file changed, 11 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/man2/mmap.2 b/man2/mmap.2
[...]
>>> .IP
>>> For example, suppose that thread A looks through
>>> @@ -284,13 +285,15 @@ and the PAM libraries
>>> .UR http://www.linux-pam.org
>>> .UE .
>>> .IP
>>> -Newer kernels
>>> -(Linux 4.17 and later) have a
>>> +For cases in which the specified memory region has not been reserved using an
>>> +existing mapping, newer kernels (Linux 4.17 and later) provide an option
>>> .B MAP_FIXED_NOREPLACE
>>> -option that avoids the corruption problem; if available,
>>> -.B MAP_FIXED_NOREPLACE
>>> -should be preferred over
>>> -.BR MAP_FIXED .
>>> +that should be used instead; older kernels require the caller to use
>>> +.I addr
>>> +as a hint (without
>>> +.BR MAP_FIXED )
>>
>> Here, I got lost: the sentence suddenly jumps into explaining non-MAP_FIXED
>> behavior, in the MAP_FIXED section. Maybe if you break up the sentence, and
>> possibly omit non-MAP_FIXED discussion, it will help.
>
> Hmmm -- true. That piece could be a little clearer.
How about something like this?
For cases in which MAP_FIXED can not be used because
the specified memory
region has not been reserved using an existing mapping,
newer kernels
(Linux 4.17 and later) provide an option
MAP_FIXED_NOREPLACE that
should be used instead. Older kernels require the
caller to use addr as a hint and take appropriate action if
the kernel places the new mapping at a different address.
John, Michael, what do you think?
> Jann, I've already pushed the existing patch. Do you want to add a patch on top?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox