[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <025308CD-6E1A-41E1-8B3D-E9842CE00794@amacapital.net>
Date: Tue, 8 Sep 2020 13:35:18 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Borislav Petkov <bp@...en8.de>, Matthew Garrett <mjg59@...gle.com>,
James Bottomley <James.Bottomley@...senpartnership.com>
Cc: Sultan Alsawaf <sultan@...neltoast.com>,
"Jason A. Donenfeld" <Jason@...c4.com>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.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 Sep 8, 2020, at 12:30 PM, Borislav Petkov <bp@...en8.de> 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.
>
> Srinivas, what's the story here?
>
I have seriously mixed opinions about this.
First, there are really two separate issues here. One is undervolting these parts, and one is the MSR interface.
In my mind, the MSR part is an easy call. Userspace has no more business poking some undocumented mailbox MSR than it does poking any other MSR. We should not give special dispensation here. It should be allowed if the MSR restrictions are off, and otherwise we should warn or forbid it.
Undervolting is a bit different. It’s a genuinely useful configuration that can affect system stability. In general, I think it should be allowed, and it should have a real driver in tree.
But this has a tricky interaction with lockdown. An interface that allows root to destabilize a system may well allow root to escalate privileges. But I think that making lockdown=integrity prevent tuning voltages and such would be quite obnoxious.
Should there perhaps be a separate lockdown bit for stability?
I assume that Intel XTU and such work on Secure-Booted Windows.
Powered by blists - more mailing lists