lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 14 Jul 2020 11:52:47 -0700 From: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com> To: Borislav Petkov <bp@...en8.de>, Chris Down <chris@...isdown.name> 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>, Jacob Pan <jacob.jun.pan@...ux.intel.com> Subject: Re: [PATCH -v2.1] x86/msr: Filter MSR writes On Tue, 2020-07-14 at 18:56 +0200, Borislav Petkov wrote: > 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. :-) > > > 0: https://twitter.com/mjg59/status/1034132444201582596 > > As to the power issue, lemme CC some Intel folks I found in > MAINTAINERS. > > Intel folks, pls check the link above and upthread: Why TF do people > need to use some luserspace daemon which pokes at MSRs which the > kernel > writes to too, in order to bypass some apparently too conservative > throttling, AFAIU? For issues related to thermal or power, we don't expect to poke MSRs from user space by any daemon. We have sysfs interfaces for the required controls. This is also true for controls via MMIO space. Anytime if it is safe to add, we are adding controls via sysfs. The tool in question from the link (not from Intel), when developed may not have TCC or RAPL-MMIO controls via sysfs. We have sysfs interfaces for a while. They can send email to me to justify other controls if any. Only time direct MSR access is required is for debug tools like turbostat. > > And why does this work on windoze reportedly? This is not related to MSR or MMIO. This is related to some ACPI tables. In Linux, thermald will adjust these knobs like Windows. It was missing some ACPI details, which Matthew Garrett submitted patches to kernel and getting merged with 5.8 series. Thanks, Srinivas
Powered by blists - more mailing lists