Messages in this thread | | | From | Jann Horn <> | Date | Fri, 28 Sep 2018 22:54:05 +0200 | Subject | Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting) |
| |
On Fri, Sep 28, 2018 at 10:49 PM Andi Kleen <ak@linux.intel.com> wrote: > > On Fri, Sep 28, 2018 at 06:40:17PM +0100, Mark Rutland wrote: > > On Fri, Sep 28, 2018 at 10:23:40AM -0700, Andi Kleen wrote: > > > > There's also been prior discussion on these feature in other contexts > > > > (e.g. android expoits resulting from out-of-tree drivers). It would be > > > > nice to see those considered. > > > > > > > > IIRC The conclusion from prior discussions (e.g. [1]) was that we wanted > > > > finer granularity of control such that we could limit PMU access to > > > > specific users -- e.g. disallow arbitrary android apps from poking *any* > > > > PMU, while allowing some more trusted apps/users to uses *some* specific > > > > PMUs. > > > > > > > > e.g. we could add /sys/bus/event_source/devices/${PMU}/device, protect > > > > this via the usual fs ACLs, and pass the fd to perf_event_open() > > > > somehow. A valid fd would act as a capability, taking precedence over > > > > perf_event_paranoid. > > > > > > That sounds like an orthogonal feature. I don't think the original > > > patchkit would need to be hold up for this. It would be something > > > in addition. > > > > I have to say that I disagree -- these controls will have to interact > > somehow, and the fewer of them we have, the less complexity we'll have > > to deal with longer-term. > > You're proposing to completely redesign perf_event_open.
And I think it would be a very good redesign. :) I love things that use file descriptors to represent capabilities.
> This new file descriptor argument doesn't exist today so it would > need to create a new system call with more arguments
Is that true? The first argument is a pointer to a struct that contains its own size, so it can be expanded without an ABI break. I don't see any reason why you couldn't cram more stuff in there.
> (and BTW it would be more than the normal 6 argument limit > we have, so actually it couldn't even be a standard sycall) > > Obviously we would need to keep the old system call around > for compability, so you would need to worry about this > interaction in any case! > > So tying it together doesn't make any sense, because > the problem has to be solved separately anyways. > > > > > > BTW can't you already do that with the syscall filter? I assume > > > the Android sandboxes already use that. Just forbid perf_event_open > > > for the apps. > > > > Note that this was about providing access to *some* PMUs in some cases. > > > > IIUC, if that can be done today via a syscall filter, the same is true > > of per-pmu paranoid settings. > > The difference is that the Android sandboxes likely already doing this > and have all the infrastructure, and it's just another rule. > > Requiring syscall filters just to use the PMU on xn system > that otherwise doesn't need them would be very odd. > > -Andi
| |