From: Willy Tarreau <w@1wt.eu>
To: hpa@zytor.com
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
Stephen Hemminger <stephen@networkplumber.org>,
Juergen Gross <jgross@suse.com>,
Sean Christopherson <sean.j.christopherson@intel.com>
Subject: Re: [patch 5/9] x86/ioport: Reduce ioperm impact for sane usage further
Date: Thu, 7 Nov 2019 13:56:38 +0100 [thread overview]
Message-ID: <20191107125638.GB15642@1wt.eu> (raw)
In-Reply-To: <5AAEF116-EC9D-4C58-878F-9D27189E123A@zytor.com>
On Thu, Nov 07, 2019 at 02:50:20AM -0800, hpa@zytor.com wrote:
> You get access to the ports you are assigned, just like pages you are
> assigned... the rest is kernel policy, or, for that matter, privileged
> userspace (get permissions to the necessary ports, then drop privilege... the
> usual stuff.)
I agree, my point is that there's already no policy checking at the
moment ports are assigned, hence a process having the permissions to
request just port 0x70-0x71 to read the hwclock will also have permission
to request access to the sensor chip a 0x2E and trigger a watchdog
reset or stop the CPU fan. Thus any policy enforcement is solely done
by the requesting process itself, assuming it doesn't simply use iopl()
already, which grants everything.
This is why I'm really wondering if the real use cases that need all
this stuff still exist at all in practice.
Willy
next prev parent reply other threads:[~2019-11-07 12:58 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-06 19:34 [patch 0/9] x86/iopl: Prevent user space from using CLI/STI with iopl(3) Thomas Gleixner
2019-11-06 19:35 ` [patch 1/9] x86/ptrace: Prevent truncation of bitmap size Thomas Gleixner
2019-11-07 7:31 ` Ingo Molnar
2019-11-06 19:35 ` [patch 2/9] x86/process: Unify copy_thread_tls() Thomas Gleixner
2019-11-08 22:31 ` Andy Lutomirski
2019-11-08 23:43 ` Thomas Gleixner
2019-11-10 12:36 ` Thomas Gleixner
2019-11-10 16:56 ` Andy Lutomirski
2019-11-11 8:52 ` Peter Zijlstra
2019-11-06 19:35 ` [patch 3/9] x86/cpu: Unify cpu_init() Thomas Gleixner
2019-11-08 22:34 ` Andy Lutomirski
2019-11-06 19:35 ` [patch 4/9] x86/io: Speedup schedule out of I/O bitmap user Thomas Gleixner
2019-11-07 9:12 ` Peter Zijlstra
2019-11-07 14:04 ` Thomas Gleixner
2019-11-07 14:08 ` Thomas Gleixner
2019-11-08 22:41 ` Andy Lutomirski
2019-11-08 23:45 ` Thomas Gleixner
2019-11-09 3:32 ` Andy Lutomirski
2019-11-10 12:43 ` Thomas Gleixner
2019-11-09 0:24 ` Andy Lutomirski
2019-11-06 19:35 ` [patch 5/9] x86/ioport: Reduce ioperm impact for sane usage further Thomas Gleixner
2019-11-07 1:11 ` Linus Torvalds
2019-11-07 7:44 ` Thomas Gleixner
2019-11-07 8:25 ` Ingo Molnar
2019-11-07 9:17 ` Willy Tarreau
2019-11-07 10:00 ` Thomas Gleixner
2019-11-07 10:13 ` Willy Tarreau
2019-11-07 10:19 ` hpa
2019-11-07 10:27 ` Willy Tarreau
2019-11-07 10:50 ` hpa
2019-11-07 12:56 ` Willy Tarreau [this message]
2019-11-07 16:45 ` Eric W. Biederman
2019-11-07 16:53 ` Linus Torvalds
2019-11-07 16:57 ` Willy Tarreau
2019-11-10 17:17 ` Andy Lutomirski
2019-11-07 7:37 ` Ingo Molnar
2019-11-07 7:45 ` Thomas Gleixner
2019-11-07 8:16 ` Ingo Molnar
2019-11-07 18:02 ` Thomas Gleixner
2019-11-07 19:24 ` Brian Gerst
2019-11-07 19:54 ` Linus Torvalds
2019-11-07 21:00 ` Brian Gerst
2019-11-07 21:32 ` Thomas Gleixner
2019-11-07 23:20 ` hpa
2019-11-07 21:44 ` Linus Torvalds
2019-11-08 1:12 ` H. Peter Anvin
2019-11-08 2:12 ` Brian Gerst
2019-11-10 17:21 ` Andy Lutomirski
2019-11-06 19:35 ` [patch 6/9] x86/iopl: Fixup misleading comment Thomas Gleixner
2019-11-06 19:35 ` [patch 7/9] x86/iopl: Restrict iopl() permission scope Thomas Gleixner
2019-11-07 9:09 ` Peter Zijlstra
2019-11-10 17:26 ` Andy Lutomirski
2019-11-10 20:31 ` Thomas Gleixner
2019-11-10 21:05 ` Andy Lutomirski
2019-11-10 21:21 ` Thomas Gleixner
2019-11-06 19:35 ` [patch 8/9] x86/iopl: Remove legacy IOPL option Thomas Gleixner
2019-11-07 6:11 ` Jürgen Groß
2019-11-07 6:26 ` hpa
2019-11-07 16:44 ` Stephen Hemminger
2019-11-07 9:13 ` Peter Zijlstra
2019-11-06 19:35 ` [patch 9/9] selftests/x86/iopl: Verify that CLI/STI result in #GP Thomas Gleixner
2019-11-07 7:28 ` [patch] x86/iopl: Remove unused local variable, update comments in ksys_ioperm() 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=20191107125638.GB15642@1wt.eu \
--to=w@1wt.eu \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=sean.j.christopherson@intel.com \
--cc=stephen@networkplumber.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).