For review: nptl(7) man page

For review: nptl(7) man page

[Michael Kerrisk (man-pages)]

Hello all,

I wrote a short man page documented some of the details of 
NPTL that might affect application developers. Review comments
would be most welcome.

Thanks,

Michael

===
.\" Copyright (c) 2015 by Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
.\"
.\" %%%LICENSE_START(VERBATIM)
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one.
.\"
.\" Since the Linux kernel and libraries are constantly changing, this
.\" manual page may be incorrect or out-of-date.  The author(s) assume no
.\" responsibility for errors or omissions, or for damages resulting from
.\" the use of the information contained herein.  The author(s) may not
.\" have taken the same level of care in the production of this manual,
.\" which is licensed free of charge, as they might when working
.\" professionally.
.\"
.\" Formatted or processed versions of this manual, if unaccompanied by
.\" the source, must acknowledge the copyright and authors of this work.
.\" %%%LICENSE_END
.\"
.\"
.TH NPTL 7 2015-03-21 "Linux" "Linux Programmer's Manual"
.SH NAME
nptl \- Native POSIX Threads Library
.SH DESCRIPTION
NPTL (Native POSIX Threads Library)
is the GNU C library POSIX threads implementation that is used on modern
Linux systems.
.\"
.SS NPTL and signals
NPTL makes internal use of the first two real-time signals
(signal numbers 32 and 33).
One of these signals is used to support thread cancellation and POSIX timers;
the other is used as part of a mechanism that ensures all threads in
a process always have the same UIDs and GIDs, as required by POSIX.
These signals cannot be used in applications.

To prevent accidental use of these signals in applications,
which might interfere with the operation of the NPTL implementation,
various glibc library functions and system call wrapper functions
attempt to hide these signals from applications,
as follows:
.IP * 3
.B SIGRTMIN
is defined with the value 34 (rather than 32).
.IP *
The
.BR sigwaitinfo (2),
.BR sigtimedwait (2),
and
.BR sigwait (3)
interfaces silently ignore requests to wait for these two signals
if they are specified in the signal set argument of these calls.
.IP *
The
.BR sigprocmask (2)
and
.BR pthread_sigmask (3)
interfaces silently ignore attempts to block these two signals.
.IP *
The
.BR sigaction (2),
.BR pthread_kill (3),
and
.BR pthread_sigqueue (3)
interfaces fail with the error
.B EINVAL
(indicating an invalid signal number) if these signals are specified.
.IP *
.BR sigfillset (3)
does not include these two signals when it creates a full signal set.
.\"
.SS NPTL and process credential changes
At the Linux kernel level,
credentials (user and group IDs) are a per-thread attribute.
However, POSIX requires that all of the POSIX threads in a process
have the same credentials.
To accommodate this requirement,
the NPTL implementation wraps all of the system calls that
change process credentials with functions that,
in addition to invoking the underlying system call,
arrange for all other threads in the process to also change their credentials.

The implementation of each of these system calls involves the use of 
a real-time signal that is sent (using
.BR tgkill (2))
to each of the other threads that must change change its credentials.
Before sending these signals, the thread that is changing credentials
saves the new credential(s) and records the system call being employed
in a global buffer.
A signal handler in the receiving thread(s) fetches this information and
then uses the same system call to change its credentials.

Wrapper functions employing this technique are provided for
.BR setgid (2),
.BR setuid (2),
.BR setegid (2),
.BR seteuid (2),
.BR setregid (2),
.BR setreuid (2),
.BR setresgid (2),
.BR setresuid (2),
and
.BR setgroups (2).
.SH CONFORMING TO
For details of the conformance of NPTL to the POSIX standard, see
.BR pthreads (7).
.SH SEE ALSO
.BR credentials (7),
.BR pthreads (7),
.BR signal (7),
.BR standards (7)

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: nptl(7) man page

[Bert Wesarg]

On Sun, Mar 22, 2015 at 3:38 PM, Michael Kerrisk (man-pages)
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hello all,
>
> I wrote a short man page documented some of the details of
> NPTL that might affect application developers. Review comments
> would be most welcome.
>
> Thanks,
>
> Michael
>
> ===
> .\" Copyright (c) 2015 by Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> .\"
> .\" %%%LICENSE_START(VERBATIM)
> .\" Permission is granted to make and distribute verbatim copies of this
> .\" manual provided the copyright notice and this permission notice are
> .\" preserved on all copies.
> .\"
> .\" Permission is granted to copy and distribute modified versions of this
> .\" manual under the conditions for verbatim copying, provided that the
> .\" entire resulting derived work is distributed under the terms of a
> .\" permission notice identical to this one.
> .\"
> .\" Since the Linux kernel and libraries are constantly changing, this
> .\" manual page may be incorrect or out-of-date.  The author(s) assume no
> .\" responsibility for errors or omissions, or for damages resulting from
> .\" the use of the information contained herein.  The author(s) may not
> .\" have taken the same level of care in the production of this manual,
> .\" which is licensed free of charge, as they might when working
> .\" professionally.
> .\"
> .\" Formatted or processed versions of this manual, if unaccompanied by
> .\" the source, must acknowledge the copyright and authors of this work.
> .\" %%%LICENSE_END
> .\"
> .\"
> .TH NPTL 7 2015-03-21 "Linux" "Linux Programmer's Manual"
> .SH NAME
> nptl \- Native POSIX Threads Library
> .SH DESCRIPTION
> NPTL (Native POSIX Threads Library)
> is the GNU C library POSIX threads implementation that is used on modern
> Linux systems.
> .\"
> .SS NPTL and signals
> NPTL makes internal use of the first two real-time signals
> (signal numbers 32 and 33).
> One of these signals is used to support thread cancellation and POSIX timers;
> the other is used as part of a mechanism that ensures all threads in
> a process always have the same UIDs and GIDs, as required by POSIX.
> These signals cannot be used in applications.
>
> To prevent accidental use of these signals in applications,
> which might interfere with the operation of the NPTL implementation,
> various glibc library functions and system call wrapper functions
> attempt to hide these signals from applications,
> as follows:
> .IP * 3
> .B SIGRTMIN
> is defined with the value 34 (rather than 32).
> .IP *
> The
> .BR sigwaitinfo (2),
> .BR sigtimedwait (2),
> and
> .BR sigwait (3)
> interfaces silently ignore requests to wait for these two signals
> if they are specified in the signal set argument of these calls.
> .IP *
> The
> .BR sigprocmask (2)
> and
> .BR pthread_sigmask (3)
> interfaces silently ignore attempts to block these two signals.
> .IP *
> The
> .BR sigaction (2),
> .BR pthread_kill (3),
> and
> .BR pthread_sigqueue (3)
> interfaces fail with the error
> .B EINVAL
> (indicating an invalid signal number) if these signals are specified.
> .IP *
> .BR sigfillset (3)
> does not include these two signals when it creates a full signal set.
> .\"
> .SS NPTL and process credential changes
> At the Linux kernel level,
> credentials (user and group IDs) are a per-thread attribute.
> However, POSIX requires that all of the POSIX threads in a process
> have the same credentials.
> To accommodate this requirement,
> the NPTL implementation wraps all of the system calls that
> change process credentials with functions that,
> in addition to invoking the underlying system call,
> arrange for all other threads in the process to also change their credentials.
>
> The implementation of each of these system calls involves the use of
> a real-time signal that is sent (using
> .BR tgkill (2))
> to each of the other threads that must change change its credentials.

