Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753803AbcCATBh (ORCPT ); Tue, 1 Mar 2016 14:01:37 -0500 Received: from prdiron-3.llnl.gov ([128.15.143.173]:30665 "EHLO prdiron-3.llnl.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752875AbcCATBf convert rfc822-to-8bit (ORCPT ); Tue, 1 Mar 2016 14:01:35 -0500 X-Attachments: From: "Rountree, Barry L." To: "linux-kernel@vger.kernel.org" CC: George Spelvin , "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" , "luto@kernel.org" , "Mcfadden, Marty Jay" , "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" , Borislav Petkov , "Eastep, Jonathan M" , Prarit Bhargava , "len.brown@intel.com" , "Travis Gummels" Subject: Re: [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction Thread-Topic: [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction Thread-Index: AQHRc+zFRnvKo5tdB0qq1qxau7bTOw== Date: Tue, 1 Mar 2016 19:01:33 +0000 Message-ID: References: <20160229145859.GA3724@pd.tnic> <20160229175318.14183.qmail@ns.horizon.com> <20160229182047.GD3724@pd.tnic> <20160229234125.GJ3724@pd.tnic> In-Reply-To: <20160229234125.GJ3724@pd.tnic> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [128.15.244.136] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3639 Lines: 84 On 2/29/16, 3:41 PM, "Borislav Petkov" wrote: >On Mon, Feb 29, 2016 at 10:35:12PM +0000, Mcfadden, Marty Jay wrote: >> The examples provided were to address why bit-level access granularity >> was needed. They were not intended to be, nor are they, a >>comprehensive list >> of scenarios. > >So which scenarios cannot be satisfied by proper implementation of >userspace APIs (sysfs, procfs, etc) and direct access to MSRs is the >only way? All of them can *eventually* be implemented with userspace APIs. But that process can take years. We had an early version of msr-safe allowing whitelisted RAPL access in 2012. I don't think a RAPL driver hit linux mainline until 2015. One way of getting more resources into "proper implementations" is by showing how usefulness of the userspace + msr-safe implementation. > >> What is being proposed is to make msr.ko better with a whitelist which >> does not allow access to any MSRs be default unless you are root or >> are a user with the appropriate capability (which is how it works >> today). > >That doesn't protect you from mistakenly configuring the wrong mask, as >root. A well-defined userspace interface does. No userspace interface will protect you from mistaken configurations as root. You can mitigate the mistakes by making the defaults sane (the default here is no userspace access at all) and by making inadvertent errors unlikely (it's unlikely that root will edit the whitelist by mistake; if it happens it still needs to be echoed into the whilelist file; any invalid line invalidates the entire whitelist and puts the system back into no-userspace-access mode). > >Also, as I hinted at before, you have cases where other drivers >and modules access the same MSRs as msr.ko and for that you need >synchronization. Which would then need to be added. But we're going >to be stuck with this wrong interface already and we then would be >*extending* that wrong interface. No thanks. Synchronization wasn't provided by msr.ko and that doesn't appear to have caused any problems. If synchronization is a problem, it's easy enough to remove the offending MSR from the whitelist. > >> System Administrators can then selectively add entries to the whitelist >> to allow userspace applications access to specified bits of specific >>MSRs >> of interest. This can all be done on emerging hardware before new >> updates or interfaces are added to the kernel. > >Emerging hardware uses specialized hw bringup software - not the >upstream kernel. Or it is a heavily patched beyond recognition ancient >upstream kernel. And to that kernel people can do whatever they want. Absolutely. The problem we're trying to solve is that msr.ko shouldn't be used on production machines. However, our users want the capabilities provided by new MSRs well before they show up in mainline. msr-safe is the best solution we've come up with. We do far less kernel patching (which our security folks really appreciate), users can't inadvertently trash the machine (which our sysadmins appreciate) and our users get access to new processor functionality on production machines. > >> Keeping msr.ko around and adding a whitelist mechanism will provide a >> safe means for developers to experiment with MSR sets in their to >> squeeze out performance and power and possibly inform future features >> of modules like the rapl driver. > >This can be done with msr.ko now too. The security model for msr.ko is all-or-nothing. That's not a sane choice for production environments. Barry Rountree Center for Applied Scientific Computing Lawrence Livermore National Laboratory