Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756080AbcCCAkq (ORCPT ); Wed, 2 Mar 2016 19:40:46 -0500 Received: from mail-oi0-f44.google.com ([209.85.218.44]:34255 "EHLO mail-oi0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755512AbcCCAkp (ORCPT ); Wed, 2 Mar 2016 19:40:45 -0500 MIME-Version: 1.0 In-Reply-To: References: <20160229145859.GA3724@pd.tnic> <20160229175318.14183.qmail@ns.horizon.com> <20160229182047.GD3724@pd.tnic> <20160229234125.GJ3724@pd.tnic> From: Andy Lutomirski Date: Wed, 2 Mar 2016 16:40:24 -0800 Message-ID: Subject: Re: [PATCH 0/4] MSR: MSR: MSR Whitelist and Batch Introduction To: "Rountree, Barry L." Cc: Ingo Molnar , Brian Gerst , "x86@kernel.org" , Borislav Petkov , "len.brown@intel.com" , "dan.j.williams@intel.com" , George Spelvin , "mingo@kernel.org" , "dyoung@redhat.com" , "acme@infradead.org" , "yu.c.chen@intel.com" , "ak@linux.intel.com" , "Eastep, Jonathan M" , "viro@zeniv.linux.org.uk" , "jolsa@redhat.com" , "tglx@linutronix.de" , "hpa@zytor.com" , "pavel@ucw.cz" , "Mcfadden, Marty Jay" , "andriy.shevchenko@linux.intel.com" , "a.p.zijlstra@chello.nl" , Travis Gummels , "linux-kernel@vger.kernel.org" , Prarit Bhargava Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3558 Lines: 83 On Mar 1, 2016 11:01 AM, "Rountree, Barry L." wrote: > > > > 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. How about a userspace + msr.ko implementation with no kernel changes whatsoever? We're not talking about a lot of code here. > > > > >> 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). Then configure the existing code correctly. Step 1: Only root gets access to /dev/msr Step 2: Your semi-privileged users get access to a user daemon or CUSE device or whatever that implements your security policy Step 3: Remember not to complain upstream if your MSR write breaks things. Which reminds me: we should probably create a rather limited (maybe even empty) list of MSRs that may be written via /dev/msr without tainting the kernel. > > > >> 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. Why exactly can't msr.ko be used in production? Remember, you're already claiming that you believe that certain MSRs are okay to poke behind the kernel's back. --Andy