s/change change/change/

Bert

> Before sending these signals, the thread that is changing credentials
> saves the new credential(s) and records the system call being employed
> in a global buffer.
> A signal handler in the receiving thread(s) fetches this information and
> then uses the same system call to change its credentials.
>
> Wrapper functions employing this technique are provided for
> .BR setgid (2),
> .BR setuid (2),
> .BR setegid (2),
> .BR seteuid (2),
> .BR setregid (2),
> .BR setreuid (2),
> .BR setresgid (2),
> .BR setresuid (2),
> and
> .BR setgroups (2).
> .SH CONFORMING TO
> For details of the conformance of NPTL to the POSIX standard, see
> .BR pthreads (7).
> .SH SEE ALSO
> .BR credentials (7),
> .BR pthreads (7),
> .BR signal (7),
> .BR standards (7)
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-man" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: nptl(7) man page

[Michael Kerrisk (man-pages)]

Hello Bert,

On 22 March 2015 at 16:51, Bert Wesarg <bert.wesarg-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> On Sun, Mar 22, 2015 at 3:38 PM, Michael Kerrisk (man-pages)
> <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
[...]
>> to each of the other threads that must change change its credentials.
>
> s/change change/change/

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/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: nptl(7) man page

[Szabolcs Nagy]

* Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> [2015-03-22 15:38:44 +0100]:
> .\"
> .TH NPTL 7 2015-03-21 "Linux" "Linux Programmer's Manual"
> .SH NAME
> nptl \- Native POSIX Threads Library
> .SH DESCRIPTION
> NPTL (Native POSIX Threads Library)
> is the GNU C library POSIX threads implementation that is used on modern
> Linux systems.
> .\"
> .SS NPTL and signals
> NPTL makes internal use of the first two real-time signals
> (signal numbers 32 and 33).
> One of these signals is used to support thread cancellation and POSIX timers;
> the other is used as part of a mechanism that ensures all threads in
> a process always have the same UIDs and GIDs, as required by POSIX.
> These signals cannot be used in applications.
> 
> To prevent accidental use of these signals in applications,
> which might interfere with the operation of the NPTL implementation,
> various glibc library functions and system call wrapper functions
> attempt to hide these signals from applications,
> as follows:
> .IP * 3
> .B SIGRTMIN
> is defined with the value 34 (rather than 32).
> .IP *
> The
> .BR sigwaitinfo (2),
> .BR sigtimedwait (2),
> and
> .BR sigwait (3)
> interfaces silently ignore requests to wait for these two signals
> if they are specified in the signal set argument of these calls.
> .IP *
> The
> .BR sigprocmask (2)
> and
> .BR pthread_sigmask (3)
> interfaces silently ignore attempts to block these two signals.
> .IP *
> The
> .BR sigaction (2),
> .BR pthread_kill (3),
> and
> .BR pthread_sigqueue (3)
> interfaces fail with the error
> .B EINVAL
> (indicating an invalid signal number) if these signals are specified.
> .IP *
> .BR sigfillset (3)
> does not include these two signals when it creates a full signal set.
> .\"

are these abi details expected to be stable?
(i'm not against documenting the existing
implementation just curious if this is supposed
to hold for all new archs)

in theory for an application it is enough to know
that it can only use the signals it can name and
there might be implementation internal signals
that cannot be masked (which might need to be taken
into account when calculating a thread stack size).

> .SS NPTL and process credential changes
> At the Linux kernel level,
> credentials (user and group IDs) are a per-thread attribute.
> However, POSIX requires that all of the POSIX threads in a process
> have the same credentials.
> To accommodate this requirement,
> the NPTL implementation wraps all of the system calls that
> change process credentials with functions that,
> in addition to invoking the underlying system call,
> arrange for all other threads in the process to also change their credentials.
> 
> The implementation of each of these system calls involves the use of 
> a real-time signal that is sent (using
> .BR tgkill (2))
> to each of the other threads that must change change its credentials.
> Before sending these signals, the thread that is changing credentials
> saves the new credential(s) and records the system call being employed
> in a global buffer.
> A signal handler in the receiving thread(s) fetches this information and
> then uses the same system call to change its credentials.
> 

i think the situation described in

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

might be worth documenting

vfork is not serialized wrt setxid functions

(but it would be better if the kernel got fixed
to have a new set of posix setxid syscalls that
change credentials atomically for the process)

> Wrapper functions employing this technique are provided for
> .BR setgid (2),
> .BR setuid (2),
> .BR setegid (2),
> .BR seteuid (2),
> .BR setregid (2),
> .BR setreuid (2),
> .BR setresgid (2),
> .BR setresuid (2),
> and
> .BR setgroups (2).
> .SH CONFORMING TO
> For details of the conformance of NPTL to the POSIX standard, see
> .BR pthreads (7).
> .SH SEE ALSO
> .BR credentials (7),
> .BR pthreads (7),
> .BR signal (7),
> .BR standards (7)
> 
> -- 
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/

Re: For review: nptl(7) man page

[Nicholas Miell]

On 03/22/2015 07:38 AM, Michael Kerrisk (man-pages) wrote:
> Hello all,
>
> I wrote a short man page documented some of the details of
> NPTL that might affect application developers. Review comments
> would be most welcome.
>
> Thanks,
>
> Michael

POSIX specifies that process-shared pthread_mutex_t's can be manipulated 
by independent processes, however the AMD64 and i386 versions of the 
mutex structures are incompatible and cannot be shared.

This might be true of the other supposedly sharable primitives, I never 
bothered to check the rest when I first noticed the problem with mutexes.

Re: For review: nptl(7) man page

[Michael Kerrisk (man-pages)]

