Linux-man Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH] iopl.2: Changing description of permissions set per-process to per-thread
@ 2020-05-24 13:22 Thomas Piekarski
  2020-05-25 13:57 ` Michael Kerrisk (man-pages)
  0 siblings, 1 reply; 7+ messages in thread
From: Thomas Piekarski @ 2020-05-24 13:22 UTC (permalink / raw)
  To: Michael Kerrisk (man-pages); +Cc: linux-man, victorm007

iopl is setting permissions for port-mapped I/O not per-process but only 
for threads and its children.

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

Reported-by: victorm007@yahoo.com
Signed-off-by: Thomas Piekarski <t.piekarski@deloquencia.de>


---


1. Test case if permissions are granted per-process or per-thread

I took the opportunity to dig into PMIO and granting permissions with 
iopl and ioperm.

Wrote the following code in which two threads are created and try to 
read some data with inb(). First thread (read_from_sleepy_child) is 
created before permissions are granted (but is delayed) and the second 
one (read_from_child) after that.

If those permissions would be granted on process level should the first 
thread not succeed?

I hope I did not make any mistake, applied threading well and can solve 
this issue as well as support the discussion at LKML.

2. Test Code

#include <pthread.h>
#include <stdio.h>
#include <sys/io.h>
#include <unistd.h>

#define PORT 0x378 // lp0

void *read_from_sleepy_child()
{
   sleep(3);

   // The inb() will fail due to missing permissions and it'll segfault
   // although permissions are acquired before threads are joined.
   // When permissions are set per process this should work.
   printf("Read anything from (sleepy) child thread (%x).\n", inb(PORT));

   return NULL;
}

void *read_from_child()
{
   // The inb() will succeed due to permissions are inherited to
   // childs after they got acquired with either iopl or ioperm
   printf("Read anything from child thread (%x).\n", inb(PORT));

   return NULL;
}

int main()
{
   pthread_t delayed_thread, thread;

   pthread_create(&delayed_thread, NULL, read_from_sleepy_child, NULL);

   iopl(3);
   // ioperm(0, 0xFFFF, 1); // the same segfault

   // The inb() will succeed due to being the main, default thread
   // where permissions got acquired in first place
   printf("Read anything from main thread (%x).\n", inb(PORT));

   pthread_create(&thread, NULL, read_from_child, NULL);
   pthread_join(delayed_thread, NULL);
   pthread_join(thread, NULL);

   return 0;
}


3. Patch

  man2/iopl.2 | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/man2/iopl.2 b/man2/iopl.2
index e5b216a14..329095808 100644
--- a/man2/iopl.2
+++ b/man2/iopl.2
@@ -39,7 +39,7 @@ iopl \- change I/O privilege level
  .BI "int iopl(int " level );
  .SH DESCRIPTION
  .BR iopl ()
-changes the I/O privilege level of the calling process,
+changes the I/O privilege level of the calling thread,
  as specified by the two least significant bits in
  .IR level .
  .PP
@@ -50,7 +50,7 @@ Since these X servers require access to all 65536 I/O 
ports, the
  call is not sufficient.
  .PP
  In addition to granting unrestricted I/O port access, running at a higher
-I/O privilege level also allows the process to disable interrupts.
+I/O privilege level also allows the thread to disable interrupts.
  This will probably crash the system, and is not recommended.
  .PP
  Permissions are not inherited by the child process created by
@@ -79,7 +79,7 @@ is greater than 3.
  This call is unimplemented.
  .TP
  .B EPERM
-The calling process has insufficient privilege to call
+The calling thread has insufficient privilege to call
  .BR iopl ();
  the
  .B CAP_SYS_RAWIO
-- 
2.20.1

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] iopl.2: Changing description of permissions set per-process to per-thread
  2020-05-24 13:22 [PATCH] iopl.2: Changing description of permissions set per-process to per-thread Thomas Piekarski
@ 2020-05-25 13:57 ` Michael Kerrisk (man-pages)
  2020-05-28 13:22   ` Thomas Gleixner
  0 siblings, 1 reply; 7+ messages in thread
From: Michael Kerrisk (man-pages) @ 2020-05-25 13:57 UTC (permalink / raw)
  To: Thomas Piekarski; +Cc: linux-man, victorm007, Thomas Gleixner

[CC += Thomas Gleixner]

Thomas G,

I expect that the small change at Thomas P proposes in this patch is
correct (i.e., iopl(2) operates per-thread, not per-process). I
remember that you touch the relevant kernel source file often. Perhaps
you are able to give a quick Ack?

Thanks,

Michael


On Sun, 24 May 2020 at 15:22, Thomas Piekarski
<t.piekarski@deloquencia.de> wrote:
>
> iopl is setting permissions for port-mapped I/O not per-process but only
> for threads and its children.
>
> See https://bugzilla.kernel.org/show_bug.cgi?id=205317
>
> Reported-by: victorm007@yahoo.com
> Signed-off-by: Thomas Piekarski <t.piekarski@deloquencia.de>
>
>
> ---
>
>
> 1. Test case if permissions are granted per-process or per-thread
>
> I took the opportunity to dig into PMIO and granting permissions with
> iopl and ioperm.
>
> Wrote the following code in which two threads are created and try to
> read some data with inb(). First thread (read_from_sleepy_child) is
> created before permissions are granted (but is delayed) and the second
> one (read_from_child) after that.
>
> If those permissions would be granted on process level should the first
> thread not succeed?
>
> I hope I did not make any mistake, applied threading well and can solve
> this issue as well as support the discussion at LKML.
>
> 2. Test Code
>
> #include <pthread.h>
> #include <stdio.h>
> #include <sys/io.h>
> #include <unistd.h>
>
> #define PORT 0x378 // lp0
>
> void *read_from_sleepy_child()
> {
>    sleep(3);
>
>    // The inb() will fail due to missing permissions and it'll segfault
>    // although permissions are acquired before threads are joined.
>    // When permissions are set per process this should work.
>    printf("Read anything from (sleepy) child thread (%x).\n", inb(PORT));
>
>    return NULL;
> }
>
> void *read_from_child()
> {
>    // The inb() will succeed due to permissions are inherited to
>    // childs after they got acquired with either iopl or ioperm
>    printf("Read anything from child thread (%x).\n", inb(PORT));
>
>    return NULL;
> }
>
> int main()
> {
>    pthread_t delayed_thread, thread;
>
>    pthread_create(&delayed_thread, NULL, read_from_sleepy_child, NULL);
>
>    iopl(3);
>    // ioperm(0, 0xFFFF, 1); // the same segfault
>
>    // The inb() will succeed due to being the main, default thread
>    // where permissions got acquired in first place
>    printf("Read anything from main thread (%x).\n", inb(PORT));
>
>    pthread_create(&thread, NULL, read_from_child, NULL);
>    pthread_join(delayed_thread, NULL);
>    pthread_join(thread, NULL);
>
>    return 0;
> }
>
>
> 3. Patch
>
>   man2/iopl.2 | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/man2/iopl.2 b/man2/iopl.2
> index e5b216a14..329095808 100644
> --- a/man2/iopl.2
> +++ b/man2/iopl.2
> @@ -39,7 +39,7 @@ iopl \- change I/O privilege level
>   .BI "int iopl(int " level );
>   .SH DESCRIPTION
>   .BR iopl ()
> -changes the I/O privilege level of the calling process,
> +changes the I/O privilege level of the calling thread,
>   as specified by the two least significant bits in
>   .IR level .
>   .PP
> @@ -50,7 +50,7 @@ Since these X servers require access to all 65536 I/O
> ports, the
>   call is not sufficient.
>   .PP
>   In addition to granting unrestricted I/O port access, running at a higher
> -I/O privilege level also allows the process to disable interrupts.
> +I/O privilege level also allows the thread to disable interrupts.
>   This will probably crash the system, and is not recommended.
>   .PP
>   Permissions are not inherited by the child process created by
> @@ -79,7 +79,7 @@ is greater than 3.
>   This call is unimplemented.
>   .TP
>   .B EPERM
> -The calling process has insufficient privilege to call
> +The calling thread has insufficient privilege to call
>   .BR iopl ();
>   the
>   .B CAP_SYS_RAWIO
> --
> 2.20.1



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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] iopl.2: Changing description of permissions set per-process to per-thread
  2020-05-25 13:57 ` Michael Kerrisk (man-pages)
