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: Wed, 9 Sep 2020 17:08:06 -0700 From: Andy Lutomirski <luto@...nel.org> To: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com> Cc: Borislav Petkov <bp@...en8.de>, Sultan Alsawaf <sultan@...neltoast.com>, "Jason A. Donenfeld" <Jason@...c4.com>, kitsunyan <kitsunyan@...mail.cc>, "Brown, Len" <len.brown@...el.com>, X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: [PATCH] x86/msr: do not warn on writes to OC_MAILBOX On Tue, Sep 8, 2020 at 6:02 PM Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com> wrote: > > On Tue, 2020-09-08 at 21:30 +0200, Borislav Petkov wrote: > > On Tue, Sep 08, 2020 at 12:18:38PM -0700, Sultan Alsawaf wrote: > > > I'd like to point out that on Intel's recent 14nm parts, > > > undervolting > > > is not so much for squeezing every last drop of performance out of > > > the > > > SoC as it is for necessity. > > > > <snip interesting examples> > > > > Sounds to me that this undervolting functionality should be part of > > the kernel and happen automatically. I have no clue, though, whether > > people who do it, just get lucky and undervolting doesn't cause any > > other hardware issues, or there's a real reason for this power > > madness > > and if not done, power-related failures happen only on some boxes so > > they decided to do them on all. > > > > Or maybe BIOS is nuts, which is not a stretch. > > > The whole OC is based on experiments to come to correct values. This > depends on whole system design not just CPUs. > https://www.intel.com/content/www/us/en/gaming/resources/how-to-overclock.html > It warns about system stability. > > > Srinivas, what's the story here? > I checked and there is no public spec. There are several mailbox > commands with version dependent on the processor. > > The actual OC mailbox implementation itself is implemented in Linux in > intel_turbo_max_3 driver. So that is public. > So someone can develop a driver and provide some sysfs to send mailbox > commands, but kernel can't validate commands which can cause any > security or stability issues. Not sure if this is acceptable standard. > I don't think there is any precedent of creating such blind sysfs > entries. > > Having once written a rejected driver to poke at the Intel Xeon memory controller SMBUS, there is at least precedent for writing drivers for dangerous interfaces, if not merging said drivers :) But we have drivers for various EC interfaces, for other SMBUS hosts, etc, and all of these can cause all kinds of mischief if misused.
Powered by blists - more mailing lists