On 03/22/2015 08:56 PM, Szabolcs Nagy wrote:
> * Michael Kerrisk (man-pages) <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [2015-03-22 15:38:44 +0100]:
>> .\"
>> .TH NPTL 7 2015-03-21 "Linux" "Linux Programmer's Manual"
>> .SH NAME
>> nptl \- Native POSIX Threads Library
>> .SH DESCRIPTION
>> NPTL (Native POSIX Threads Library)
>> is the GNU C library POSIX threads implementation that is used on modern
>> Linux systems.
>> .\"
>> .SS NPTL and signals
>> NPTL makes internal use of the first two real-time signals
>> (signal numbers 32 and 33).
>> One of these signals is used to support thread cancellation and POSIX timers;
>> the other is used as part of a mechanism that ensures all threads in
>> a process always have the same UIDs and GIDs, as required by POSIX.
>> These signals cannot be used in applications.
>>
>> To prevent accidental use of these signals in applications,
>> which might interfere with the operation of the NPTL implementation,
>> various glibc library functions and system call wrapper functions
>> attempt to hide these signals from applications,
>> as follows:
>> .IP * 3
>> .B SIGRTMIN
>> is defined with the value 34 (rather than 32).
>> .IP *
>> The
>> .BR sigwaitinfo (2),
>> .BR sigtimedwait (2),
>> and
>> .BR sigwait (3)
>> interfaces silently ignore requests to wait for these two signals
>> if they are specified in the signal set argument of these calls.
>> .IP *
>> The
>> .BR sigprocmask (2)
>> and
>> .BR pthread_sigmask (3)
>> interfaces silently ignore attempts to block these two signals.
>> .IP *
>> The
>> .BR sigaction (2),
>> .BR pthread_kill (3),
>> and
>> .BR pthread_sigqueue (3)
>> interfaces fail with the error
>> .B EINVAL
>> (indicating an invalid signal number) if these signals are specified.
>> .IP *
>> .BR sigfillset (3)
>> does not include these two signals when it creates a full signal set.
>> .\"
> 
> are these abi details expected to be stable?
> (i'm not against documenting the existing
> implementation just curious if this is supposed
> to hold for all new archs)

I'm not sure, sorry.

> in theory for an application it is enough to know
> that it can only use the signals it can name and
> there might be implementation internal signals
> that cannot be masked (which might need to be taken
> into account when calculating a thread stack size).
> 
>> .SS NPTL and process credential changes
>> At the Linux kernel level,
>> credentials (user and group IDs) are a per-thread attribute.
>> However, POSIX requires that all of the POSIX threads in a process
>> have the same credentials.
>> To accommodate this requirement,
>> the NPTL implementation wraps all of the system calls that
>> change process credentials with functions that,
>> in addition to invoking the underlying system call,
>> arrange for all other threads in the process to also change their credentials.
>>
>> The implementation of each of these system calls involves the use of 
>> a real-time signal that is sent (using
>> .BR tgkill (2))
>> to each of the other threads that must change change its credentials.
>> Before sending these signals, the thread that is changing credentials
>> saves the new credential(s) and records the system call being employed
>> in a global buffer.
>> A signal handler in the receiving thread(s) fetches this information and
>> then uses the same system call to change its credentials.
>>
> 
> i think the situation described in
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=14749
> 
> might be worth documenting
> 
> vfork is not serialized wrt setxid functions

Do you have any proposed text for this? (In the meantime, I added a FIXME.)

> (but it would be better if the kernel got fixed
> to have a new set of posix setxid syscalls that
> change credentials atomically for the process)

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: nptl(7) man page

[Michael Kerrisk (man-pages)]

On 03/22/2015 10:38 PM, Nicholas Miell wrote:
> On 03/22/2015 07:38 AM, Michael Kerrisk (man-pages) wrote:
>> Hello all,
>>
>> I wrote a short man page documented some of the details of
>> NPTL that might affect application developers. Review comments
>> would be most welcome.
>>
>> Thanks,
>>
>> Michael
> 
> POSIX specifies that process-shared pthread_mutex_t's can be manipulated 
> by independent processes, however the AMD64 and i386 versions of the 
> mutex structures are incompatible and cannot be shared.
> 
> This might be true of the other supposedly sharable primitives, I never 
> bothered to check the rest when I first noticed the problem with mutexes.

Nicholas,

Can you provide pointers to further information on this topic?

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: nptl(7) man page

[Michael Kerrisk (man-pages)]

On 07/24/2015 05:51 PM, Nicholas Miell wrote:
> PTHREAD_PROCESS_SHARED says any thread with access to the memory containing
> the mutex can operate on the mutex and POSIX basically ignores the idea
> that different processes could be running completely incompatible
> executables or whatever.
> 
> pthread_mutex_t has a bunch of #ifdefs in the middle of it that change the
> structure size and layout between i386 and x86_64.
> 
> Most importantly, the positions of the __nusers and __kind fields are
> swapped (this looks to be an oversight dating back to 2003 when __nusers
> was first introduced and carefully preserved when the separate i386 and
> x86_64 versions of pthreadtypes.h were merged into the single x86 version),
> which means that when the lock and unlock functions attempt to figure out
> what kind of mutex it is (recursive/adaptive/whatever), they'll look at the
> wrong field if the mutex is from the wrong architecture and then things
> will break.
> 
> And then there's the fact that the rest of the struct is a union in the
> 32-bit version and flat in the 64-bit version, but that could have been
> worked around if you put a flag in the __kind field that tells the 64-bit
> pthread library that it is looking at a 32-bit mutex.

Thanks for the additional detail, Nicholas. So, how about a paragraph such 
as the following for the manual page:

       POSIX says that any thread in any process with access to the mem‐
       ory containing a  process-shared  (PTHREAD_PROCESS_SHARED)  mutex
       can  operate  on that mutex.  However, on 64-bit x86 systems, the
       mutex definition for x86-64 is incompatible with the mutex  defi‐
       nition  for  i386,  meaning that 32-bit and 64-bit binaries can't
       share mutexes on x86-64 systems.
?

Cheers,

Michael


> On Fri, Jul 24, 2015 at 12:57 AM, Michael Kerrisk (man-pages) <
> mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
>> On 03/22/2015 10:38 PM, Nicholas Miell wrote:
>>> On 03/22/2015 07:38 AM, Michael Kerrisk (man-pages) wrote:
>>>> Hello all,
>>>>
>>>> I wrote a short man page documented some of the details of
>>>> NPTL that might affect application developers. Review comments
>>>> would be most welcome.
>>>>
>>>> Thanks,
>>>>
>>>> Michael
>>>
>>> POSIX specifies that process-shared pthread_mutex_t's can be manipulated
>>> by independent processes, however the AMD64 and i386 versions of the
>>> mutex structures are incompatible and cannot be shared.
>>>
>>> This might be true of the other supposedly sharable primitives, I never
>>> bothered to check the rest when I first noticed the problem with mutexes.
>>
>> Nicholas,
>>
>> Can you provide pointers to further information on this topic?
>>
>> Cheers,
>>
>> Michael
>>
>>
>> --
>> Michael Kerrisk
>> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
>> Linux/UNIX System Programming Training: http://man7.org/training/
>>
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: nptl(7) man page

[Nicholas Miell]