@ 2020-05-28 13:22   ` Thomas Gleixner
  2020-05-28 14:52     ` Thomas Piekarski
  0 siblings, 1 reply; 7+ messages in thread
From: Thomas Gleixner @ 2020-05-28 13:22 UTC (permalink / raw)
  To: mtk.manpages, Thomas Piekarski; +Cc: linux-man, victorm007

Michael, Thomas,

"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:

> I expect that the small change at Thomas P proposes in this patch is
> correct (i.e., iopl(2) operates per-thread, not per-process). I
> remember that you touch the relevant kernel source file often. Perhaps
> you are able to give a quick Ack?
>>
>>   man2/iopl.2 | 6 +++---
>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/man2/iopl.2 b/man2/iopl.2
>> index e5b216a14..329095808 100644
>> --- a/man2/iopl.2
>> +++ b/man2/iopl.2
>> @@ -39,7 +39,7 @@ iopl \- change I/O privilege level
>>   .BI "int iopl(int " level );
>>   .SH DESCRIPTION
>>   .BR iopl ()
>> -changes the I/O privilege level of the calling process,
>> +changes the I/O privilege level of the calling thread,

I'm fine with the s/process/thread/ changes. The permissions are really
per thread.

Though the manpage should mention that a thread inherits the permissions
from the parent, i.e. clone() vs. fork(), exec().

