Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 1 Oct 2018 18:11:59 +0200 (CEST)
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Alexey Budankov <alexey.budankov@linux.intel.com>
cc:     Jann Horn <jannh@google.com>, Andi Kleen <ak@linux.intel.com>,
        Mark Rutland <mark.rutland@arm.com>, tursulin@ursulin.net,
        kernel list <linux-kernel@vger.kernel.org>,
        tvrtko.ursulin@linux.intel.com,
        Peter Zijlstra <peterz@infradead.org>,
        the arch/x86 maintainers <x86@kernel.org>,
        "H . Peter Anvin" <hpa@zytor.com>, acme@kernel.org,
        alexander.shishkin@linux.intel.com, jolsa@redhat.com,
        namhyung@kernel.org, maddy@linux.vnet.ibm.com,
        Kees Cook <keescook@chromium.org>
Subject: Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting)
In-Reply-To: <22155f49-2f57-73b8-6e89-ddd8a127967b@linux.intel.com>
Message-ID: <alpine.DEB.2.21.1810011741070.32062@nanos.tec.linutronix.de>
References: <20180919122751.12439-1-tvrtko.ursulin@linux.intel.com> <alpine.DEB.2.21.1809281151190.2004@nanos.tec.linutronix.de> <20180928164111.i6nba2j6mnegwslw@lakrids.cambridge.arm.com> <20180928172340.GA32651@tassilo.jf.intel.com>
 <20180928174016.i7d24puv7y3jwzf6@lakrids.cambridge.arm.com> <20180928204930.GC32651@tassilo.jf.intel.com> <CAG48ez16ECnLMNggTZQQJOuPK5ZJ8dLSkGDzvxwK1zVh1BFExw@mail.gmail.com> <20180928205907.GD32651@tassilo.jf.intel.com> <CAG48ez1xJ+Y=snnHJ5k6J6O3qqD=bHdjRioLFuzPZpxU9v7xxA@mail.gmail.com>
 <20180928212757.GE32651@tassilo.jf.intel.com> <22155f49-2f57-73b8-6e89-ddd8a127967b@linux.intel.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Alexey,

On Mon, 1 Oct 2018, Alexey Budankov wrote:
> > On Fri, Sep 28, 2018 at 11:22:37PM +0200, Jann Horn wrote:
> >> <blasphemy>
> >> Is that true? IIRC if you want to use the perf tools after a kernel
> >> update, you have to install a new version of perf anyway, no?
> 
> There are usages in production where perf_event_open() syscall 
> accompanied with read(), mmap() etc. is embedded into application 
> on per-thread basis and is used for self monitoring and dynamic 
> execution tuning.
> 
> There are also other Perf tools around that, for example, are 
> statically linked and then used as on Linux as on Android.
> 
> Backward compatibility does matter in these cases.

Well, it's nothing fundamentally new, that new features require changes to
applications, libraries etc. It's nice if it can be avoided of course.

From a design POV, Jann's idea to have a per PMU special file which you
need to open for getting access is way better than the extra knobs. It
allows to use all existing security mechanisms to be used.

Peter and I discussed that and we came up with the idea that the file
descriptor is not even required, i.e. you could make it backward
compatible.

perf_event_open() knows which PMU is associated with the event the caller
tries to open. So perf_event_open() can try to access/open the special per
PMU file on behalf of the caller. That should get the same security
treatment like a regular open() from user space. If that succeeds, access
is granted.

The magic file could still be writeable for root to give general
restrictions aside of the file based ones similar to what you are
proposing.

The analysis and documentation requirements still remain of course.

Thanks,

	tglx