Sounds good.

On Sun, Jul 26, 2015 at 1:24 PM, Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
> On 07/24/2015 05:51 PM, Nicholas Miell wrote:
>> PTHREAD_PROCESS_SHARED says any thread with access to the memory containing
>> the mutex can operate on the mutex and POSIX basically ignores the idea
>> that different processes could be running completely incompatible
>> executables or whatever.
>>
>> pthread_mutex_t has a bunch of #ifdefs in the middle of it that change the
>> structure size and layout between i386 and x86_64.
>>
>> Most importantly, the positions of the __nusers and __kind fields are
>> swapped (this looks to be an oversight dating back to 2003 when __nusers
>> was first introduced and carefully preserved when the separate i386 and
>> x86_64 versions of pthreadtypes.h were merged into the single x86 version),
>> which means that when the lock and unlock functions attempt to figure out
>> what kind of mutex it is (recursive/adaptive/whatever), they'll look at the
>> wrong field if the mutex is from the wrong architecture and then things
>> will break.
>>
>> And then there's the fact that the rest of the struct is a union in the
>> 32-bit version and flat in the 64-bit version, but that could have been
>> worked around if you put a flag in the __kind field that tells the 64-bit
>> pthread library that it is looking at a 32-bit mutex.
>
> Thanks for the additional detail, Nicholas. So, how about a paragraph such
> as the following for the manual page:
>
>        POSIX says that any thread in any process with access to the mem‐
>        ory containing a  process-shared  (PTHREAD_PROCESS_SHARED)  mutex
>        can  operate  on that mutex.  However, on 64-bit x86 systems, the
>        mutex definition for x86-64 is incompatible with the mutex  defi‐
>        nition  for  i386,  meaning that 32-bit and 64-bit binaries can't
>        share mutexes on x86-64 systems.
> ?
>
> Cheers,
>
> Michael
>
>
>> On Fri, Jul 24, 2015 at 12:57 AM, Michael Kerrisk (man-pages) <
>> mtk.manpages@gmail.com> wrote:
>>
>>> On 03/22/2015 10:38 PM, Nicholas Miell wrote:
>>>> On 03/22/2015 07:38 AM, Michael Kerrisk (man-pages) wrote:
>>>>> Hello all,
>>>>>
>>>>> I wrote a short man page documented some of the details of
>>>>> NPTL that might affect application developers. Review comments
>>>>> would be most welcome.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Michael
>>>>
>>>> POSIX specifies that process-shared pthread_mutex_t's can be manipulated
>>>> by independent processes, however the AMD64 and i386 versions of the
>>>> mutex structures are incompatible and cannot be shared.
>>>>
>>>> This might be true of the other supposedly sharable primitives, I never
>>>> bothered to check the rest when I first noticed the problem with mutexes.
>>>
>>> Nicholas,
>>>
>>> Can you provide pointers to further information on this topic?
>>>
>>> Cheers,
>>>
>>> Michael
>>>
>>>
>>> --
>>> Michael Kerrisk
>>> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
>>> Linux/UNIX System Programming Training: http://man7.org/training/
>>>
>>
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/

Re: For review: nptl(7) man page

[Michael Kerrisk (man-pages)]

On 07/26/2015 10:27 PM, Nicholas Miell wrote:
> Sounds good.

That was quick! Thanks for checking, and thanks for the report, Nicholas!

Cheers,

Michael


> On Sun, Jul 26, 2015 at 1:24 PM, Michael Kerrisk (man-pages)
> <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 07/24/2015 05:51 PM, Nicholas Miell wrote:
>>> PTHREAD_PROCESS_SHARED says any thread with access to the memory containing
>>> the mutex can operate on the mutex and POSIX basically ignores the idea
>>> that different processes could be running completely incompatible
>>> executables or whatever.
>>>
>>> pthread_mutex_t has a bunch of #ifdefs in the middle of it that change the
>>> structure size and layout between i386 and x86_64.
>>>
>>> Most importantly, the positions of the __nusers and __kind fields are
>>> swapped (this looks to be an oversight dating back to 2003 when __nusers
>>> was first introduced and carefully preserved when the separate i386 and
>>> x86_64 versions of pthreadtypes.h were merged into the single x86 version),
>>> which means that when the lock and unlock functions attempt to figure out
>>> what kind of mutex it is (recursive/adaptive/whatever), they'll look at the
>>> wrong field if the mutex is from the wrong architecture and then things
>>> will break.
>>>
>>> And then there's the fact that the rest of the struct is a union in the
>>> 32-bit version and flat in the 64-bit version, but that could have been
>>> worked around if you put a flag in the __kind field that tells the 64-bit
>>> pthread library that it is looking at a 32-bit mutex.
>>
>> Thanks for the additional detail, Nicholas. So, how about a paragraph such
>> as the following for the manual page:
>>
>>        POSIX says that any thread in any process with access to the mem‐
>>        ory containing a  process-shared  (PTHREAD_PROCESS_SHARED)  mutex
>>        can  operate  on that mutex.  However, on 64-bit x86 systems, the
>>        mutex definition for x86-64 is incompatible with the mutex  defi‐
>>        nition  for  i386,  meaning that 32-bit and 64-bit binaries can't
>>        share mutexes on x86-64 systems.
>> ?
>>
>> Cheers,
>>
>> Michael
>>
>>
>>> On Fri, Jul 24, 2015 at 12:57 AM, Michael Kerrisk (man-pages) <
>>> mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>
>>>> On 03/22/2015 10:38 PM, Nicholas Miell wrote:
>>>>> On 03/22/2015 07:38 AM, Michael Kerrisk (man-pages) wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> I wrote a short man page documented some of the details of
>>>>>> NPTL that might affect application developers. Review comments
>>>>>> would be most welcome.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Michael
>>>>>
>>>>> POSIX specifies that process-shared pthread_mutex_t's can be manipulated
>>>>> by independent processes, however the AMD64 and i386 versions of the
>>>>> mutex structures are incompatible and cannot be shared.
>>>>>
>>>>> This might be true of the other supposedly sharable primitives, I never
>>>>> bothered to check the rest when I first noticed the problem with mutexes.
>>>>
>>>> Nicholas,
>>>>
>>>> Can you provide pointers to further information on this topic?
>>>>
>>>> Cheers,
>>>>
>>>> Michael
>>>>
>>>>
>>>> --
>>>> Michael Kerrisk
>>>> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
>>>> Linux/UNIX System Programming Training: http://man7.org/training/
>>>>
>>>
>>
>>
>> --
>> Michael Kerrisk
>> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
>> Linux/UNIX System Programming Training: http://man7.org/training/
> 


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: nptl(7) man page

[Torvald Riegel]

