On Fri, Oct 11, 2019 at 09:05:43AM +0200, Peter Zijlstra wrote:
> On Thu, Oct 10, 2019 at 02:31:14PM -0400, Joel Fernandes wrote:
> > On Thu, Oct 10, 2019 at 07:09:49PM +0200, Peter Zijlstra wrote:
>
> > > Yes, I did notice, I found it weird.
> > >
> > > If you have CAP_IPC_LIMIT you should be
On Thu, Oct 10, 2019 at 02:31:14PM -0400, Joel Fernandes wrote:
> On Thu, Oct 10, 2019 at 07:09:49PM +0200, Peter Zijlstra wrote:
> > Yes, I did notice, I found it weird.
> >
> > If you have CAP_IPC_LIMIT you should be able to bust mlock memory
> > limits, so I don't see why we should further
On Thu, 10 Oct 2019, Casey Schaufler wrote:
> > Because it is not necessary.
>
> The logic escapes me, but OK.
We should only extend the stacking infrastructure to what is concretely
required. We don't yet have a use-case for stacking perf_event so we
should keep the code as simple as
On Thu, Oct 10, 2019 at 07:09:49PM +0200, Peter Zijlstra wrote:
> On Thu, Oct 10, 2019 at 11:13:33AM -0400, Joel Fernandes wrote:
> > On Thu, Oct 10, 2019 at 10:12:51AM +0200, Peter Zijlstra wrote:
> > > +static inline int perf_allow_tracepoint(struct perf_event_attr *attr)
> > > {
> > > - return
On 10/9/2019 7:44 PM, James Morris wrote:
> On Wed, 9 Oct 2019, Casey Schaufler wrote:
>
>> On 10/9/2019 3:14 PM, James Morris wrote:
>>> On Wed, 9 Oct 2019, Casey Schaufler wrote:
>>>
Please consider making the perf_alloc security blob maintained
by the infrastructure rather than the
On Thu, Oct 10, 2019 at 11:13:33AM -0400, Joel Fernandes wrote:
> On Thu, Oct 10, 2019 at 10:12:51AM +0200, Peter Zijlstra wrote:
> > +static inline int perf_allow_tracepoint(struct perf_event_attr *attr)
> > {
> > - return sysctl_perf_event_paranoid > 1;
> > + if (sysctl_perf_event_paranoid
On Thu, Oct 10, 2019 at 10:12:51AM +0200, Peter Zijlstra wrote:
> On Wed, Oct 09, 2019 at 04:36:57PM -0400, Joel Fernandes (Google) wrote:
> > In currentl mainline, the degree of access to perf_event_open(2) system
> > call depends on the perf_event_paranoid sysctl. This has a number of
> >
On Wed, Oct 09, 2019 at 04:36:57PM -0400, Joel Fernandes (Google) wrote:
> In currentl mainline, the degree of access to perf_event_open(2) system
> call depends on the perf_event_paranoid sysctl. This has a number of
> limitations:
>
> 1. The sysctl is only a single value. Many types of
Hi Joel,
Thanks for the patch.
On 09.10.2019 23:36, Joel Fernandes (Google) wrote:
> In currentl mainline, the degree of access to perf_event_open(2) system
> call depends on the perf_event_paranoid sysctl. This has a number of
> limitations:
>
> 1. The sysctl is only a single value. Many
On Wed, 9 Oct 2019, Casey Schaufler wrote:
> On 10/9/2019 3:14 PM, James Morris wrote:
> > On Wed, 9 Oct 2019, Casey Schaufler wrote:
> >
> >> Please consider making the perf_alloc security blob maintained
> >> by the infrastructure rather than the individual modules. This
> >> will save it
On 10/9/2019 5:40 PM, Joel Fernandes wrote:
> On Wed, Oct 09, 2019 at 03:41:56PM -0700, Casey Schaufler wrote:
>> On 10/9/2019 3:14 PM, James Morris wrote:
>>> On Wed, 9 Oct 2019, Casey Schaufler wrote:
>>>
Please consider making the perf_alloc security blob maintained
by the
On Thu, Oct 10, 2019 at 09:11:39AM +1100, James Morris wrote:
> On Wed, 9 Oct 2019, Joel Fernandes (Google) wrote:
>
> >
> > +#ifdef CONFIG_SECURITY
> > + err = security_perf_event_alloc(event);
> > + if (err)
> > + goto err_security;
> > +#endif
>
> You should not need this
On Wed, Oct 09, 2019 at 03:41:56PM -0700, Casey Schaufler wrote:
> On 10/9/2019 3:14 PM, James Morris wrote:
> > On Wed, 9 Oct 2019, Casey Schaufler wrote:
> >
> >> Please consider making the perf_alloc security blob maintained
> >> by the infrastructure rather than the individual modules. This
>
On 10/9/2019 3:14 PM, James Morris wrote:
> On Wed, 9 Oct 2019, Casey Schaufler wrote:
>
>> Please consider making the perf_alloc security blob maintained
>> by the infrastructure rather than the individual modules. This
>> will save it having to be changed later.
> Is anyone planning on using
On Wed, 9 Oct 2019, Casey Schaufler wrote:
> Please consider making the perf_alloc security blob maintained
> by the infrastructure rather than the individual modules. This
> will save it having to be changed later.
Is anyone planning on using this with full stacking?
If not, we don't need the
On Wed, 9 Oct 2019, Joel Fernandes (Google) wrote:
>
> +#ifdef CONFIG_SECURITY
> + err = security_perf_event_alloc(event);
> + if (err)
> + goto err_security;
> +#endif
You should not need this ifdef.
> diff --git a/security/security.c b/security/security.c
> index
On 10/9/2019 1:36 PM, Joel Fernandes (Google) wrote:
> In currentl mainline, the degree of access to perf_event_open(2) system
> call depends on the perf_event_paranoid sysctl. This has a number of
> limitations:
>
> 1. The sysctl is only a single value. Many types of accesses are controlled
>
In currentl mainline, the degree of access to perf_event_open(2) system
call depends on the perf_event_paranoid sysctl. This has a number of
limitations:
1. The sysctl is only a single value. Many types of accesses are controlled
based on the single value thus making the control very limited
18 matches
Mail list logo
