Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp4085446pxk; Tue, 8 Sep 2020 10:16:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwOEAAsUsOk4d6RNv40gEOLimjLDZ234zUxRsnjhHWiNatwqmzM1mVCLGL3uKcbuUKWmqou X-Received: by 2002:aa7:c7da:: with SMTP id o26mr28685305eds.261.1599585367212; Tue, 08 Sep 2020 10:16:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599585367; cv=none; d=google.com; s=arc-20160816; b=tEradfy34XUITjtdPf/sMB07n4IkeWiPKdBBu2oiPW/r4Qun+sqbnoZQNLwGq4KBcm 68+eW91wnav5gsqHN42aFuqn1Jzz2SxTqhvPGd+4fJxmgYZECPCe2OjBo4nsRhm78PCj nMBXPc+hsZgL91kcBzTCB7Bi8HV+5XXOTnKO48S0WvsryDzP/D1yqQFv9tnLy/TrchMl O4+aQB5zOG68SeLCsfkHOqPJ66zSVoarvD3GKafqrTAKPqFOe9vY4ELPnda/IKHIm4om JhcEZkm8v2mzBO5oNKjJWH7oQXDXWmcLQ5RB0M0vibGhhh21mnti8xn2qgBqJk4BBQkD gU5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=EbQbipzbs2unOT9Ewo7n6NF0IPdPfUfG0frmkpHwLmY=; b=0feCIdFocsPxj1MV934I/U6QN5rKH8gge+skgN/CP8ZfoWCYj1j16akVBPHnNvoVD/ GmYwAl9CEg/Ljw5QucaZ/dg4RXanUvRxAbFvWvfWvErSWF04kAS8kvFwmsd/uDZiMbf+ fjoXMHd7HmGVqDejge0Zyf3Ia/302a9fHbgrw39wNOB9iZAeS5H232dv/DknnXLrqN4I mlUqNHlFyKvwprbm6zNI4Q8Ekma6MIv12TgNJyPnmglkeEIXgPKUEa+pc/8aP19KifL8 gBCDjjV5MYgiQBgf3wufPX9xOn4w4uVxRJ0f3/e0jWEfLw2yjy1ArCd5cWPjSwiukPSO X5bw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@zx2c4.com header.s=mail header.b=fSSVFqkN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zx2c4.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u26si11846877edv.154.2020.09.08.10.15.44; Tue, 08 Sep 2020 10:16:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@zx2c4.com header.s=mail header.b=fSSVFqkN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zx2c4.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731987AbgIHRNO (ORCPT + 99 others); Tue, 8 Sep 2020 13:13:14 -0400 Received: from mail.zx2c4.com ([192.95.5.64]:52459 "EHLO mail.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726660AbgIHRNE (ORCPT ); Tue, 8 Sep 2020 13:13:04 -0400 Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTP id ec913daf for ; Tue, 8 Sep 2020 16:44:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=zx2c4.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=mail; bh=nYsjvTY+XcGAaXbY+ccHFh7T5nY=; b=fSSVFq kNf41kZKWRzyG8Gc4F8w0kkN+OvbfSHJfCZ7TtZFMsyveek6/hZNvsRMy8BsF7DJ mjSMFWz8Anri/b/GdUixt3ES0wPawOZTB7is3ckAbJ6PayNeMevWdRf9U4Tf392z 16WDh3QOzq9Ugi7uSBW4RjaCdIkGbTRPStTdZzX5DAvSG8m02Q6vGpbhBRQtK9zC xtLkWDT5l9QQlagzqF8OtU7jen63PjShXL3g4kMnPGLjydBWltXKsS7CXrMFfXYx jhHf4qEsaUVFOv/AEl1XIIVLrqfw2ZO3iJi6CUi6b8tD4oQ6XJa1FECSwUaH1ZD5 EKB7l9fVwhikWMhw== Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 351848e7 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Tue, 8 Sep 2020 16:44:03 +0000 (UTC) Received: by mail-io1-f53.google.com with SMTP id r9so147666ioa.2 for ; Tue, 08 Sep 2020 10:12:57 -0700 (PDT) X-Gm-Message-State: AOAM531aQ0/djyoIswT5XXok76kESuMZwVt/LbspYuFnx27nkVFPyd4+ 5x1NeY+pTVrVk1IjRHk2GCcMtdghdoORO2IPMBY= X-Received: by 2002:a6b:b98a:: with SMTP id j132mr21806732iof.67.1599585176932; Tue, 08 Sep 2020 10:12:56 -0700 (PDT) MIME-Version: 1.0 References: <20200907094843.1949-1-Jason@zx2c4.com> <20200907100647.GB10657@zn.tnic> <22617e57e541e460fac09db04fdb370f8e96e8ef.camel@linux.intel.com> In-Reply-To: <22617e57e541e460fac09db04fdb370f8e96e8ef.camel@linux.intel.com> From: "Jason A. Donenfeld" Date: Tue, 8 Sep 2020 19:12:44 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] x86/msr: do not warn on writes to OC_MAILBOX To: Srinivas Pandruvada Cc: Borislav Petkov , kitsunyan , "Brown, Len" , X86 ML , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 8, 2020 at 7:10 PM Srinivas Pandruvada wrote: > > On Mon, 2020-09-07 at 12:06 +0200, Borislav Petkov wrote: > > + Srinivas. > > + kitsunyan. > > > > On Mon, Sep 07, 2020 at 11:48:43AM +0200, Jason A. Donenfeld wrote: > > > Popular tools, like intel-undervolt, use MSR 0x150 to control the > > > CPU > > > voltage offset. In fact, evidently the intel_turbo_max_3 driver in- > > > tree > > > also uses this MSR. So, teach the kernel's MSR list about this, so > > > that > > > intel-undervolt and other such tools don't spew warnings to dmesg, > > > while > > > unifying the constant used throughout the kernel. > > > > > [...] > > > > - if (reg == MSR_IA32_ENERGY_PERF_BIAS) > > > + switch (reg) { > > > + case MSR_IA32_ENERGY_PERF_BIAS: > There is already sysfs interface for it. > > > > + case MSR_IA32_OC_MAILBOX: > > > return 0; > > > + } > > > > > [...] > > > Actually, we added the filtering to catch exactly such misuses and, > > lemme check what is the proper word now... /me checks, aha, adding > > new > > MSRs to the "passlist" is the wrong thing to do. > > > > Srinivas, can you pls convert this in-tree driver to use a proper > > sysfs > > interface for that mailbox MSR and also work with the intel-undervolt > > author - I hope I have the right person CCed from the git repo on > > github > > - to come up with a proper interface so that we can drop this MSR use > > too. > > Overclocking is not architectural I/F and is supported by some special > CPU skews. I can't find any public document to specify the commands > which can be used via this OC mailbox. I have to check internally to > see if there is any. To add a proper sysfs interface we have to make > sure that we are not allowing some random commands to hardware and > crash the system. Well you can definitely crash the system this way -- undervolting can result in all sorts of nice glitching. You might be able to even programmatically undervolt to compromise the kernel in clever ways (a lockdown bypass, I guess, but who cares). That's why I initially suggested this was pretty squarely in the realm of hobbyists and should just be added to that whitelist.