On Tue, Oct 21, 2014 at 2:14 AM, Peter Zijlstra wrote:
> On Mon, Oct 20, 2014 at 12:51:10PM +0200, Hendrik Brueckner wrote:
>> I think it would makes sense to return 0 as default in the
>> perf_event_idx_default() and let each PMU/arch that actually supports
>> reading PMCs from user space return
On Mon, Oct 20, 2014 at 12:51:10PM +0200, Hendrik Brueckner wrote:
> I think it would makes sense to return 0 as default in the
> perf_event_idx_default() and let each PMU/arch that actually supports
> reading PMCs from user space return the proper index. And according
> to tools/perf/design.txt,
On Mon, Oct 20, 2014 at 10:39:48AM -0700, Andy Lutomirski wrote:
> On Mon, Oct 20, 2014 at 9:49 AM, Andy Lutomirski wrote:
> > On Mon, Oct 20, 2014 at 1:33 AM, Peter Zijlstra
> > wrote:
> >> On Sun, Oct 19, 2014 at 03:57:54PM -0700, Andy Lutomirski wrote:
> >>> > Maybe, but at that point we
On Mon, Oct 20, 2014 at 10:39:48AM -0700, Andy Lutomirski wrote:
On Mon, Oct 20, 2014 at 9:49 AM, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Oct 20, 2014 at 1:33 AM, Peter Zijlstra pet...@infradead.org
wrote:
On Sun, Oct 19, 2014 at 03:57:54PM -0700, Andy Lutomirski wrote:
On Mon, Oct 20, 2014 at 12:51:10PM +0200, Hendrik Brueckner wrote:
I think it would makes sense to return 0 as default in the
perf_event_idx_default() and let each PMU/arch that actually supports
reading PMCs from user space return the proper index. And according
to tools/perf/design.txt,
On Tue, Oct 21, 2014 at 2:14 AM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Oct 20, 2014 at 12:51:10PM +0200, Hendrik Brueckner wrote:
I think it would makes sense to return 0 as default in the
perf_event_idx_default() and let each PMU/arch that actually supports
reading PMCs from user
On Mon, Oct 20, 2014 at 9:49 AM, Andy Lutomirski wrote:
> On Mon, Oct 20, 2014 at 1:33 AM, Peter Zijlstra wrote:
>> On Sun, Oct 19, 2014 at 03:57:54PM -0700, Andy Lutomirski wrote:
>>> > Maybe, but at that point we commit to yet another ABI... I'd rather just
>>> > put a 'sane' implementation in
On Mon, Oct 20, 2014 at 1:33 AM, Peter Zijlstra wrote:
> On Sun, Oct 19, 2014 at 03:57:54PM -0700, Andy Lutomirski wrote:
>> > Maybe, but at that point we commit to yet another ABI... I'd rather just
>> > put a 'sane' implementation in a library or so.
>>
>> This cuts both ways, though. For vdso
On Mon, Oct 20, 2014 at 10:48:13AM +0200, Peter Zijlstra wrote:
> On Sun, Oct 19, 2014 at 05:08:08PM -0700, Andy Lutomirski wrote:
> > There are a whole bunch of implementations of that
> > callback:
> >
> > - perf_event_idx_default seems fishy
>
> I suppose I did that to encode the rule that 0
On Mon, 20 Oct 2014 10:48:13 +0200
Peter Zijlstra wrote:
> > - cpumsf_pmu_event_idx is the same as power_pmu_event_idx.
>
> Oh cute, lets ask the s390 people, do you guys have a userspace
> instruction to read the actual counter value?
The "extract cpu counter" ECCTR instruction can be
On Sun, Oct 19, 2014 at 05:08:08PM -0700, Andy Lutomirski wrote:
> Before I totally screw this up: is .event_idx used for anything except
> userspace rdpmc?
It should only be used for that.
> There are a whole bunch of implementations of that
> callback:
>
> - perf_event_idx_default seems
On Sun, Oct 19, 2014 at 03:57:54PM -0700, Andy Lutomirski wrote:
> > Maybe, but at that point we commit to yet another ABI... I'd rather just
> > put a 'sane' implementation in a library or so.
>
> This cuts both ways, though. For vdso timekeeping, the underlying
> data structure has changed
On Sun, Oct 19, 2014 at 03:57:54PM -0700, Andy Lutomirski wrote:
Maybe, but at that point we commit to yet another ABI... I'd rather just
put a 'sane' implementation in a library or so.
This cuts both ways, though. For vdso timekeeping, the underlying
data structure has changed
On Sun, Oct 19, 2014 at 05:08:08PM -0700, Andy Lutomirski wrote:
Before I totally screw this up: is .event_idx used for anything except
userspace rdpmc?
It should only be used for that.
There are a whole bunch of implementations of that
callback:
- perf_event_idx_default seems fishy
I
On Mon, 20 Oct 2014 10:48:13 +0200
Peter Zijlstra pet...@infradead.org wrote:
- cpumsf_pmu_event_idx is the same as power_pmu_event_idx.
Oh cute, lets ask the s390 people, do you guys have a userspace
instruction to read the actual counter value?
The extract cpu counter ECCTR instruction
On Mon, Oct 20, 2014 at 10:48:13AM +0200, Peter Zijlstra wrote:
On Sun, Oct 19, 2014 at 05:08:08PM -0700, Andy Lutomirski wrote:
There are a whole bunch of implementations of that
callback:
- perf_event_idx_default seems fishy
I suppose I did that to encode the rule that 0 :=
On Mon, Oct 20, 2014 at 1:33 AM, Peter Zijlstra pet...@infradead.org wrote:
On Sun, Oct 19, 2014 at 03:57:54PM -0700, Andy Lutomirski wrote:
Maybe, but at that point we commit to yet another ABI... I'd rather just
put a 'sane' implementation in a library or so.
This cuts both ways, though.
On Mon, Oct 20, 2014 at 9:49 AM, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Oct 20, 2014 at 1:33 AM, Peter Zijlstra pet...@infradead.org wrote:
On Sun, Oct 19, 2014 at 03:57:54PM -0700, Andy Lutomirski wrote:
Maybe, but at that point we commit to yet another ABI... I'd rather just
On Sun, Oct 19, 2014 at 2:35 PM, Peter Zijlstra wrote:
> On Thu, Oct 16, 2014 at 05:00:56PM -0700, Andy Lutomirski wrote:
>> The current cap_user_rdpmc code seems rather confused to me. On x86,
>> *all* events set cap_user_rdpmc if the global rdpmc control is set.
>> But only x86_pmu events
On Sun, Oct 19, 2014 at 3:20 PM, Peter Zijlstra wrote:
> On Sun, Oct 19, 2014 at 03:05:42PM -0700, Andy Lutomirski wrote:
>> On Oct 19, 2014 2:33 PM, "Peter Zijlstra" wrote:
>
>> > > Also, I don't understand the purpose of cap_user_time. Wouldn't it be
>> > > easier to just record the last
On Sun, Oct 19, 2014 at 03:05:42PM -0700, Andy Lutomirski wrote:
> On Oct 19, 2014 2:33 PM, "Peter Zijlstra" wrote:
> > > Also, I don't understand the purpose of cap_user_time. Wouldn't it be
> > > easier to just record the last CLOCK_MONOTONIC time and let the user
> > > call
On Oct 19, 2014 2:33 PM, "Peter Zijlstra" wrote:
>
> On Sun, Oct 19, 2014 at 01:23:17PM -0700, Andy Lutomirski wrote:
> > On Thu, Oct 16, 2014 at 5:00 PM, Andy Lutomirski
> > wrote:
> > > The current cap_user_rdpmc code seems rather confused to me. On x86,
> > > *all* events set cap_user_rdpmc
On Thu, Oct 16, 2014 at 05:00:56PM -0700, Andy Lutomirski wrote:
> The current cap_user_rdpmc code seems rather confused to me. On x86,
> *all* events set cap_user_rdpmc if the global rdpmc control is set.
> But only x86_pmu events define .event_idx, so amd uncore events won't
> actually expose
On Sun, Oct 19, 2014 at 01:23:17PM -0700, Andy Lutomirski wrote:
> On Thu, Oct 16, 2014 at 5:00 PM, Andy Lutomirski wrote:
> > The current cap_user_rdpmc code seems rather confused to me. On x86,
> > *all* events set cap_user_rdpmc if the global rdpmc control is set.
> > But only x86_pmu events
On Thu, Oct 16, 2014 at 5:00 PM, Andy Lutomirski wrote:
> The current cap_user_rdpmc code seems rather confused to me. On x86,
> *all* events set cap_user_rdpmc if the global rdpmc control is set.
> But only x86_pmu events define .event_idx, so amd uncore events won't
> actually expose their
On Thu, Oct 16, 2014 at 5:00 PM, Andy Lutomirski l...@amacapital.net wrote:
The current cap_user_rdpmc code seems rather confused to me. On x86,
*all* events set cap_user_rdpmc if the global rdpmc control is set.
But only x86_pmu events define .event_idx, so amd uncore events won't
actually
On Sun, Oct 19, 2014 at 01:23:17PM -0700, Andy Lutomirski wrote:
On Thu, Oct 16, 2014 at 5:00 PM, Andy Lutomirski l...@amacapital.net wrote:
The current cap_user_rdpmc code seems rather confused to me. On x86,
*all* events set cap_user_rdpmc if the global rdpmc control is set.
But only
On Thu, Oct 16, 2014 at 05:00:56PM -0700, Andy Lutomirski wrote:
The current cap_user_rdpmc code seems rather confused to me. On x86,
*all* events set cap_user_rdpmc if the global rdpmc control is set.
But only x86_pmu events define .event_idx, so amd uncore events won't
actually expose their
On Oct 19, 2014 2:33 PM, Peter Zijlstra pet...@infradead.org wrote:
On Sun, Oct 19, 2014 at 01:23:17PM -0700, Andy Lutomirski wrote:
On Thu, Oct 16, 2014 at 5:00 PM, Andy Lutomirski l...@amacapital.net
wrote:
The current cap_user_rdpmc code seems rather confused to me. On x86,
*all*
On Sun, Oct 19, 2014 at 03:05:42PM -0700, Andy Lutomirski wrote:
On Oct 19, 2014 2:33 PM, Peter Zijlstra pet...@infradead.org wrote:
Also, I don't understand the purpose of cap_user_time. Wouldn't it be
easier to just record the last CLOCK_MONOTONIC time and let the user
call
On Sun, Oct 19, 2014 at 3:20 PM, Peter Zijlstra pet...@infradead.org wrote:
On Sun, Oct 19, 2014 at 03:05:42PM -0700, Andy Lutomirski wrote:
On Oct 19, 2014 2:33 PM, Peter Zijlstra pet...@infradead.org wrote:
Also, I don't understand the purpose of cap_user_time. Wouldn't it be
easier to
On Sun, Oct 19, 2014 at 2:35 PM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, Oct 16, 2014 at 05:00:56PM -0700, Andy Lutomirski wrote:
The current cap_user_rdpmc code seems rather confused to me. On x86,
*all* events set cap_user_rdpmc if the global rdpmc control is set.
But only
The current cap_user_rdpmc code seems rather confused to me. On x86,
*all* events set cap_user_rdpmc if the global rdpmc control is set.
But only x86_pmu events define .event_idx, so amd uncore events won't
actually expose their rdpmc index to userspace.
Would it make more sense to add a flag
On Thu, Oct 16, 2014 at 10:42:27AM +0200, Peter Zijlstra wrote:
> gawd I hate the static_key API.
Yahaa, I like to twist my brain for fun just by staring at
sched_clock_stable() logic.
Oh, and it needs fixing btw because if you look at the asm that comes
out, after the jump labels have run, you
On Thu, Oct 16, 2014 at 1:42 AM, Peter Zijlstra wrote:
> On Tue, Oct 14, 2014 at 03:57:39PM -0700, Andy Lutomirski wrote:
>> We currently allow any process to use rdpmc. This significantly
>> weakens the protection offered by PR_TSC_DISABLED, and it could be
>> helpful to users attempting to
On Tue, Oct 14, 2014 at 03:57:39PM -0700, Andy Lutomirski wrote:
> We currently allow any process to use rdpmc. This significantly
> weakens the protection offered by PR_TSC_DISABLED, and it could be
> helpful to users attempting to exploit timing attacks.
>
> Since we can't enable access to
On Tue, Oct 14, 2014 at 03:57:39PM -0700, Andy Lutomirski wrote:
We currently allow any process to use rdpmc. This significantly
weakens the protection offered by PR_TSC_DISABLED, and it could be
helpful to users attempting to exploit timing attacks.
Since we can't enable access to
On Thu, Oct 16, 2014 at 1:42 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, Oct 14, 2014 at 03:57:39PM -0700, Andy Lutomirski wrote:
We currently allow any process to use rdpmc. This significantly
weakens the protection offered by PR_TSC_DISABLED, and it could be
helpful to users
On Thu, Oct 16, 2014 at 10:42:27AM +0200, Peter Zijlstra wrote:
gawd I hate the static_key API.
Yahaa, I like to twist my brain for fun just by staring at
sched_clock_stable() logic.
Oh, and it needs fixing btw because if you look at the asm that comes
out, after the jump labels have run, you
The current cap_user_rdpmc code seems rather confused to me. On x86,
*all* events set cap_user_rdpmc if the global rdpmc control is set.
But only x86_pmu events define .event_idx, so amd uncore events won't
actually expose their rdpmc index to userspace.
Would it make more sense to add a flag
We currently allow any process to use rdpmc. This significantly
weakens the protection offered by PR_TSC_DISABLED, and it could be
helpful to users attempting to exploit timing attacks.
Since we can't enable access to individual counters, use a very
coarse heuristic to limit access to rdpmc:
We currently allow any process to use rdpmc. This significantly
weakens the protection offered by PR_TSC_DISABLED, and it could be
helpful to users attempting to exploit timing attacks.
Since we can't enable access to individual counters, use a very
coarse heuristic to limit access to rdpmc:
42 matches
Mail list logo