On Sun, 2015-07-26 at 22:24 +0200, Michael Kerrisk (man-pages) wrote:
> On 07/24/2015 05:51 PM, Nicholas Miell wrote:
> > PTHREAD_PROCESS_SHARED says any thread with access to the memory containing
> > the mutex can operate on the mutex and POSIX basically ignores the idea
> > that different processes could be running completely incompatible
> > executables or whatever.
> > 
> > pthread_mutex_t has a bunch of #ifdefs in the middle of it that change the
> > structure size and layout between i386 and x86_64.
> > 
> > Most importantly, the positions of the __nusers and __kind fields are
> > swapped (this looks to be an oversight dating back to 2003 when __nusers
> > was first introduced and carefully preserved when the separate i386 and
> > x86_64 versions of pthreadtypes.h were merged into the single x86 version),
> > which means that when the lock and unlock functions attempt to figure out
> > what kind of mutex it is (recursive/adaptive/whatever), they'll look at the
> > wrong field if the mutex is from the wrong architecture and then things
> > will break.
> > 
> > And then there's the fact that the rest of the struct is a union in the
> > 32-bit version and flat in the 64-bit version, but that could have been
> > worked around if you put a flag in the __kind field that tells the 64-bit
> > pthread library that it is looking at a 32-bit mutex.
> 
> Thanks for the additional detail, Nicholas. So, how about a paragraph such 
> as the following for the manual page:
> 
>        POSIX says that any thread in any process with access to the mem‐
>        ory containing a  process-shared  (PTHREAD_PROCESS_SHARED)  mutex
>        can  operate  on that mutex.  However, on 64-bit x86 systems, the
>        mutex definition for x86-64 is incompatible with the mutex  defi‐
>        nition  for  i386,  meaning that 32-bit and 64-bit binaries can't
>        share mutexes on x86-64 systems.

In general, I don't think we promise that one can use share
PTHREAD_PROCESS_SHARED data structures between processes that do not use
the same glibc.  A 32b glibc build and an x86_64 build will differ
(e.g., the new semaphore implemenation uses a different algorithm if 64b
atomic operations are available instead of just 32b ones).  The sizes
and aligment of the data structures are ABI, but I do not believe that
the way in that glibc uses those bits is part of the ABI too.

However, I haven't checked whether POSIX makes any statements about this
situation.

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: nptl(7) man page

[Rich Felker]

On Mon, Aug 03, 2015 at 05:45:40PM +0200, Torvald Riegel wrote:
> On Sun, 2015-07-26 at 22:24 +0200, Michael Kerrisk (man-pages) wrote:
> > On 07/24/2015 05:51 PM, Nicholas Miell wrote:
> > > PTHREAD_PROCESS_SHARED says any thread with access to the memory containing
> > > the mutex can operate on the mutex and POSIX basically ignores the idea
> > > that different processes could be running completely incompatible
> > > executables or whatever.
> > > 
> > > pthread_mutex_t has a bunch of #ifdefs in the middle of it that change the
> > > structure size and layout between i386 and x86_64.
> > > 
> > > Most importantly, the positions of the __nusers and __kind fields are
> > > swapped (this looks to be an oversight dating back to 2003 when __nusers
> > > was first introduced and carefully preserved when the separate i386 and
> > > x86_64 versions of pthreadtypes.h were merged into the single x86 version),
> > > which means that when the lock and unlock functions attempt to figure out
> > > what kind of mutex it is (recursive/adaptive/whatever), they'll look at the
> > > wrong field if the mutex is from the wrong architecture and then things
> > > will break.
> > > 
> > > And then there's the fact that the rest of the struct is a union in the
> > > 32-bit version and flat in the 64-bit version, but that could have been
> > > worked around if you put a flag in the __kind field that tells the 64-bit
> > > pthread library that it is looking at a 32-bit mutex.
> > 
> > Thanks for the additional detail, Nicholas. So, how about a paragraph such 
> > as the following for the manual page:
> > 
> >        POSIX says that any thread in any process with access to the mem‐
> >        ory containing a  process-shared  (PTHREAD_PROCESS_SHARED)  mutex
> >        can  operate  on that mutex.  However, on 64-bit x86 systems, the
> >        mutex definition for x86-64 is incompatible with the mutex  defi‐
> >        nition  for  i386,  meaning that 32-bit and 64-bit binaries can't
> >        share mutexes on x86-64 systems.
> 
> In general, I don't think we promise that one can use share
> PTHREAD_PROCESS_SHARED data structures between processes that do not use
> the same glibc.  A 32b glibc build and an x86_64 build will differ
> (e.g., the new semaphore implemenation uses a different algorithm if 64b
> atomic operations are available instead of just 32b ones).  The sizes
> and aligment of the data structures are ABI, but I do not believe that
> the way in that glibc uses those bits is part of the ABI too.
> 
> However, I haven't checked whether POSIX makes any statements about this
> situation.

It doesn't directly. If you consider the models as two separate
"compilation environments"/"execution environments" of the same
implementation, then it would at least be within the scope of POSIX to
have something to say about it. On the other hand if you consider them
as completely separate implementations that just happen to run (as
foreign binaries) on the same logical/physical machine, it's well
outside the scope of POSIX whether this works.

Rich

Re: For review: nptl(7) man page

[Roland McGrath]

> It doesn't directly. If you consider the models as two separate
> "compilation environments"/"execution environments" of the same
> implementation, then it would at least be within the scope of POSIX to
> have something to say about it. 

I think we are asserting that they are exactly that by dint of the confstr
results for _CS_POSIX_V7_ILP32_OFF32_CFLAGS et al.  So the question is what
POSIX actually does or doesn't say about process-shared synchronization
objects being shared between processes running programs built in different
POSIX compilation environments.

The other relevant question is whether 32/64 sharing of each particular
pshared object has in fact worked reliably under glibc in the past.  Since
we haven't been clear and explicit about the subject before AFAIK, then if
in fact it worked before then people might well have inferred that we made
such an ABI guarantee.  (I hope not, since if so we just broke it.)

Re: For review: nptl(7) man page

[Nicholas Miell]

On Aug 4, 2015, at 8:06 AM, Roland McGrath <roland-/Z5OmTQCD9xF6kxbq+BtvQ@public.gmane.org> wrote:

> I think we are asserting that they are exactly that by dint of the confstr
> results for _CS_POSIX_V7_ILP32_OFF32_CFLAGS et al.  So the question is what
> POSIX actually does or doesn't say about process-shared synchronization
> objects being shared between processes running programs built in different
> POSIX compilation environments.
> 
> The other relevant question is whether 32/64 sharing of each particular
> pshared object has in fact worked reliably under glibc in the past.  Since
> we haven't been clear and explicit about the subject before AFAIK, then if
> in fact it worked before then people might well have inferred that we made
> such an ABI guarantee.  (I hope not, since if so we just broke it.)

