[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200714170404.GE2080@chrisdown.name>
Date: Tue, 14 Jul 2020 18:04:04 +0100
From: Chris Down <chris@...isdown.name>
To: Borislav Petkov <bp@...en8.de>
Cc: linux-kernel@...r.kernel.org, sean.j.christopherson@...el.com,
tony.luck@...el.com, torvalds@...ux-foundation.org, x86@...nel.org,
kernel-team@...com, Matthew Garrett <matthewgarrett@...gle.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Len Brown <len.brown@...el.com>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
Jacob Pan <jacob.jun.pan@...ux.intel.com>
Subject: Re: [PATCH -v2.1] x86/msr: Filter MSR writes
Borislav Petkov writes:
>On Tue, Jul 14, 2020 at 05:04:48PM +0100, Chris Down wrote:
>> 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.
>
>Ok, feel free to suggest a fix, better yet send a patch. Otherwise,
>you'd have to wait for my vacation to end first. :-)
Sure thing, I'll send a patch tomorrow, then. :-)
Powered by blists - more mailing lists