lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1810011741070.32062@nanos.tec.linutronix.de>
Date:   Mon, 1 Oct 2018 18:11:59 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Alexey Budankov <alexey.budankov@...ux.intel.com>
cc:     Jann Horn <jannh@...gle.com>, Andi Kleen <ak@...ux.intel.com>,
        Mark Rutland <mark.rutland@....com>, tursulin@...ulin.net,
        kernel list <linux-kernel@...r.kernel.org>,
        tvrtko.ursulin@...ux.intel.com,
        Peter Zijlstra <peterz@...radead.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        "H . Peter Anvin" <hpa@...or.com>, acme@...nel.org,
        alexander.shishkin@...ux.intel.com, jolsa@...hat.com,
        namhyung@...nel.org, maddy@...ux.vnet.ibm.com,
        Kees Cook <keescook@...omium.org>
Subject: Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting)

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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