>>   as specified by the two least significant bits in
>>   .IR level .
>>   .PP
>> @@ -50,7 +50,7 @@ Since these X servers require access to all 65536 I/O
>> ports, the
>>   call is not sufficient.
>>   .PP
>>   In addition to granting unrestricted I/O port access, running at a higher
>> -I/O privilege level also allows the process to disable interrupts.
>> +I/O privilege level also allows the thread to disable interrupts.

This paragraph became outdated as of

   a24ca9976843 ("x86/iopl: Remove legacy IOPL option")

in v5.5. The kernel no longer allows user space to disable
interrupts. It still grants access to _ALL_ 64k ioports.

Also:

> This call is necessary to allow 8514-compatible X servers to run under
> Linux.  Since these X servers require access to all 65536 I/O ports,
> the ioperm(2) call is not sufficient.

is outdated.

ioperm() allows to set all 64k bits, but its significantly slower than
iopl(3) because it needs to copy 8k of data on context switch while
iopl(3) just maps an 'all bits set' static bitmap.

Aside of that only really old x servers rely on iopl(3).

Thanks,

        tglx

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] iopl.2: Changing description of permissions set per-process to per-thread
  2020-05-28 13:22   ` Thomas Gleixner
@ 2020-05-28 14:52     ` Thomas Piekarski
  2020-06-24  9:53       ` Michael Kerrisk (man-pages)
  0 siblings, 1 reply; 7+ messages in thread
From: Thomas Piekarski @ 2020-05-28 14:52 UTC (permalink / raw)
  To: Thomas Gleixner, mtk.manpages; +Cc: linux-man, victorm007

Hello Thomas,
Hello Michael,


On 28.05.20 3:22 PM, Thomas Gleixner wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
> 
>> I expect that the small change at Thomas P proposes in this patch is
>> correct (i.e., iopl(2) operates per-thread, not per-process). I
>> remember that you touch the relevant kernel source file often. Perhaps
>> you are able to give a quick Ack?
>>>
>>>    man2/iopl.2 | 6 +++---
>>>    1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/man2/iopl.2 b/man2/iopl.2
>>> index e5b216a14..329095808 100644
>>> --- a/man2/iopl.2
>>> +++ b/man2/iopl.2
>>> @@ -39,7 +39,7 @@ iopl \- change I/O privilege level
>>>    .BI "int iopl(int " level );
>>>    .SH DESCRIPTION
>>>    .BR iopl ()
>>> -changes the I/O privilege level of the calling process,
>>> +changes the I/O privilege level of the calling thread,
> 
> I'm fine with the s/process/thread/ changes. The permissions are really
> per thread.
> 
> Though the manpage should mention that a thread inherits the permissions
> from the parent, i.e. clone() vs. fork(), exec().
> 
>>>    as specified by the two least significant bits in
>>>    .IR level .
>>>    .PP
>>> @@ -50,7 +50,7 @@ Since these X servers require access to all 65536 I/O
>>> ports, the
>>>    call is not sufficient.
>>>    .PP
>>>    In addition to granting unrestricted I/O port access, running at a higher
>>> -I/O privilege level also allows the process to disable interrupts.
>>> +I/O privilege level also allows the thread to disable interrupts.
> 
> This paragraph became outdated as of
> 
>     a24ca9976843 ("x86/iopl: Remove legacy IOPL option")
> 
> in v5.5. The kernel no longer allows user space to disable
> interrupts. It still grants access to _ALL_ 64k ioports.
> 
> Also:
> 
>> This call is necessary to allow 8514-compatible X servers to run under
>> Linux.  Since these X servers require access to all 65536 I/O ports,
>> the ioperm(2) call is not sufficient.
> 
> is outdated.
> 
> ioperm() allows to set all 64k bits, but its significantly slower than
> iopl(3) because it needs to copy 8k of data on context switch while
> iopl(3) just maps an 'all bits set' static bitmap.
> 
> Aside of that only really old x servers rely on iopl(3).


Thanks for your feedback. I'll update the patch accordingly.

1. Rechecking that it says that permissions are inherited from parents
2. Stating that since Kernel v5.5 it is not possible anymore to
    disable interrupts from user space
3. Removing the paragraph "This call is necessary..."

Should the man page mention that iopl is deprecated, provided only for 
compatibility to old X-Servers and significantly slower than ioperm?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] iopl.2: Changing description of permissions set per-process to per-thread
  2020-05-28 14:52     ` Thomas Piekarski
