Bug 99901

Summary: iopl is lost on fork and execve
Product: Documentation Reporter: Alex Henrie (alexhenrie24)
Component: man-pagesAssignee: documentation_man-pages (documentation_man-pages)
Status: RESOLVED CODE_FIX    
Severity: normal CC: mtk.manpages
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: Subsystem:
Regression: No Bisected commit-id:
Attachments: iopl3 test program

Description Alex Henrie 2015-06-13 17:36:08 UTC 
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]

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
Comment 1 Michael Kerrisk 2015-06-16 09:48:09 UTC 
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
Comment 2 Michael Kerrisk 2016-03-15 03:37:16 UTC 
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),