New: iopl is lost on fork and execve
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/[email protected]
Reporter: [email protected]
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
Signature · 6 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 99901] iopl is lost on fork and execve
In reply to a message not in the archivehttps://bugzilla.kernel.org/show_bug.cgi?id=99901
Michael Kerrisk <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #1 from Michael Kerrisk <[email protected]> --- 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)
Quoted 8 lines
Created attachment 179841 [details]
iopl3 test program
man ioplcurrently 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
Quoted 13 lines
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
Signature · 6 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 99901] iopl is lost on fork and execve
In reply to a message not in the archivehttps://bugzilla.kernel.org/show_bug.cgi?id=99901
Michael Kerrisk <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |CODE_FIX--- Comment #2 from Michael Kerrisk <[email protected]> --- Alex, sorry for the long delay in following up.
I have applied the patch below. Closing this bug.
Cheers,
Michael
man2/iopl.2 +0 -0
@@ -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),
Signature · 6 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html