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 +, Mcfadden, Marty Jay wrote:
> >> The examples provided were to address why bit-level access granularity
> >> was needed. They were not intended
On 2/29/16, 3:41 PM, "Borislav Petkov" wrote:
>On Mon, Feb 29, 2016 at 10:35:12PM +, 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
On 3/1/16, 12:02 AM, "Thomas Gleixner" wrote:
>
>Your whitelist filter is just a sloppy hack to foster bad practices. Your
>arguments about emerging technologies etc. are just trying to lull us into
>accepting your wonderful hackery, so that you can continue to use MSRs in
>production environm
On Tue, Mar 01, 2016 at 06:29:59PM +, Rountree, Barry L. wrote:
> ... And we can provide this access on production machines without
> risking inadvertent or malicious scribbling on non-benign MSRs. And we
> can do this with one simple, straightforward kernel module.
So you can simply keep tha
On Mon, 29 Feb 2016, Mcfadden, Marty Jay wrote:
> This is precisely why the whitelist approach is being proposed. The current
> version of msr.ko will gladly allow userspace tools with capabilities set to
> scribble all over them. With whitelists, system admins can turn off
> capabilities for the
On Mon, Feb 29, 2016 at 10:35:12PM +, 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 implementat
> From: Borislav Petkov [mailto:b...@alien8.de]
> Sent: Monday, February 29, 2016 10:21 AM
> To: George Spelvin
>
> From a quick look, the stuff in the examples was already in the rapl driver.
>
The examples provided were to address why bit-level access granularity
was needed. They were not int
On Mon, Feb 29, 2016 at 12:53:18PM -0500, George Spelvin wrote:
> I worry that this is this too ambitious a goal. Who is volunteering
> to actually do this?
>From a quick look, the stuff in the examples was already in the rapl
driver.
> It takes quite a while to find a good OS-level abstraction
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
On Mon, Feb 29, 2016 at 01:31:44PM -0300, Henrique de Moraes Holschuh wrote:
> Fully agreed. That said, it would be nice to have a patchset (intended
> mostly for stable/LTS backporting) that restricts MSR access to a *static*
> whitelist that allows only the minimal access required by the current
On Feb 28, 2016 6:55 PM, "Mcfadden, Marty Jay" wrote:
>
> > On Sun, Feb 28, 2016, Borislav Petkov wrote:
> >
> > Can we have some concrete examples for that please?
> >
>
> Our environment allows users to have exclusive access to some
> number of compute nodes for a limited time. Bit-level contr
On Mon, 29 Feb 2016, Borislav Petkov wrote:
> What you want to achieve can be implemented - if it hasn't happened
> already - in the already supplied drivers (rapl, x86_energy_perf_policy,
> etc).
>
> Then, instead of filtering access to MSRs, we should not allow any
> non-OS controlled access to
On Mon, Feb 29, 2016 at 02:55:43AM +, Mcfadden, Marty Jay wrote:
> Our environment allows users to have exclusive access to some
> number of compute nodes for a limited time. Bit-level control of
> MSRs is required when a user might gain root or, more commonly,
> interfere with subsequent jobs
> On Sun, Feb 28, 2016, Borislav Petkov wrote:
>
> Can we have some concrete examples for that please?
>
Our environment allows users to have exclusive access to some
number of compute nodes for a limited time. Bit-level control of
MSRs is required when a user might gain root or, more commonl
On Sun, Feb 28, 2016 at 06:54:47PM +, Mcfadden, Marty Jay wrote:
> Further, system administrators need the ability to grant/deny MSR read
> and/or write access at bit-level granularity for some of the MSRs in order
> to maintain imposed security policies for their respective deployments.
Can w
> * Ingo Molnar [mailto:mingo.kernel@gmail.com] wrote:
>
> No, we really don't want to touch the old MSR code - it's a very opaque API
> with
> various deep limitations.
>
> What I'd like to see instead is to use a modern system monitoring interface -
> and
> in fact that already happened i
* Marty McFadden wrote:
>
> This patch addresses the following two problems:
> 1. The current msr module grants all-or-nothing access to MSRs,
> thus making user-level runtime performance adjustments
> problematic, particularly for power-constrained HPC systems.
>
> 2. The curre
17 matches
Mail list logo
