Message-ID: <alpine.DEB.2.21.1809281709350.2004@nanos.tec.linutronix.de>
Date:   Fri, 28 Sep 2018 17:23:52 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>
cc:     Tvrtko Ursulin <tursulin@...ulin.net>,
        LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Madhavan Srinivasan <maddy@...ux.vnet.ibm.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Alexey Budankov <alexey.budankov@...ux.intel.com>,
        Kees Cook <keescook@...omium.org>, Jann Horn <jannh@...gle.com>
Subject: Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting)

Tvrtko,

On Fri, 28 Sep 2018, Tvrtko Ursulin wrote:
> On 28/09/2018 15:02, Thomas Gleixner wrote:
> > > Presumably you see adding fine grained control as diminishing the overall
> > > security rather than raising it? Could you explain why? Because
> > > incompetent
> > > sysadmin will turn it off for some PMU, while without having the
> > > fine-grained
> > > control they wouldn't turn it off globally?
> > 
> > I did not say at all that this might be diminishing security. And the
> > argumentation with 'incompetent sysadmins' is just the wrong attitude.
> 
> Wrong attitude what? I was trying to guess your reasoning (cues in
> "presumably" and a lot of question marks) since it wasn't clear to me why is
> your position what it is.

Guessing my reasonings has nothing to do with you mentioning incompentent
sysadmins.

> > What I was asking for is proper documentation and this proper documentation
> > is meant for _competent_ sysadmins.
> > 
> > That documentation has to clearly describe what kind of information is
> > accessible and what potential side effects security wise this might
> > have. You cannot expect that even competent sysadmins know offhand what
> > which PMU might expose. And telling them 'Use Google' is just not the right
> > thing to do.
> 
> I did not mention Google.

I did not say that you mentioned google. But what is a sysadmin supposed to
do when there is no documentation aside of using google? And not having
documentation is basically the same thing as telling them to use google.

> > If you can't explain and document it, then providing the knob is just
> > fulfilling somebodys 'I want a pony' request.
> 
> Well it's not a pony, it is mechanism to avoid having to turn off all
> security. We can hopefully discuss it without ponies.

If you want to make a pettifogger contest out of this discussion, then we
can stop right here. I explained it technically why just adding a knob
without further explanation and analysis is not acceptable.

> > And the same is required for all other PMUs which can be enabled in the
> > same way for unprivileged access. And we might as well come to the
> > conclusion via analysis that for some PMUs unpriviledged access is just not
> > a good idea and exclude them. I surely know a few which qualify for
> > exclusion, so the right approach is to provide this knob only when the risk
> > is analyzed and documented and the PMU has been flagged as candidate for
> > unpriviledged exposure. I.e. opt in and not opt out.
> 
> I am happy to work on the mechanics of achieving this once the security guys
> and all PMU owners get involved. Even though I am not convinced the bar to
> allow fine-grained control should be evaluating all possible PMUs*, but if the
> security folks agree that is the case it is fine by me.

Making the knob opt in per PMU does not need all PMU owners to be
involved. It allows to add the opt in flag on a case by case basis.

> *) The part of my reply you did not quote explains how the fine-grained
> control improves security in existing deployments. The documentation I added
> refers to the existing perf_event_paranoid documentation for explanation of
> security concerns involved. Which is not much in itself. But essentially we
> both have a PMU and a knob already. I don't see why adding the same knob
> per-PMU needs much more stringent criteria to be accepted. But as said, that's
> for security people to decide.

The fact, that the existing knob is poorly documented does make an excuse
for adding more knobs without documentation. Quite the contrary, if we
notice that the existing knob lacks proper documentation, then we should
fix that first.

Thanks,

	tglx

Powered by blists - more mailing lists