All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Lutomirski <luto@kernel.org>
Subject: Re: [GIT PULL] x86/iopl changes for v5.5
Date: Tue, 26 Nov 2019 20:50:46 +0100	[thread overview]
Message-ID: <20191126195046.GA28296@gmail.com> (raw)
In-Reply-To: <CAHk-=whswxd9b0A9Sr5YhjcGbA0WKrB8Rrtx89PLKeP6RdKT3A@mail.gmail.com>


* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, Nov 25, 2019 at 8:16 AM Ingo Molnar <mingo@kernel.org> wrote:
> >
> > This tree implements a nice simplification of the iopl and ioperm code
> > that Thomas Gleixner discovered: we can implement the IO privilege
> > features of the iopl system call by using the IO permission bitmap in
> > permissive mode, while trapping CLI/STI/POPF/PUSHF uses in user-space if
> > they change the interrupt flag.
> 
> I've pulled it.
> 
> But do we have a test for something like this:
> 
>    ioperm(.. limited set of ports..)
>    access that limited set.
> 
>    special_sequence() {
>        iopl(3);
>        access some extended set
>        iopl(0)
>    }
> 
>    go back to access the limited set again
> 
> because there's subtle interactions with people using *both* iopl()
> and ioperm() and switching between the two. Historically you could
> trivially do the above, because they are entirely independent
> operations. Does it still work?
> 
> Too busy/lazy to check myself.

Yes, I went through the code with such scenarios in mind and I believe it 
all works correctly: the two bitmaps are independent and the granular one 
is preserved across iopl() interactions. But to make sure I'll write a 
testcase as well.

In any case I agree that this kind of behavior is very much part of the 
ABI, so if it doesn't work like that we'll fix it. :-)

Thanks,

	Ingo

  reply	other threads:[~2019-11-26 19:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-25 16:16 [GIT PULL] x86/iopl changes for v5.5 Ingo Molnar
2019-11-25 19:24 ` Ingo Molnar
2019-11-26  9:45   ` Ingo Molnar
2019-11-26 21:04     ` [GIT PULL] x86/urgent fix " Ingo Molnar
2019-11-27  1:30       ` pr-tracker-bot
2019-11-26 19:30 ` [GIT PULL] x86/iopl changes " pr-tracker-bot
2019-11-26 19:33 ` Linus Torvalds
2019-11-26 19:50   ` Ingo Molnar [this message]
2019-11-26 20:02     ` Ingo Molnar

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=20191126195046.GA28296@gmail.com \
    --to=mingo@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.