From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752236AbcB2RxV (ORCPT ); Mon, 29 Feb 2016 12:53:21 -0500 Received: from ns.horizon.com ([71.41.210.147]:33886 "HELO ns.horizon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751070AbcB2RxU (ORCPT ); Mon, 29 Feb 2016 12:53:20 -0500 Date: 29 Feb 2016 12:53:18 -0500 Message-ID: <20160229175318.14183.qmail@ns.horizon.com> From: "George Spelvin" To: bp@alien8.de, mcfadden8@llnl.gov Subject: Re: [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction Cc: a.p.zijlstra@chello.nl, acme@infradead.org, ak@linux.intel.com, andriy.shevchenko@linux.intel.com, brgerst@gmail.com, dan.j.williams@intel.com, dyoung@redhat.com, hpa@zytor.com, jolsa@redhat.com, linux-kernel@vger.kernel.org, linux@horizon.com, luto@kernel.org, mingo@kernel.org, mingo@redhat.com, pavel@ucw.cz, tglx@linutronix.de, viro@zeniv.linux.org.uk, x86@kernel.org, yu.c.chen@intel.com In-Reply-To: <20160229145859.GA3724@pd.tnic> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Borislav Petkov wrote: > What should be done, instead, is implement all functionality you need in > the respective drivers with proper error and input sanity-checking done > by the OS. Also, OS has other agents poking at them so it should be the > arbiter controlling access and so on. > > IMNSVHO. I worry that this is this too ambitious a goal. Who is volunteering to actually do this? It takes quite a while to find a good OS-level abstraction (remember wakelocks?), and MSRs are the CPU architect's equivalent of ioctls. So they're a bit of a mess, and there will keep being new ones. I agree with you about anything that's going to see widespread use, but for specialized (apparently mostly HPC) use where the application really is heavily optimized for specific CPU models, perhaps dangerous-but-simple is good enough? The proposed interface is simple and imposes very little maintenance burden on the kernel. My main objection is that it's yet another special-case permission system. Are we *sure* we'll never want to have to classes of users with different access rights?