All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Down <chris@chrisdown.name>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-kernel@vger.kernel.org, sean.j.christopherson@intel.com,
	tony.luck@intel.com, torvalds@linux-foundation.org,
	x86@kernel.org, kernel-team@fb.com,
	Matthew Garrett <matthewgarrett@google.com>
Subject: Re: [PATCH -v2.1] x86/msr: Filter MSR writes
Date: Tue, 14 Jul 2020 17:04:48 +0100	[thread overview]
Message-ID: <20200714160448.GC2080@chrisdown.name> (raw)
In-Reply-To: <20200714154728.GA3101@nazgul.tnic>

Borislav Petkov writes:
>On Tue, Jul 14, 2020 at 01:19:55PM +0100, Chris Down wrote:
>> That is, even with pr_err_ratelimited, we still end up logging on basically
>> every single write, even though it's from the same TGID writing to the same
>> MSRs, and end up becoming >80% of kmsg.
>>
>> Of course, one can boot with `allow_writes=1` to avoid these messages at
>
>Yes, use that.
>
>From a quick scan over that "tool" you pointed me at, it pokes at some
>MSRs from userspace which the kernel *also* writes to and this is
>exactly what should not be allowed.

I don't think we're in disagreement about that. My concern is strictly about 
the amount of spam caused for some of those existing use cases during the 
transition phase. People should know that their tools would break, but there 
shouldn't be so many messages generated that it inevitably pushes other useful 
information out of the kmsg buffer.

>As to the "MSR hack", please describe what the issue is exactly so that
>we can get the proper people involved. If anything, this needs to be
>fixed in the kernel properly. If people are waiting for a year for a
>BIOS fix, I'd say there's a very slim chance for that to ever happen...

Since the issue involves DPTF which is only supported via binary blobs, I can't 
say for certain what the issue is. As I understand it, when the throttling 
behaviour isn't explicitly configured by the OS kernel, the default policy is 
extremely overeager. Matthew also had a look at it[0], but I don't know if 
anything eventually happened there. I've cc'ed him.

Either way, again, this isn't really the point. :-) The point is that there 
_are_ currently widespread cases involving poking MSRs from userspace, however 
sacrilegious or ugly (which I agree with!), and while people should be told 
about that, it's excessive to have the potential to take up 80% of kmsg in the 
default configuration. It doesn't take thousands of messages to get the message 
across, that's what a custom printk ratelimit is for.

0: https://twitter.com/mjg59/status/1034132444201582596

  reply	other threads:[~2020-07-14 16:04 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-12 10:50 [RFC PATCH] x86/msr: Filter MSR writes Borislav Petkov
2020-06-12 16:34 ` Sean Christopherson
2020-06-12 16:46   ` Borislav Petkov
2020-06-12 16:57     ` Sean Christopherson
2020-06-12 17:03       ` Borislav Petkov
2020-06-12 17:43         ` Sean Christopherson
2020-06-12 17:52           ` Borislav Petkov
2020-06-12 17:20 ` Linus Torvalds
2020-06-12 17:48   ` Borislav Petkov
2020-06-12 19:47     ` Borislav Petkov
2020-06-12 20:39     ` Peter Zijlstra
2020-06-13  5:40       ` Tony Luck
2020-06-13  9:39       ` Borislav Petkov
2020-06-13 15:48 ` [PATCH -v2] " Borislav Petkov
2020-06-15  6:38   ` [PATCH -v2.1] " Borislav Petkov
2020-06-25  5:51     ` Sean Christopherson
2020-06-25  8:37       ` Borislav Petkov
2020-07-14 12:19     ` Chris Down
2020-07-14 15:47       ` Borislav Petkov
2020-07-14 16:04         ` Chris Down [this message]
2020-07-14 16:46           ` Luck, Tony
2020-07-14 16:58             ` Borislav Petkov
2020-07-14 17:02             ` Chris Down
2020-07-14 16:56           ` Borislav Petkov
2020-07-14 17:04             ` Chris Down
2020-07-14 18:52             ` Srinivas Pandruvada
2020-07-15  4:26               ` Borislav Petkov
2020-07-14 19:17           ` Matthew Garrett
2020-11-17 21:00             ` Mathieu Chouquet-Stringer
2020-11-17 21:20               ` Borislav Petkov
2020-11-18  8:58                 ` Mathieu Chouquet-Stringer
2020-11-18  9:09                 ` Mathieu Chouquet-Stringer
2020-11-18 11:50                   ` Borislav Petkov
2020-11-18 14:04                     ` [PATCH] " Mathieu Chouquet-Stringer
2020-11-18 17:50                       ` Borislav Petkov
2020-11-19 10:53                         ` Mathieu Chouquet-Stringer
2020-11-25 21:41                           ` Mathieu Chouquet-Stringer
2020-11-26 10:03                           ` Borislav Petkov
2020-11-17 21:21               ` [PATCH -v2.1] " Matthew Garrett
2020-11-17 21:22                 ` Matthew Garrett
2020-11-18  9:02                   ` Mathieu Chouquet-Stringer
2020-06-17 15:06 ` [tip: x86/misc] " tip-bot2 for Borislav Petkov
2020-06-25  8:45 ` tip-bot2 for Borislav Petkov

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=20200714160448.GC2080@chrisdown.name \
    --to=chris@chrisdown.name \
    --cc=bp@alien8.de \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthewgarrett@google.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=tony.luck@intel.com \
    --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 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.