The relevant questions aren't what's the least useful behavior that POSIX lets us get away with or can we leave it broken because it never worked;'the questions are what do the other operating systems do and what do the users want. 

IIRC, the first I ever heard of this issue was Keith Packard complaining that he couldn't put a mutex in shared memory because then 32-bit X clients couldn't talk to a 64-bit X server and it was too bad it didn't work on Linux because it does work on Solaris. --
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: nptl(7) man page

[Torvald Riegel]

On Tue, 2015-08-04 at 11:50 -0700, Nicholas Miell wrote:
> On Aug 4, 2015, at 8:06 AM, Roland McGrath <roland-/Z5OmTQCD9xF6kxbq+BtvQ@public.gmane.org> wrote:
> 
> > I think we are asserting that they are exactly that by dint of the confstr
> > results for _CS_POSIX_V7_ILP32_OFF32_CFLAGS et al.  So the question is what
> > POSIX actually does or doesn't say about process-shared synchronization
> > objects being shared between processes running programs built in different
> > POSIX compilation environments.
> > 
> > The other relevant question is whether 32/64 sharing of each particular
> > pshared object has in fact worked reliably under glibc in the past.  Since
> > we haven't been clear and explicit about the subject before AFAIK, then if
> > in fact it worked before then people might well have inferred that we made
> > such an ABI guarantee.  (I hope not, since if so we just broke it.)
> 
> The relevant questions aren't what's the least useful behavior that POSIX lets us get away with or can we leave it broken because it never worked;'the questions are what do the other operating systems do and what do the users want. 

Those are relevant questions, but they are not the only relevant ones.
Some users would also like to share data structures between processes
using different glibc builds (eg, different versions), and we won't
promise that this works for obvioius reasons.

The semaphore example shows that there can be a disadvantage to
guaranteeing 32/64b interoperability (specifically, the 64b code is more
efficient).  For mutex, I *currently* don't see a reason why we couldn't
get away with just doing 32b stuff for the pshared case, but there's no
guarantee that I can foresee all future needs either.

Thus, if we would decide to guarantee 32/64b interoperability, we'd need
to have at least strong use cases for that and a decent amount of
confidence that making such a guarantee is unlikely to constrain the
implementation in the future.


--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: nptl(7) man page

[Nicholas Miell]

> On Aug 5, 2015, at 2:36 AM, Torvald Riegel <triegel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> 
>> On Tue, 2015-08-04 at 11:50 -0700, Nicholas Miell wrote:
>>> On Aug 4, 2015, at 8:06 AM, Roland McGrath <roland-/Z5OmTQCD9xF6kxbq+BtvQ@public.gmane.org> wrote:
>>> 
>>> I think we are asserting that they are exactly that by dint of the confstr
>>> results for _CS_POSIX_V7_ILP32_OFF32_CFLAGS et al.  So the question is what
>>> POSIX actually does or doesn't say about process-shared synchronization
>>> objects being shared between processes running programs built in different
>>> POSIX compilation environments.
>>> 
>>> The other relevant question is whether 32/64 sharing of each particular
>>> pshared object has in fact worked reliably under glibc in the past.  Since
>>> we haven't been clear and explicit about the subject before AFAIK, then if
>>> in fact it worked before then people might well have inferred that we made
>>> such an ABI guarantee.  (I hope not, since if so we just broke it.)
>> 
>> The relevant questions aren't what's the least useful behavior that POSIX lets us get away with or can we leave it broken because it never worked;'the questions are what do the other operating systems do and what do the users want.
> 
> Those are relevant questions, but they are not the only relevant ones.
> Some users would also like to share data structures between processes
> using different glibc builds (eg, different versions), and we won't
> promise that this works for obvioius reasons.

The reasonable scenario is what we have right now -- 32 and 64-bit versions of glibc built from the exact same git commit. And I'd exclude static versions of glibc even if they're the same version. 

> The semaphore example shows that there can be a disadvantage to
> guaranteeing 32/64b interoperability (specifically, the 64b code is more
> efficient).  For mutex, I *currently* don't see a reason why we couldn't
> get away with just doing 32b stuff for the pshared case, but there's no
> guarantee that I can foresee all future needs either.
> 
> Thus, if we would decide to guarantee 32/64b interoperability, we'd need
> to have at least strong use cases for that and a decent amount of
> confidence that making such a guarantee is unlikely to constrain the
> implementation in the future.
> 

Well, POSIX semaphores are supposed to be a replacement for System V semaphores (and this extends to the rest of the POSIX IPC primitives); right now they aren't.--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: nptl(7) man page

[Rich Felker]

On Wed, Aug 05, 2015 at 11:14:32AM -0700, Nicholas Miell wrote:
> 
> 
> > On Aug 5, 2015, at 2:36 AM, Torvald Riegel <triegel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > 
> >> On Tue, 2015-08-04 at 11:50 -0700, Nicholas Miell wrote:
> >>> On Aug 4, 2015, at 8:06 AM, Roland McGrath <roland-/Z5OmTQCD9xF6kxbq+BtvQ@public.gmane.org> wrote:
> >>> 
> >>> I think we are asserting that they are exactly that by dint of the confstr
> >>> results for _CS_POSIX_V7_ILP32_OFF32_CFLAGS et al.  So the question is what
> >>> POSIX actually does or doesn't say about process-shared synchronization
> >>> objects being shared between processes running programs built in different
> >>> POSIX compilation environments.
> >>> 
> >>> The other relevant question is whether 32/64 sharing of each particular
> >>> pshared object has in fact worked reliably under glibc in the past.  Since
> >>> we haven't been clear and explicit about the subject before AFAIK, then if
> >>> in fact it worked before then people might well have inferred that we made
> >>> such an ABI guarantee.  (I hope not, since if so we just broke it.)
> >> 
> >> The relevant questions aren't what's the least useful behavior
> >> that POSIX lets us get away with or can we leave it broken
> >> because it never worked;'the questions are what do the other
> >> operating systems do and what do the users want.
> > 
> > Those are relevant questions, but they are not the only relevant ones.
> > Some users would also like to share data structures between processes
> > using different glibc builds (eg, different versions), and we won't
> > promise that this works for obvioius reasons.
> 
> The reasonable scenario is what we have right now -- 32 and 64-bit
> versions of glibc built from the exact same git commit. And I'd
> exclude static versions of glibc even if they're the same version.

Why would you exclude static? IMO two static-linked executables using
the same version of glibc should be compatible with each other even if
you don't want to guarantee they'll be compatible with the
same-version shared glibc.

