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
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
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),