From: Andy Lutomirski <luto@kernel.org>
To: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>,
Sultan Alsawaf <sultan@kerneltoast.com>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
kitsunyan <kitsunyan@airmail.cc>,
"Brown, Len" <len.brown@intel.com>, X86 ML <x86@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] x86/msr: do not warn on writes to OC_MAILBOX
Date: Wed, 9 Sep 2020 17:08:06 -0700 [thread overview]
Message-ID: <CALCETrWAa+WogyaZ+XGsVxQ+3-j3C+VoQnRWz8L+FUgRpY7nfw@mail.gmail.com> (raw)
In-Reply-To: <fa447f6b7c7f03cc0c55573d5736889cee81a1e6.camel@linux.intel.com>
On Tue, Sep 8, 2020 at 6:02 PM Srinivas Pandruvada
<srinivas.pandruvada@linux.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.
next prev parent reply other threads:[~2020-09-10 2:38 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-07 9:48 [PATCH] x86/msr: do not warn on writes to OC_MAILBOX Jason A. Donenfeld
2020-09-07 10:06 ` Borislav Petkov
2020-09-07 10:46 ` Jason A. Donenfeld
2020-09-07 11:11 ` Borislav Petkov
2020-09-07 11:15 ` Jason A. Donenfeld
2020-09-07 11:23 ` Borislav Petkov
2020-09-08 17:10 ` Srinivas Pandruvada
2020-09-08 17:12 ` Jason A. Donenfeld
2020-09-08 17:25 ` Borislav Petkov
2020-09-08 17:29 ` Jason A. Donenfeld
2020-09-08 17:36 ` Borislav Petkov
2020-09-08 17:42 ` Jason A. Donenfeld
2020-09-08 18:01 ` Borislav Petkov
2020-09-08 19:07 ` Jason A. Donenfeld
2020-09-08 19:18 ` Sultan Alsawaf
2020-09-08 19:30 ` Borislav Petkov
2020-09-08 20:35 ` Andy Lutomirski
2020-09-08 22:32 ` Matthew Garrett
2020-09-09 23:56 ` Andy Lutomirski
2020-09-09 1:02 ` Srinivas Pandruvada
2020-09-10 0:08 ` Andy Lutomirski [this message]
2020-10-19 17:15 ` Borislav Petkov
2020-10-20 17:21 ` Srinivas Pandruvada
2020-10-20 17:47 ` Borislav Petkov
2020-10-20 18:40 ` Srinivas Pandruvada
2020-10-20 19:40 ` Dave Hansen
2020-10-21 13:11 ` Srinivas Pandruvada
2020-10-22 19:28 ` Borislav Petkov
2020-10-21 13:24 ` Peter Zijlstra
2020-09-08 17:31 ` 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=CALCETrWAa+WogyaZ+XGsVxQ+3-j3C+VoQnRWz8L+FUgRpY7nfw@mail.gmail.com \
--to=luto@kernel.org \
--cc=Jason@zx2c4.com \
--cc=bp@alien8.de \
--cc=kitsunyan@airmail.cc \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=sultan@kerneltoast.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).