> > The semaphore example shows that there can be a disadvantage to
> > guaranteeing 32/64b interoperability (specifically, the 64b code is more
> > efficient).  For mutex, I *currently* don't see a reason why we couldn't
> > get away with just doing 32b stuff for the pshared case, but there's no
> > guarantee that I can foresee all future needs either.
> > 
> > Thus, if we would decide to guarantee 32/64b interoperability, we'd need
> > to have at least strong use cases for that and a decent amount of
> > confidence that making such a guarantee is unlikely to constrain the
> > implementation in the future.
> 
> Well, POSIX semaphores are supposed to be a replacement for System V
> semaphores (and this extends to the rest of the POSIX IPC
> primitives); right now they aren't.

Only for some usage cases. As far as I can tell, POSIX semaphores are
not intended to be required to be implemented as a kernel resource.
They don't have permissions enforcement/safety against malicious
processes, backout on async process termination, etc.

Rich
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: nptl(7) man page

[Michael Kerrisk (man-pages)]

On 08/05/2015 08:23 PM, Rich Felker wrote:
> On Wed, Aug 05, 2015 at 11:14:32AM -0700, Nicholas Miell wrote:
>>
>>
>>> On Aug 5, 2015, at 2:36 AM, Torvald Riegel <triegel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>>
>>>> On Tue, 2015-08-04 at 11:50 -0700, Nicholas Miell wrote:
>>>>> On Aug 4, 2015, at 8:06 AM, Roland McGrath <roland-/Z5OmTQCD9xF6kxbq+BtvQ@public.gmane.org> wrote:
>>>>>
>>>>> I think we are asserting that they are exactly that by dint of the confstr
>>>>> results for _CS_POSIX_V7_ILP32_OFF32_CFLAGS et al.  So the question is what
>>>>> POSIX actually does or doesn't say about process-shared synchronization
>>>>> objects being shared between processes running programs built in different
>>>>> POSIX compilation environments.
>>>>>
>>>>> The other relevant question is whether 32/64 sharing of each particular
>>>>> pshared object has in fact worked reliably under glibc in the past.  Since
>>>>> we haven't been clear and explicit about the subject before AFAIK, then if
>>>>> in fact it worked before then people might well have inferred that we made
>>>>> such an ABI guarantee.  (I hope not, since if so we just broke it.)
>>>>
>>>> The relevant questions aren't what's the least useful behavior
>>>> that POSIX lets us get away with or can we leave it broken
>>>> because it never worked;'the questions are what do the other
>>>> operating systems do and what do the users want.
>>>
>>> Those are relevant questions, but they are not the only relevant ones.
>>> Some users would also like to share data structures between processes
>>> using different glibc builds (eg, different versions), and we won't
>>> promise that this works for obvioius reasons.
>>
>> The reasonable scenario is what we have right now -- 32 and 64-bit
>> versions of glibc built from the exact same git commit. And I'd
>> exclude static versions of glibc even if they're the same version.
> 
> Why would you exclude static? IMO two static-linked executables using
> the same version of glibc should be compatible with each other even if
> you don't want to guarantee they'll be compatible with the
> same-version shared glibc.
> 
>>> The semaphore example shows that there can be a disadvantage to
>>> guaranteeing 32/64b interoperability (specifically, the 64b code is more
>>> efficient).  For mutex, I *currently* don't see a reason why we couldn't
>>> get away with just doing 32b stuff for the pshared case, but there's no
>>> guarantee that I can foresee all future needs either.
>>>
>>> Thus, if we would decide to guarantee 32/64b interoperability, we'd need
>>> to have at least strong use cases for that and a decent amount of
>>> confidence that making such a guarantee is unlikely to constrain the
>>> implementation in the future.
>>
>> Well, POSIX semaphores are supposed to be a replacement for System V
>> semaphores (and this extends to the rest of the POSIX IPC
>> primitives); right now they aren't.
> 
> Only for some usage cases. As far as I can tell, POSIX semaphores are
> not intended to be required to be implemented as a kernel resource.

That last is also true of SysV semaphores, surely?

> They don't have permissions enforcement/safety against malicious
> processes, 

(I'm a little lost here. POSIX semaphores do have a permissions mask.)

>  backout on async process termination, etc.

Actually, System V semaphores don't reliably have this either (see BUGS
in semop(2)).

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: nptl(7) man page

[Rich Felker]

On Wed, Aug 05, 2015 at 08:59:55PM +0200, Michael Kerrisk (man-pages) wrote:
> >>> The semaphore example shows that there can be a disadvantage to
> >>> guaranteeing 32/64b interoperability (specifically, the 64b code is more
> >>> efficient).  For mutex, I *currently* don't see a reason why we couldn't
> >>> get away with just doing 32b stuff for the pshared case, but there's no
> >>> guarantee that I can foresee all future needs either.
> >>>
> >>> Thus, if we would decide to guarantee 32/64b interoperability, we'd need
> >>> to have at least strong use cases for that and a decent amount of
> >>> confidence that making such a guarantee is unlikely to constrain the
> >>> implementation in the future.
> >>
> >> Well, POSIX semaphores are supposed to be a replacement for System V
> >> semaphores (and this extends to the rest of the POSIX IPC
> >> primitives); right now they aren't.
> > 
> > Only for some usage cases. As far as I can tell, POSIX semaphores are
> > not intended to be required to be implemented as a kernel resource.
> 
> That last is also true of SysV semaphores, surely?

The grammar of my sentence was rather complicated and perhaps
confusing. The intent was to say that SysV semaphores absolutely have
to be a kernel resource, but POSIX semaphores don't (and aren't).

> > They don't have permissions enforcement/safety against malicious
> > processes, 
> 
> (I'm a little lost here. POSIX semaphores do have a permissions mask.)

Yes, named semaphores have fs-like permissions, and of course you can
do that with unnamed ones in named shared memory objects or files.
However, as implemented in the real world, that provides no protection
from a malicious process that _does_ have access permissions. With SysV
semaphores, the worst a malicious process with access can do is
wait/post the semaphore. With current implementations of POSIX
semaphores, and other process-shared pthread sync objects, a malicious
process that has access can utterly corrupt the state of the object. I
am not sure of the extent of damage that can be achieved here, but
there is not explicit effort to harden against it.

> >  backout on async process termination, etc.
> 
> Actually, System V semaphores don't reliably have this either (see BUGS
> in semop(2)).

That's something of a design bug, but irrelevant to the reasonable
usage which would be to post, not wait.

Rich
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: For review: nptl(7) man page

[Michael Kerrisk (man-pages)]

