Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 14 Jul 2020 17:04:48 +0100
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
Message-ID: <20200714160448.GC2080@chrisdown.name>
References: <20200615063837.GA14668@zn.tnic>
 <20200714121955.GA2080@chrisdown.name>
 <20200714154728.GA3101@nazgul.tnic>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20200714154728.GA3101@nazgul.tnic>
User-Agent: Mutt/1.14.6 (2020-07-11)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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