Linux-man Archive on lore.kernel.org
 help / color / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Thomas Piekarski <t.piekarski@deloquencia.de>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	linux-man <linux-man@vger.kernel.org>,
	victorm007@yahoo.com
Subject: Re: [PATCH] iopl.2: Changing description of permissions set per-process to per-thread
Date: Wed, 24 Jun 2020 11:53:12 +0200
Message-ID: <CAKgNAkiNQw5DE9X5Mw2MMF+=bXHzAz45ym+=s2_C2Nz=p4zfQg@mail.gmail.com> (raw)
In-Reply-To: <2103b6f3-42d1-8f92-0e97-e43ccd12c1b7@deloquencia.de>

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/

  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-24 13:22 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) [this message]
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)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKgNAkiNQw5DE9X5Mw2MMF+=bXHzAz45ym+=s2_C2Nz=p4zfQg@mail.gmail.com' \
    --to=mtk.manpages@gmail.com \
    --cc=linux-man@vger.kernel.org \
    --cc=t.piekarski@deloquencia.de \
    --cc=tglx@linutronix.de \
    --cc=victorm007@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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