@ 2020-06-24  9:53       ` Michael Kerrisk (man-pages)
  2020-06-26 20:29         ` [PATCH-v2] iopl.2: Updating description of permissions and disabling interrupts Thomas Piekarski
  0 siblings, 1 reply; 7+ messages in thread
From: Michael Kerrisk (man-pages) @ 2020-06-24  9:53 UTC (permalink / raw)
  To: Thomas Piekarski; +Cc: Thomas Gleixner, linux-man, victorm007

Hi Thomas P,

Might you have an update for this patch?

Thanks,

Michael


On Thu, 28 May 2020 at 16:52, Thomas Piekarski
<t.piekarski@deloquencia.de> wrote:
>
> Hello Thomas,
> Hello Michael,
>
>
> On 28.05.20 3:22 PM, Thomas Gleixner wrote:
> > "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
> >
> >> I expect that the small change at Thomas P proposes in this patch is
> >> correct (i.e., iopl(2) operates per-thread, not per-process). I
> >> remember that you touch the relevant kernel source file often. Perhaps
> >> you are able to give a quick Ack?
> >>>
> >>>    man2/iopl.2 | 6 +++---
> >>>    1 file changed, 3 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/man2/iopl.2 b/man2/iopl.2
> >>> index e5b216a14..329095808 100644
> >>> --- a/man2/iopl.2
> >>> +++ b/man2/iopl.2
> >>> @@ -39,7 +39,7 @@ iopl \- change I/O privilege level
> >>>    .BI "int iopl(int " level );
> >>>    .SH DESCRIPTION
> >>>    .BR iopl ()
> >>> -changes the I/O privilege level of the calling process,
> >>> +changes the I/O privilege level of the calling thread,
> >
> > I'm fine with the s/process/thread/ changes. The permissions are really
> > per thread.
> >
> > Though the manpage should mention that a thread inherits the permissions
> > from the parent, i.e. clone() vs. fork(), exec().
> >
> >>>    as specified by the two least significant bits in
> >>>    .IR level .
> >>>    .PP
> >>> @@ -50,7 +50,7 @@ Since these X servers require access to all 65536 I/O
> >>> ports, the
> >>>    call is not sufficient.
> >>>    .PP
> >>>    In addition to granting unrestricted I/O port access, running at a higher
> >>> -I/O privilege level also allows the process to disable interrupts.
> >>> +I/O privilege level also allows the thread to disable interrupts.
> >
> > This paragraph became outdated as of
> >
> >     a24ca9976843 ("x86/iopl: Remove legacy IOPL option")
> >
> > in v5.5. The kernel no longer allows user space to disable
> > interrupts. It still grants access to _ALL_ 64k ioports.
> >
> > Also:
> >
> >> This call is necessary to allow 8514-compatible X servers to run under
> >> Linux.  Since these X servers require access to all 65536 I/O ports,
> >> the ioperm(2) call is not sufficient.
> >
> > is outdated.
> >
> > ioperm() allows to set all 64k bits, but its significantly slower than
> > iopl(3) because it needs to copy 8k of data on context switch while
> > iopl(3) just maps an 'all bits set' static bitmap.
> >
> > Aside of that only really old x servers rely on iopl(3).
>
>
> Thanks for your feedback. I'll update the patch accordingly.
>
> 1. Rechecking that it says that permissions are inherited from parents
> 2. Stating that since Kernel v5.5 it is not possible anymore to
>     disable interrupts from user space
> 3. Removing the paragraph "This call is necessary..."
>
> Should the man page mention that iopl is deprecated, provided only for
> compatibility to old X-Servers and significantly slower than ioperm?



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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH-v2] iopl.2: Updating description of permissions and disabling interrupts
  2020-06-24  9:53       ` Michael Kerrisk (man-pages)
@ 2020-06-26 20:29         ` Thomas Piekarski
  2020-06-29 11:49           ` Michael Kerrisk (man-pages)
  0 siblings, 1 reply; 7+ messages in thread
From: Thomas Piekarski @ 2020-06-26 20:29 UTC (permalink / raw)
  To: mtk.manpages; +Cc: Thomas Gleixner, linux-man, victorm007

Updating description of permissions for port-mapped I/O set per-thread 
and not per-process. Mentioning iopl can not disable interrupts since 
5.5 anymore and is in general deprecated and only provided for legacy X 
servers.

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

Reported-by: victorm007@yahoo.com
Signed-off-by: Thomas Piekarski <t.piekarski@deloquencia.de>


---
  man2/iopl.2 | 34 ++++++++++++++--------------------
  1 file changed, 14 insertions(+), 20 deletions(-)

diff --git a/man2/iopl.2 b/man2/iopl.2
index e5b216a14..be9acfd1e 100644
--- a/man2/iopl.2
+++ b/man2/iopl.2
@@ -39,29 +39,17 @@ iopl \- change I/O privilege level
  .BI "int iopl(int " level );
  .SH DESCRIPTION
  .BR iopl ()
-changes the I/O privilege level of the calling process,
+changes the I/O privilege level of the calling thread,
  as specified by the two least significant bits in
  .IR level .
  .PP
-This call is necessary to allow 8514-compatible X servers to run under
-Linux.
-Since these X servers require access to all 65536 I/O ports, the
-.BR ioperm (2)
-call is not sufficient.
+The I/O privilege level for a normal thread is 0.
+Permissions are inherited from parents to children.
  .PP
-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.
-.PP
-Permissions are not inherited by the child process created by
-.BR fork (2)
-and are not preserved across
-.BR execve (2)
-(but see NOTES).
-.PP
-The I/O privilege level for a normal process is 0.
-.PP
-This call is mostly for the i386 architecture.
+This call is deprecated, significantly slower than
+.BR ioperm(2)
+and is only provided for older X servers which require
+access to all 65536 I/O ports. It is mostly for the i386 architecture.
  On many other architectures it does not exist or will always
  return an error.
  .SH RETURN VALUE
@@ -79,7 +67,7 @@ is greater than 3.
  This call is unimplemented.
  .TP
  .B EPERM
-The calling process has insufficient privilege to call
+The calling thread has insufficient privilege to call
  .BR iopl ();
  the
  .B CAP_SYS_RAWIO
@@ -99,6 +87,12 @@ and in
  .IR <sys/perm.h> .
  Avoid the latter, it is available on i386 only.
  .PP
+Prior to Linux 5.5
+.BR iopl ()
+allowed the thread to disable interrupts while running
+at a higher I/O privilege level. This will probably crash
+the system, and is not recommended.
+.PP
  Prior to Linux 3.7,
  on some architectures (such as i386), permissions
  .I were
-- 
2.20.1





On 24.06.20 11:53 AM, Michael Kerrisk (man-pages) wrote:
> Hi Thomas P,
> 
> Might you have an update for this patch?
> 
> Thanks,
> 
> Michael
> 
> 
> On Thu, 28 May 2020 at 16:52, Thomas Piekarski
> <t.piekarski@deloquencia.de> wrote:
>> On 28.05.20 3:22 PM, Thomas Gleixner wrote:
>>> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
>>>
>>>> I expect that the small change at Thomas P proposes in this patch is
>>>> correct (i.e., iopl(2) operates per-thread, not per-process). I
>>>> remember that you touch the relevant kernel source file often. Perhaps
>>>> you are able to give a quick Ack?
>>>>>
>>>>>     man2/iopl.2 | 6 +++---
>>>>>     1 file changed, 3 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/man2/iopl.2 b/man2/iopl.2
>>>>> index e5b216a14..329095808 100644
>>>>> --- a/man2/iopl.2
>>>>> +++ b/man2/iopl.2
>>>>> @@ -39,7 +39,7 @@ iopl \- change I/O privilege level
>>>>>     .BI "int iopl(int " level );
>>>>>     .SH DESCRIPTION
>>>>>     .BR iopl ()
>>>>> -changes the I/O privilege level of the calling process,
>>>>> +changes the I/O privilege level of the calling thread,
>>>
>>> I'm fine with the s/process/thread/ changes. The permissions are really
>>> per thread.
>>>
>>> Though the manpage should mention that a thread inherits the permissions
>>> from the parent, i.e. clone() vs. fork(), exec().
>>>
>>>>>     as specified by the two least significant bits in
>>>>>     .IR level .
>>>>>     .PP
>>>>> @@ -50,7 +50,7 @@ Since these X servers require access to all 65536 I/O
>>>>> ports, the
>>>>>     call is not sufficient.
>>>>>     .PP
>>>>>     In addition to granting unrestricted I/O port access, running at a higher
>>>>> -I/O privilege level also allows the process to disable interrupts.
>>>>> +I/O privilege level also allows the thread to disable interrupts.
>>>
>>> This paragraph became outdated as of
>>>
>>>      a24ca9976843 ("x86/iopl: Remove legacy IOPL option")
>>>
>>> in v5.5. The kernel no longer allows user space to disable
>>> interrupts. It still grants access to _ALL_ 64k ioports.
>>>
>>> Also:
>>>
>>>> This call is necessary to allow 8514-compatible X servers to run under
>>>> Linux.  Since these X servers require access to all 65536 I/O ports,
>>>> the ioperm(2) call is not sufficient.
>>>
>>> is outdated.
>>>
>>> ioperm() allows to set all 64k bits, but its significantly slower than
>>> iopl(3) because it needs to copy 8k of data on context switch while
>>> iopl(3) just maps an 'all bits set' static bitmap.
>>>
>>> Aside of that only really old x servers rely on iopl(3).
>>
>>
>> Thanks for your feedback. I'll update the patch accordingly.
>>
>> 1. Rechecking that it says that permissions are inherited from parents
>> 2. Stating that since Kernel v5.5 it is not possible anymore to
>>      disable interrupts from user space
>> 3. Removing the paragraph "This call is necessary..."
>>
>> Should the man page mention that iopl is deprecated, provided only for
>> compatibility to old X-Servers and significantly slower than ioperm?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH-v2] iopl.2: Updating description of permissions and disabling interrupts
  2020-06-26 20:29         ` [PATCH-v2] iopl.2: Updating description of permissions and disabling interrupts Thomas Piekarski
