Hi,
On 03.10.2018 20:01, Jann Horn wrote:
> On Mon, Oct 1, 2018 at 10:53 PM Alexey Budankov
> wrote:
>> 3. Every time an event for ${PMU} is created over perf_event_open():
>>a) the calling thread's euid is checked to belong to ${PMU}_users group
>> and if it does then the event's fd
Hi,
On 03.10.2018 20:01, Jann Horn wrote:
> On Mon, Oct 1, 2018 at 10:53 PM Alexey Budankov
> wrote:
>> 3. Every time an event for ${PMU} is created over perf_event_open():
>>a) the calling thread's euid is checked to belong to ${PMU}_users group
>> and if it does then the event's fd
On Mon, Oct 1, 2018 at 10:53 PM Alexey Budankov
wrote:
> On 01.10.2018 19:11, Thomas Gleixner wrote:
> > 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
On Mon, Oct 1, 2018 at 10:53 PM Alexey Budankov
wrote:
> On 01.10.2018 19:11, Thomas Gleixner wrote:
> > 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
Hello,
On 02.10.2018 9:40, Thomas Gleixner wrote:
>
> Not only the user group, it really should do the full security checks which
> are done on open().
I expect it is already implemented by some internal kernel API so that
it could be reused.
>
>>b) then traditional checks against
Hello,
On 02.10.2018 9:40, Thomas Gleixner wrote:
>
> Not only the user group, it really should do the full security checks which
> are done on open().
I expect it is already implemented by some internal kernel API so that
it could be reused.
>
>>b) then traditional checks against
Alexey,
On Mon, 1 Oct 2018, Alexey Budankov wrote:
> > 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
Alexey,
On Mon, 1 Oct 2018, Alexey Budankov wrote:
> > 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
Hello,
On 01.10.2018 19:11, Thomas Gleixner wrote:
> 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
Hello,
On 01.10.2018 19:11, Thomas Gleixner wrote:
> 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
On Mon, Oct 1, 2018 at 6:12 PM Thomas Gleixner wrote:
> 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.
(That was Mark's idea, not mine, I
On Mon, Oct 1, 2018 at 6:12 PM Thomas Gleixner wrote:
> 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.
(That was Mark's idea, not mine, I
Alexey,
On Mon, 1 Oct 2018, Alexey Budankov wrote:
> > On Fri, Sep 28, 2018 at 11:22:37PM +0200, Jann Horn wrote:
> >>
> >> 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
Alexey,
On Mon, 1 Oct 2018, Alexey Budankov wrote:
> > On Fri, Sep 28, 2018 at 11:22:37PM +0200, Jann Horn wrote:
> >>
> >> 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
Hello Jann and Kees,
On 29.09.2018 1:02, Jann Horn wrote:
> Ah, I guess the answer is "0", since you want to see data about what
> other users are doing.
>
> Does the i915 PMU expose sampling events, counting events, or both?
> The thing about sampling events is that they AFAIK always let the
Hello Jann and Kees,
On 29.09.2018 1:02, Jann Horn wrote:
> Ah, I guess the answer is "0", since you want to see data about what
> other users are doing.
>
> Does the i915 PMU expose sampling events, counting events, or both?
> The thing about sampling events is that they AFAIK always let the
Hello Jann,
> On Fri, Sep 28, 2018 at 11:22:37PM +0200, Jann Horn wrote:
>>
>>
>> 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
Hello Jann,
> On Fri, Sep 28, 2018 at 11:22:37PM +0200, Jann Horn wrote:
>>
>>
>> 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
Hello,
On 28.09.2018 21:20, Thomas Gleixner wrote:
> Start with something like Documentation/admin-guide/perf-security.rst or
> whatever name fits better and add a proper documentation for the existing
> knob. With the infrastructure for fine grained access control add the
> general explanation
Hello,
On 28.09.2018 21:20, Thomas Gleixner wrote:
> Start with something like Documentation/admin-guide/perf-security.rst or
> whatever name fits better and add a proper documentation for the existing
> knob. With the infrastructure for fine grained access control add the
> general explanation
On Fri, 28 Sep 2018, Andi Kleen wrote:
> > > 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
On Fri, 28 Sep 2018, Andi Kleen wrote:
> > > 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
On Fri, 28 Sep 2018, Andi Kleen wrote:
> So there isn't a single answer, and that is why it is important
> that this if configurable.
I said clearly that I'm not opposed against making it configurable. But
because there is no single answer, it's even more important to have proper
documentation.
On Fri, 28 Sep 2018, Andi Kleen wrote:
> So there isn't a single answer, and that is why it is important
> that this if configurable.
I said clearly that I'm not opposed against making it configurable. But
because there is no single answer, it's even more important to have proper
documentation.
On Fri, Sep 28, 2018 at 5:12 PM Jann Horn wrote:
>
> On Fri, Sep 28, 2018 at 3:22 PM Tvrtko Ursulin
> wrote:
> > On 28/09/2018 11:26, Thomas Gleixner wrote:
> > > On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
> > >> For situations where sysadmins might want to allow different level of
> > >> access
On Fri, Sep 28, 2018 at 5:12 PM Jann Horn wrote:
>
> On Fri, Sep 28, 2018 at 3:22 PM Tvrtko Ursulin
> wrote:
> > On 28/09/2018 11:26, Thomas Gleixner wrote:
> > > On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
> > >> For situations where sysadmins might want to allow different level of
> > >> access
On Fri, Sep 28, 2018 at 11:22:37PM +0200, Jann Horn wrote:
> On Fri, Sep 28, 2018 at 10:59 PM Andi Kleen wrote:
> > > > 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
On Fri, Sep 28, 2018 at 11:22:37PM +0200, Jann Horn wrote:
> On Fri, Sep 28, 2018 at 10:59 PM Andi Kleen wrote:
> > > > 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
On Fri, Sep 28, 2018 at 10:59 PM Andi Kleen wrote:
> > > 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
On Fri, Sep 28, 2018 at 10:59 PM Andi Kleen wrote:
> > > 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
> > 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
> > 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
On Fri, Sep 28, 2018 at 10:49 PM Andi Kleen 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
On Fri, Sep 28, 2018 at 10:49 PM Andi Kleen 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
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
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
> Right now we have a single knob, which is poorly documented and that should
> be fixed first. But some googling gives you the information that allowing
> unprivilegded access is a security risk. So the security focussed sysadmin
Ah only if google could simply answer all our questions!
> will
> Right now we have a single knob, which is poorly documented and that should
> be fixed first. But some googling gives you the information that allowing
> unprivilegded access is a security risk. So the security focussed sysadmin
Ah only if google could simply answer all our questions!
> will
Alexey,
On Fri, 28 Sep 2018, Alexey Budankov wrote:
> On 28.09.2018 17:02, Thomas Gleixner wrote:
> > But this does also require a proper analysis and documentation why it is
> > not a security risk to expose the i915 PMU or what potential security
> > issues this can create, so that the
Alexey,
On Fri, 28 Sep 2018, Alexey Budankov wrote:
> On 28.09.2018 17:02, Thomas Gleixner wrote:
> > But this does also require a proper analysis and documentation why it is
> > not a security risk to expose the i915 PMU or what potential security
> > issues this can create, so that the
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
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
> 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
> 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
On Fri, Sep 28, 2018 at 12:26:52PM +0200, Thomas Gleixner wrote:
> On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
>
> It would be very helpful if you cc all involved people on the cover letter
> instead of just cc'ing your own pile of email addresses. CC'ed now.
>
> > For situations where sysadmins
On Fri, Sep 28, 2018 at 12:26:52PM +0200, Thomas Gleixner wrote:
> On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
>
> It would be very helpful if you cc all involved people on the cover letter
> instead of just cc'ing your own pile of email addresses. CC'ed now.
>
> > For situations where sysadmins
Hello,
On 28.09.2018 17:02, Thomas Gleixner wrote:
> Tvrtko,
>
> On Fri, 28 Sep 2018, Tvrtko Ursulin wrote:
>> On 28/09/2018 11:26, Thomas Gleixner wrote:
>>> On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
>>>
>>> It would be very helpful if you cc all involved people on the cover letter
>>> instead
Hello,
On 28.09.2018 17:02, Thomas Gleixner wrote:
> Tvrtko,
>
> On Fri, 28 Sep 2018, Tvrtko Ursulin wrote:
>> On 28/09/2018 11:26, Thomas Gleixner wrote:
>>> On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
>>>
>>> It would be very helpful if you cc all involved people on the cover letter
>>> instead
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
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
On Fri, Sep 28, 2018 at 3:22 PM Tvrtko Ursulin
wrote:
> On 28/09/2018 11:26, Thomas Gleixner wrote:
> > On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
> >> For situations where sysadmins might want to allow different level of
> >> access control for different PMUs, we start creating per-PMU
> >>
On Fri, Sep 28, 2018 at 3:22 PM Tvrtko Ursulin
wrote:
> On 28/09/2018 11:26, Thomas Gleixner wrote:
> > On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
> >> For situations where sysadmins might want to allow different level of
> >> access control for different PMUs, we start creating per-PMU
> >>
On 28/09/2018 15:02, Thomas Gleixner wrote:
Tvrtko,
On Fri, 28 Sep 2018, Tvrtko Ursulin wrote:
On 28/09/2018 11:26, Thomas Gleixner wrote:
On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
It would be very helpful if you cc all involved people on the cover letter
instead of just cc'ing your own
On 28/09/2018 15:02, Thomas Gleixner wrote:
Tvrtko,
On Fri, 28 Sep 2018, Tvrtko Ursulin wrote:
On 28/09/2018 11:26, Thomas Gleixner wrote:
On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
It would be very helpful if you cc all involved people on the cover letter
instead of just cc'ing your own
Tvrtko,
On Fri, 28 Sep 2018, Tvrtko Ursulin wrote:
> On 28/09/2018 11:26, Thomas Gleixner wrote:
> > On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
> >
> > It would be very helpful if you cc all involved people on the cover letter
> > instead of just cc'ing your own pile of email addresses. CC'ed
Tvrtko,
On Fri, 28 Sep 2018, Tvrtko Ursulin wrote:
> On 28/09/2018 11:26, Thomas Gleixner wrote:
> > On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
> >
> > It would be very helpful if you cc all involved people on the cover letter
> > instead of just cc'ing your own pile of email addresses. CC'ed
Hi,
On 28/09/2018 11:26, Thomas Gleixner wrote:
Tvrtko,
On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
It would be very helpful if you cc all involved people on the cover letter
instead of just cc'ing your own pile of email addresses. CC'ed now.
I accept it was by bad to miss adding Cc's on
Hi,
On 28/09/2018 11:26, Thomas Gleixner wrote:
Tvrtko,
On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
It would be very helpful if you cc all involved people on the cover letter
instead of just cc'ing your own pile of email addresses. CC'ed now.
I accept it was by bad to miss adding Cc's on
Tvrtko,
On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
It would be very helpful if you cc all involved people on the cover letter
instead of just cc'ing your own pile of email addresses. CC'ed now.
> For situations where sysadmins might want to allow different level of
> access control for
Tvrtko,
On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
It would be very helpful if you cc all involved people on the cover letter
instead of just cc'ing your own pile of email addresses. CC'ed now.
> For situations where sysadmins might want to allow different level of
> access control for
From: Tvrtko Ursulin
For situations where sysadmins might want to allow different level of
access control for different PMUs, we start creating per-PMU
perf_event_paranoid controls in sysfs.
These work in equivalent fashion as the existing perf_event_paranoid
sysctl, which now becomes the
From: Tvrtko Ursulin
For situations where sysadmins might want to allow different level of
access control for different PMUs, we start creating per-PMU
perf_event_paranoid controls in sysfs.
These work in equivalent fashion as the existing perf_event_paranoid
sysctl, which now becomes the
62 matches
Mail list logo