On 08/05/2015 09:46 PM, Rich Felker wrote:
> On Wed, Aug 05, 2015 at 08:59:55PM +0200, Michael Kerrisk (man-pages) wrote:
>>>>> The semaphore example shows that there can be a disadvantage to
>>>>> guaranteeing 32/64b interoperability (specifically, the 64b code is more
>>>>> efficient).  For mutex, I *currently* don't see a reason why we couldn't
>>>>> get away with just doing 32b stuff for the pshared case, but there's no
>>>>> guarantee that I can foresee all future needs either.
>>>>>
>>>>> Thus, if we would decide to guarantee 32/64b interoperability, we'd need
>>>>> to have at least strong use cases for that and a decent amount of
>>>>> confidence that making such a guarantee is unlikely to constrain the
>>>>> implementation in the future.
>>>>
>>>> Well, POSIX semaphores are supposed to be a replacement for System V
>>>> semaphores (and this extends to the rest of the POSIX IPC
>>>> primitives); right now they aren't.
>>>
>>> Only for some usage cases. As far as I can tell, POSIX semaphores are
>>> not intended to be required to be implemented as a kernel resource.
>>
>> That last is also true of SysV semaphores, surely?
> 
> The grammar of my sentence was rather complicated and perhaps
> confusing. The intent was to say that SysV semaphores absolutely have
> to be a kernel resource, but POSIX semaphores don't (and aren't).

I'm still puzzled. POSIX certainly doesn't make any requirements here.
So who does or doesn't "require" this? Also, I am not sure of the
distinction you're trying to make here. In the Linux implementation of
POSIX semaphores, kernel involvement is required in the contended case.

>>> They don't have permissions enforcement/safety against malicious
>>> processes, 
>>
>> (I'm a little lost here. POSIX semaphores do have a permissions mask.)
> 
> Yes, named semaphores have fs-like permissions, and of course you can
> do that with unnamed ones in named shared memory objects or files.
> However, as implemented in the real world, that provides no protection
> from a malicious process that _does_ have access permissions. With SysV
> semaphores, the worst a malicious process with access can do is
> wait/post the semaphore. With current implementations of POSIX
> semaphores, and other process-shared pthread sync objects, a malicious
> process that has access can utterly corrupt the state of the object. I
> am not sure of the extent of damage that can be achieved here, but
> there is not explicit effort to harden against it.

Again, I'm clear on the distinction here. By "corrupted", I assume
you're talking about (say) directly opening the SHM object used
to implement the semaphore and tweaking bits arbitrarily.
But, if someone can wait/post maliciously, you're pretty much
hosed anyway.

>>>  backout on async process termination, etc.
>>
>> Actually, System V semaphores don't reliably have this either (see BUGS
>> in semop(2)).
> 
> That's something of a design bug, but irrelevant to the reasonable
> usage which would be to post, not wait.

Why is that the only reasonable usage? 

It totally depends on the design of the sync protocol that you're
layering on top of SysV semaphores. SEM_UNDO is a fundamentally
broken concept, AFAICS.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: For review: nptl(7) man page

[Rich Felker]

On Thu, Aug 06, 2015 at 12:06:18PM +0200, Michael Kerrisk (man-pages) wrote:
> On 08/05/2015 09:46 PM, Rich Felker wrote:
> > On Wed, Aug 05, 2015 at 08:59:55PM +0200, Michael Kerrisk (man-pages) wrote:
> >>>>> The semaphore example shows that there can be a disadvantage to
> >>>>> guaranteeing 32/64b interoperability (specifically, the 64b code is more
> >>>>> efficient).  For mutex, I *currently* don't see a reason why we couldn't
> >>>>> get away with just doing 32b stuff for the pshared case, but there's no
> >>>>> guarantee that I can foresee all future needs either.
> >>>>>
> >>>>> Thus, if we would decide to guarantee 32/64b interoperability, we'd need
> >>>>> to have at least strong use cases for that and a decent amount of
> >>>>> confidence that making such a guarantee is unlikely to constrain the
> >>>>> implementation in the future.
> >>>>
> >>>> Well, POSIX semaphores are supposed to be a replacement for System V
> >>>> semaphores (and this extends to the rest of the POSIX IPC
> >>>> primitives); right now they aren't.
> >>>
> >>> Only for some usage cases. As far as I can tell, POSIX semaphores are
> >>> not intended to be required to be implemented as a kernel resource.
> >>
> >> That last is also true of SysV semaphores, surely?
> > 
> > The grammar of my sentence was rather complicated and perhaps
> > confusing. The intent was to say that SysV semaphores absolutely have
> > to be a kernel resource, but POSIX semaphores don't (and aren't).
> 
> I'm still puzzled. POSIX certainly doesn't make any requirements here.
> So who does or doesn't "require" this? Also, I am not sure of the
> distinction you're trying to make here. In the Linux implementation of
> POSIX semaphores, kernel involvement is required in the contended case.

The back-out feature of SysV semaphores does not admit a userspace
implementation as far as I can tell. Certainly the killed process
itself can't change the state of the semaphore at exit time, so the
next thread to try to access it would have to see that a process with
SEM_UNDO records died and process them. But that would take
arbitrarily large storage in the semaphore object, and would have
other issues.

> >>> They don't have permissions enforcement/safety against malicious
> >>> processes, 
> >>
> >> (I'm a little lost here. POSIX semaphores do have a permissions mask.)
> > 
> > Yes, named semaphores have fs-like permissions, and of course you can
> > do that with unnamed ones in named shared memory objects or files.
> > However, as implemented in the real world, that provides no protection
> > from a malicious process that _does_ have access permissions. With SysV
> > semaphores, the worst a malicious process with access can do is
> > wait/post the semaphore. With current implementations of POSIX
> > semaphores, and other process-shared pthread sync objects, a malicious
> > process that has access can utterly corrupt the state of the object. I
> > am not sure of the extent of damage that can be achieved here, but
> > there is not explicit effort to harden against it.
> 
> Again, I'm clear on the distinction here. By "corrupted", I assume
> you're talking about (say) directly opening the SHM object used
> to implement the semaphore and tweaking bits arbitrarily.
> But, if someone can wait/post maliciously, you're pretty much
> hosed anyway.

sem_open followed by poking at the pointed-to bits should suffice; no
"more direct" open is needed. The scope of the damage will depend on
the implementation and the memory model, but a claim that it's not
more dangerous that malicious wait/post is nontrivial and would
require some work to prove.

With other pshared objects the impact is definitely much worse. For
example a robust mutex participates in a linked list local to the
process/thread that owns it. By overwriting the prev/next pointers
while a victim thread holds the lock, you could cause arbitrary memory
clobbering in the victim process when it goes to unlock.

> >>>  backout on async process termination, etc.
> >>
> >> Actually, System V semaphores don't reliably have this either (see BUGS
> >> in semop(2)).
> > 
> > That's something of a design bug, but irrelevant to the reasonable
> > usage which would be to post, not wait.
> 
> Why is that the only reasonable usage? 
> 
> It totally depends on the design of the sync protocol that you're
> layering on top of SysV semaphores. SEM_UNDO is a fundamentally
> broken concept, AFAICS.

My claim is that it's "fundamentally broken" only for certain usage
cases that are not the ones I would expect to arise in practice.

Rich
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html