@ 2020-06-29 11:49           ` Michael Kerrisk (man-pages)
  0 siblings, 0 replies; 7+ messages in thread
From: Michael Kerrisk (man-pages) @ 2020-06-29 11:49 UTC (permalink / raw)
  To: Thomas Piekarski; +Cc: mtk.manpages, Thomas Gleixner, linux-man, victorm007

Hello Thomas,

On 6/26/20 10:29 PM, Thomas Piekarski wrote:
> Updating description of permissions for port-mapped I/O set per-thread 
> and not per-process. Mentioning iopl can not disable interrupts since 
> 5.5 anymore and is in general deprecated and only provided for legacy X 
> servers.
> 
> See https://bugzilla.kernel.org/show_bug.cgi?id=205317
> 
> Reported-by: victorm007@yahoo.com
> Signed-off-by: Thomas Piekarski <t.piekarski@deloquencia.de>

Thanks! I've applied this patch.

Cheers,

Michael

> ---
>   man2/iopl.2 | 34 ++++++++++++++--------------------
>   1 file changed, 14 insertions(+), 20 deletions(-)
> 
> diff --git a/man2/iopl.2 b/man2/iopl.2
> index e5b216a14..be9acfd1e 100644
> --- a/man2/iopl.2
> +++ b/man2/iopl.2
> @@ -39,29 +39,17 @@ iopl \- change I/O privilege level
>   .BI "int iopl(int " level );
>   .SH DESCRIPTION
>   .BR iopl ()
> -changes the I/O privilege level of the calling process,
> +changes the I/O privilege level of the calling thread,
>   as specified by the two least significant bits in
>   .IR level .
>   .PP
> -This call is necessary to allow 8514-compatible X servers to run under
> -Linux.
> -Since these X servers require access to all 65536 I/O ports, the
> -.BR ioperm (2)
> -call is not sufficient.
> +The I/O privilege level for a normal thread is 0.
> +Permissions are inherited from parents to children.
>   .PP
> -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.
> -.PP
> -Permissions are not inherited by the child process created by
> -.BR fork (2)
> -and are not preserved across
> -.BR execve (2)
> -(but see NOTES).
> -.PP
> -The I/O privilege level for a normal process is 0.
> -.PP
> -This call is mostly for the i386 architecture.
> +This call is deprecated, significantly slower than
> +.BR ioperm(2)
> +and is only provided for older X servers which require
> +access to all 65536 I/O ports. It is mostly for the i386 architecture.
>   On many other architectures it does not exist or will always
>   return an error.
>   .SH RETURN VALUE
> @@ -79,7 +67,7 @@ is greater than 3.
>   This call is unimplemented.
>   .TP
>   .B EPERM
> -The calling process has insufficient privilege to call
> +The calling thread has insufficient privilege to call
>   .BR iopl ();
>   the
>   .B CAP_SYS_RAWIO
> @@ -99,6 +87,12 @@ and in
>   .IR <sys/perm.h> .
>   Avoid the latter, it is available on i386 only.
>   .PP
> +Prior to Linux 5.5
> +.BR iopl ()
> +allowed the thread to disable interrupts while running
> +at a higher I/O privilege level. This will probably crash
> +the system, and is not recommended.
> +.PP
>   Prior to Linux 3.7,
>   on some architectures (such as i386), permissions
>   .I were
> 


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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, back to index

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-24 13:22 [PATCH] iopl.2: Changing description of permissions set per-process to per-thread Thomas Piekarski
2020-05-25 13:57 ` Michael Kerrisk (man-pages)
2020-05-28 13:22   ` Thomas Gleixner
2020-05-28 14:52     ` Thomas Piekarski
2020-06-24  9:53       ` Michael Kerrisk (man-pages)
2020-06-26 20:29         ` [PATCH-v2] iopl.2: Updating description of permissions and disabling interrupts Thomas Piekarski
2020-06-29 11:49           ` Michael Kerrisk (man-pages)

Linux-man Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-man/0 linux-man/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-man linux-man/ https://lore.kernel.org/linux-man \
		linux-man@vger.kernel.org
	public-inbox-index linux-man

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-man


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git