On 5/22/2017 5:26 PM, Peter Zijlstra wrote:
On Mon, May 22, 2017 at 09:45:30AM +0100, Mark Rutland wrote:
On Mon, May 22, 2017 at 10:12:22AM +0800, Jin, Yao wrote:
But the code is being ugly and hard to maintain. And frankly I don't
know kernel address space for all arch.
Any idea? Could we
On 5/22/2017 5:26 PM, Peter Zijlstra wrote:
On Mon, May 22, 2017 at 09:45:30AM +0100, Mark Rutland wrote:
On Mon, May 22, 2017 at 10:12:22AM +0800, Jin, Yao wrote:
But the code is being ugly and hard to maintain. And frankly I don't
know kernel address space for all arch.
Any idea? Could we
On Mon, May 22, 2017 at 09:45:30AM +0100, Mark Rutland wrote:
> On Mon, May 22, 2017 at 10:12:22AM +0800, Jin, Yao wrote:
> > But the code is being ugly and hard to maintain. And frankly I don't
> > know kernel address space for all arch.
> >
> > Any idea? Could we just do at x86 side this time?
On Mon, May 22, 2017 at 09:45:30AM +0100, Mark Rutland wrote:
> On Mon, May 22, 2017 at 10:12:22AM +0800, Jin, Yao wrote:
> > But the code is being ugly and hard to maintain. And frankly I don't
> > know kernel address space for all arch.
> >
> > Any idea? Could we just do at x86 side this time?
On Mon, May 22, 2017 at 10:12:22AM +0800, Jin, Yao wrote:
> Hi Peter,
>
> Maybe it's not very easy to move the skid checking to generic code
> because we don't have a common kernel_ip() available to determine if
> ip is a kernel address.
>
> I was trying to move kernel_ip() from
On Mon, May 22, 2017 at 10:12:22AM +0800, Jin, Yao wrote:
> Hi Peter,
>
> Maybe it's not very easy to move the skid checking to generic code
> because we don't have a common kernel_ip() available to determine if
> ip is a kernel address.
>
> I was trying to move kernel_ip() from
On 5/19/2017 9:33 PM, Jin, Yao wrote:
On 5/19/2017 8:36 PM, Peter Zijlstra wrote:
On Fri, May 19, 2017 at 08:24:19PM +0800, Jin, Yao wrote:
Ah, I was more thinking of something like PERF_PMU_CAP_NO_SKID or
something that would skip the test and preserve current behaviour.
OK, I understand
On 5/19/2017 9:33 PM, Jin, Yao wrote:
On 5/19/2017 8:36 PM, Peter Zijlstra wrote:
On Fri, May 19, 2017 at 08:24:19PM +0800, Jin, Yao wrote:
Ah, I was more thinking of something like PERF_PMU_CAP_NO_SKID or
something that would skip the test and preserve current behaviour.
OK, I understand
On 5/19/2017 8:36 PM, Peter Zijlstra wrote:
On Fri, May 19, 2017 at 08:24:19PM +0800, Jin, Yao wrote:
Ah, I was more thinking of something like PERF_PMU_CAP_NO_SKID or
something that would skip the test and preserve current behaviour.
OK, I understand now. For example, for PEBS event, its
On 5/19/2017 8:36 PM, Peter Zijlstra wrote:
On Fri, May 19, 2017 at 08:24:19PM +0800, Jin, Yao wrote:
Ah, I was more thinking of something like PERF_PMU_CAP_NO_SKID or
something that would skip the test and preserve current behaviour.
OK, I understand now. For example, for PEBS event, its
On Fri, May 19, 2017 at 08:24:19PM +0800, Jin, Yao wrote:
> > Ah, I was more thinking of something like PERF_PMU_CAP_NO_SKID or
> > something that would skip the test and preserve current behaviour.
>
> OK, I understand now. For example, for PEBS event, its capabilities should
> be set with
On Fri, May 19, 2017 at 08:24:19PM +0800, Jin, Yao wrote:
> > Ah, I was more thinking of something like PERF_PMU_CAP_NO_SKID or
> > something that would skip the test and preserve current behaviour.
>
> OK, I understand now. For example, for PEBS event, its capabilities should
> be set with
On 5/19/2017 8:10 PM, Peter Zijlstra wrote:
On Fri, May 19, 2017 at 08:06:09PM +0800, Jin, Yao wrote:
SNIP
I would much rather see this in generic code, somewhere around
__perf_event_overflow() I suppose. That would retain proper accounting
for the interrupt rate etc..
Also it would work
On 5/19/2017 8:10 PM, Peter Zijlstra wrote:
On Fri, May 19, 2017 at 08:06:09PM +0800, Jin, Yao wrote:
SNIP
I would much rather see this in generic code, somewhere around
__perf_event_overflow() I suppose. That would retain proper accounting
for the interrupt rate etc..
Also it would work
On Fri, May 19, 2017 at 08:06:09PM +0800, Jin, Yao wrote:
> SNIP
>
> > I would much rather see this in generic code, somewhere around
> > __perf_event_overflow() I suppose. That would retain proper accounting
> > for the interrupt rate etc..
> >
> > Also it would work for all architectures.
On Fri, May 19, 2017 at 08:06:09PM +0800, Jin, Yao wrote:
> SNIP
>
> > I would much rather see this in generic code, somewhere around
> > __perf_event_overflow() I suppose. That would retain proper accounting
> > for the interrupt rate etc..
> >
> > Also it would work for all architectures.
SNIP
I would much rather see this in generic code, somewhere around
__perf_event_overflow() I suppose. That would retain proper accounting
for the interrupt rate etc..
Also it would work for all architectures. Because I'm thinking more than
just x86 will suffer from skid.
Yes, moving to
SNIP
I would much rather see this in generic code, somewhere around
__perf_event_overflow() I suppose. That would retain proper accounting
for the interrupt rate etc..
Also it would work for all architectures. Because I'm thinking more than
just x86 will suffer from skid.
Yes, moving to
On Fri, May 19, 2017 at 11:29:05AM +0200, Peter Zijlstra wrote:
> On Fri, May 19, 2017 at 06:19:12PM +0800, Jin Yao wrote:
> > +bool skid_kernel_samples(struct perf_event *event, struct pt_regs *regs)
> > +{
> > + u64 ip;
> > +
> > + /*
> > +* Without PEBS, we may get kernel samples even
On Fri, May 19, 2017 at 11:29:05AM +0200, Peter Zijlstra wrote:
> On Fri, May 19, 2017 at 06:19:12PM +0800, Jin Yao wrote:
> > +bool skid_kernel_samples(struct perf_event *event, struct pt_regs *regs)
> > +{
> > + u64 ip;
> > +
> > + /*
> > +* Without PEBS, we may get kernel samples even
On Fri, May 19, 2017 at 06:19:12PM +0800, Jin Yao wrote:
> When doing sampling without PEBS
>
> perf record -e cycles:u ...
>
> On workloads that do a lot of kernel entry/exits we see kernel
> samples, even though :u is specified. This is due to skid existing.
>
> This is a security issue
On Fri, May 19, 2017 at 06:19:12PM +0800, Jin Yao wrote:
> When doing sampling without PEBS
>
> perf record -e cycles:u ...
>
> On workloads that do a lot of kernel entry/exits we see kernel
> samples, even though :u is specified. This is due to skid existing.
>
> This is a security issue
When doing sampling without PEBS
perf record -e cycles:u ...
On workloads that do a lot of kernel entry/exits we see kernel
samples, even though :u is specified. This is due to skid existing.
This is a security issue because it can leak kernel addresses even
though kernel sampling support is
When doing sampling without PEBS
perf record -e cycles:u ...
On workloads that do a lot of kernel entry/exits we see kernel
samples, even though :u is specified. This is due to skid existing.
This is a security issue because it can leak kernel addresses even
though kernel sampling support is
24 matches
Mail list logo
