From: Thomas Gleixner <tglx@linutronix.de>
To: "Mcfadden, Marty Jay" <mcfadden8@llnl.gov>
Cc: Borislav Petkov <bp@alien8.de>,
George Spelvin <linux@horizon.com>,
"a.p.zijlstra@chello.nl" <a.p.zijlstra@chello.nl>,
"acme@infradead.org" <acme@infradead.org>,
"ak@linux.intel.com" <ak@linux.intel.com>,
"andriy.shevchenko@linux.intel.com"
<andriy.shevchenko@linux.intel.com>,
"brgerst@gmail.com" <brgerst@gmail.com>,
"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
"dyoung@redhat.com" <dyoung@redhat.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"jolsa@redhat.com" <jolsa@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"luto@kernel.org" <luto@kernel.org>,
"mingo@kernel.org" <mingo@kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"pavel@ucw.cz" <pavel@ucw.cz>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"x86@kernel.org" <x86@kernel.org>,
"yu.c.chen@intel.com" <yu.c.chen@intel.com>
Subject: RE: [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction
Date: Tue, 1 Mar 2016 09:02:59 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.11.1603010849550.3638@nanos> (raw)
In-Reply-To: <AEA6FC45760E2A42897809E8E402EA1E0F2CA586@PRDEXMBX-02.the-lab.llnl.gov>
On Mon, 29 Feb 2016, Mcfadden, Marty Jay wrote:
> This is precisely why the whitelist approach is being proposed. The current
> version of msr.ko will gladly allow userspace tools with capabilities set to
> scribble all over them. With whitelists, system admins can turn off
> capabilities for the apps and limit access to a very small subset of bits of
> a small subset of MSRs.
We don't need any of this, really.
Developers who play with experimental or emerging technologies hardly need
that whitelist stuff. They better know what they are doing.
For normal production use we want proper interfaces/drivers for the
technologies which should be made accessible to applications. msr.ko should
not be available on any production machine at all.
Your whitelist filter is just a sloppy hack to foster bad practices. Your
arguments about emerging technologies etc. are just trying to lull us into
accepting your wonderful hackery, so that you can continue to use MSRs in
production environments while pretending that you provide a reasonable amount
of security and sanity around it. Nice try, but it doesn't work...
Thanks,
tglx
next prev parent reply other threads:[~2016-03-01 8:04 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-26 0:02 Marty McFadden
2016-02-26 0:02 ` [PATCH 1/4] MSR: Prep for separating msr.c into three files Marty McFadden
2016-02-26 2:56 ` kbuild test robot
2016-02-26 10:08 ` Andy Shevchenko
2016-02-26 0:02 ` [PATCH 2/4] " Marty McFadden
2016-02-26 0:02 ` [PATCH 3/4] MSR: msr Whitelist Implementation Marty McFadden
2016-02-26 1:05 ` kbuild test robot
2016-02-26 1:05 ` [PATCH] MSR: fix badzero.cocci warnings kbuild test robot
2016-02-26 0:02 ` [PATCH 4/4] MSR: msr Batch processing feature Marty McFadden
2016-02-26 2:48 ` Andy Lutomirski
2016-03-03 17:21 ` One Thousand Gnomes
2016-03-03 23:09 ` Mcfadden, Marty Jay
2016-02-26 7:37 ` [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction Ingo Molnar
2016-02-28 18:54 ` Mcfadden, Marty Jay
2016-02-28 19:01 ` Borislav Petkov
2016-02-29 2:55 ` Mcfadden, Marty Jay
2016-02-29 14:58 ` Borislav Petkov
2016-02-29 16:31 ` Henrique de Moraes Holschuh
2016-02-29 17:22 ` Borislav Petkov
2016-02-29 17:53 ` George Spelvin
2016-02-29 18:20 ` Borislav Petkov
2016-02-29 22:35 ` Mcfadden, Marty Jay
2016-02-29 23:41 ` Borislav Petkov
2016-03-01 19:01 ` Rountree, Barry L.
2016-03-03 0:40 ` Andy Lutomirski
2016-03-01 8:02 ` Thomas Gleixner [this message]
2016-03-01 18:29 ` Rountree, Barry L.
2016-03-01 18:38 ` Borislav Petkov
2016-02-29 17:17 ` Andy Lutomirski
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=alpine.DEB.2.11.1603010849550.3638@nanos \
--to=tglx@linutronix.de \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@infradead.org \
--cc=ak@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=dan.j.williams@intel.com \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@horizon.com \
--cc=luto@kernel.org \
--cc=mcfadden8@llnl.gov \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=pavel@ucw.cz \
--cc=viro@zeniv.linux.org.uk \
--cc=x86@kernel.org \
--cc=yu.c.chen@intel.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
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
all inboxes | Powered by JetHome®