[Bug 99901] New: iopl is lost on fork and execve

[Bug 99901] New: iopl is lost on fork and execve

[bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r]

https://bugzilla.kernel.org/show_bug.cgi?id=99901

            Bug ID: 99901
           Summary: iopl is lost on fork and execve
           Product: Documentation
           Version: unspecified
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P1
         Component: man-pages
          Assignee: documentation_man-pages-ztI5WcYan/vQLgFONoPN62D2FQJk+8+b@public.gmane.org
          Reporter: alexhenrie24-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
        Regression: No

Created attachment 179841
  --> https://bugzilla.kernel.org/attachment.cgi?id=179841&action=edit
iopl3 test program

`man iopl` currently states "Permissions are inherited by fork(2) and
execve(2)." This is not true. iopl has never been preserved across fork or
execve on x64 kernels,[1] and it has not been preserved across those syscalls
on x86 kernels since Linux 3.7.[2] There are no plans to change the current
behavior for either architecture.[3-6]

A test program to demonstrate this behavior is attached.

[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/process_64.c
[2]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86/kernel/process_32.c?id=6783eaa2e1253fbcbe2c2f6bb4c843abf1343caf
[3] https://lkml.org/lkml/2015/5/11/1054
[4] https://lkml.org/lkml/2015/5/12/55
[5] https://lkml.org/lkml/2015/5/12/537
[6] https://lkml.org/lkml/2015/5/12/545

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
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

[Bug 99901] iopl is lost on fork and execve

[bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r]

https://bugzilla.kernel.org/show_bug.cgi?id=99901

Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

--- Comment #1 from Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> ---
Alex,

Thanks for this report and also for
https://bugzilla.kernel.org/show_bug.cgi?id=99911
I recall seeing your mailing list discussions on this and had been meaning to
follow up.

(In reply to Alex Henrie from comment #0)
> Created attachment 179841 [details]
> iopl3 test program
> 
> `man iopl` currently states "Permissions are inherited by fork(2) and
> execve(2)." This is not true. iopl has never been preserved across fork or
> execve on x64 kernels,[1] and it has not been preserved across those
> syscalls on x86 kernels since Linux 3.7.[2] There are no plans to change the
> current behavior for either architecture.[3-6]

Okay -- I'll come up with some man page text, but first I have a question in
the other bug.

Cheers,

Michael


> 
> A test program to demonstrate this behavior is attached.
> 
> [1]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/
> x86/kernel/process_64.c
> [2]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/
> x86/kernel/process_32.c?id=6783eaa2e1253fbcbe2c2f6bb4c843abf1343caf
> [3] https://lkml.org/lkml/2015/5/11/1054
> [4] https://lkml.org/lkml/2015/5/12/55
> [5] https://lkml.org/lkml/2015/5/12/537
> [6] https://lkml.org/lkml/2015/5/12/545

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
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

[Bug 99901] iopl is lost on fork and execve

[bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r]

https://bugzilla.kernel.org/show_bug.cgi?id=99901

Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |CODE_FIX

--- Comment #2 from Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> ---
Alex, sorry for the long delay in following up.

I have applied the patch below. Closing this bug.

Cheers,

Michael

diff --git a/man2/iopl.2 b/man2/iopl.2
index 93dca3f..86f5242 100644
--- a/man2/iopl.2
+++ b/man2/iopl.2
@@ -53,10 +53,11 @@ In addition to granting unrestricted I/O port access,
running at a higher
 I/O privilege level also allows the process to disable interrupts.
 This will probably crash the system, and is not recommended.

-Permissions are inherited by
+Permissions are not inherited by the child process created by
 .BR fork (2)
-and
-.BR execve (2).
+and are not preserved across
+.BR execve (2)
+(but see NOTES).

 The I/O privilege level for a normal process is 0.

@@ -97,6 +98,16 @@ Glibc2 has a prototype both in
 and in
 .IR <sys/perm.h> .
 Avoid the latter, it is available on i386 only.
+
+Prior to Linux 3.7,
+on some architectures (such as i386), permissions
+.I were
+inherited by the child produced by
+.BR fork (2)
+and were preserved across
+.BR execve (2).
+This behavior was inadvertently changed in Linux 3.7,
+and won't be reinstated.
 .SH SEE ALSO
 .BR ioperm (2),
 .BR outb (2),

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
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