From: Borislav Petkov <bp@alien8.de>
To: Andi Kleen <ak@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Feng Tang <feng.tang@intel.com>, Ingo Molnar <mingo@redhat.com>,
"H . Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
x86@kernel.org, linux-kernel@vger.kernel.org,
rui.zhang@intel.com, andi.kleen@intel.com, dave.hansen@intel.com,
len.brown@intel.com
Subject: Re: [PATCH] x86/msr: Block writes to certain MSRs unconditionally
Date: Sun, 11 Apr 2021 11:40:40 +0200 [thread overview]
Message-ID: <20210411094040.GC14022@zn.tnic> (raw)
In-Reply-To: <87r1jiug4e.fsf@linux.intel.com>
On Sat, Apr 10, 2021 at 11:52:17AM -0700, Andi Kleen wrote:
> Have you ever seen any user programs actually write those MSRs?
> I don't see why they ever would, it's not that they have any motivation
> to do it (unlike SMM), and I don't know of any examples.
You'd be surprised how much motivation people have to poke at random
MSRs. Just browse some of those tools on github which think poking at
MSRs is ok.
> The whole MSR blocking seems more like a tilting at windmills
> type effort.
Nope, this is trying to salvage the current situation of people thinking
it is a good idea to poke at random MSRs and develop all kinds of tools
around it and then run those tools ontop of a kernel which pokes at
those same MSRs.
It is not really hard to realize that touching resources in an
unsynchronized way is a disaster waiting to happen. No matter how useful
and how wonderful those tools are.
> But on a non locked down system fully accessible MSRs are really
> useful for all kind of debugging and tuning, and anything that
> prevents that is bad.
If you wanna do that, you can just as well patch your kernel.
We're currently tainting the kernel on MSR writes and perhaps that's
good enough for now but if some tool starts doing dumb crap and pokes at
MSRs it should not be poking at and users start complaining because of
it, I'm committing that.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2021-04-11 9:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-30 8:25 [RFC 1/2] x86/tsc: add a timer to make sure tsc_adjust is always checked Feng Tang
2021-03-30 8:25 ` [RFC 2/2] x86/tsc: mark tsc reliable for qualified platforms Feng Tang
2021-04-10 9:27 ` [RFC 1/2] x86/tsc: add a timer to make sure tsc_adjust is always checked Thomas Gleixner
2021-04-10 9:47 ` Borislav Petkov
2021-04-10 12:11 ` [PATCH] x86/msr: Block writes to certain MSRs unconditionally Borislav Petkov
2021-04-10 14:51 ` Andy Lutomirski
2021-04-10 15:33 ` [PATCH -v1.1] " Borislav Petkov
2021-04-10 18:52 ` [PATCH] " Andi Kleen
2021-04-11 9:40 ` Borislav Petkov [this message]
2021-04-11 16:03 ` Andy Lutomirski
2021-04-11 16:43 ` Andi Kleen
2021-04-11 16:57 ` Andy Lutomirski
2021-04-11 17:03 ` Borislav Petkov
2021-04-11 23:21 ` Andy Lutomirski
2021-04-12 9:37 ` Borislav Petkov
2021-04-10 14:48 ` [RFC 1/2] x86/tsc: add a timer to make sure tsc_adjust is always checked Feng Tang
2021-04-10 15:38 ` Borislav Petkov
2021-04-10 18:43 ` Thomas Gleixner
2021-04-10 14:38 ` Feng Tang
2021-04-10 18:46 ` Thomas Gleixner
2021-04-11 7:21 ` Feng Tang
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=20210411094040.GC14022@zn.tnic \
--to=bp@alien8.de \
--cc=ak@linux.intel.com \
--cc=andi.kleen@intel.com \
--cc=dave.hansen@intel.com \
--cc=feng.tang@intel.com \
--cc=hpa@zytor.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rui.zhang@intel.com \
--cc=tglx@linutronix.de \
--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 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.