[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060912140453.GB2491@frankl.hpl.hp.com>
Date: Tue, 12 Sep 2006 07:04:53 -0700
From: Stephane Eranian <eranian@....hp.com>
To: Andi Kleen <ak@...e.de>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH 14/18] 2.6.17.9 perfmon2 patch for review: new i386 files
Andi,
On Fri, Aug 25, 2006 at 03:13:58PM +0200, Andi Kleen wrote:
> > Are we already running with cr4.pce set today?
>
> Not yet. But soon.
>
> > The cr4.pce allows all PMC (counter) to be read at user level, not just perfctr0.
> > When enabled all counters are readable at user level from any process. A process
> > can see the value accumulated by another process (assuming monitoring in per-thread
> > mode).
>
> Yes, we'll have to live with that.
>
> > Some people may see this as a security risk.
>
> Maybe some paranoiacs, but we normally don't design software for these people's
> obsessions.
>
> > On the other hand all you see
> > is counts.
>
> Exactly. And you always have RDTSC anyways.
>
>
> > So as long as the i386/x86_64 PMU only collect counts, this could be
> > fine. The day they can capture addresses, this becomes more problematic, I think.
>
> We can worry about it when it happens. Whenever anyone adds that capability
> to the hardware they will hopefully add new separate ring 3 control bits.
>
Just a follow-up on this. It already exists.
On the P4, I am planning on exporting the Last Brnch Record Stack (LBR Stack) to users of perfmon.
This provides some branch buffer similar to what we have on Itanium. Obviously, the MSRs do contains
addresses (source/target of branches).
--
-Stephane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists