On Wed, Oct 09, 2013 at 11:59:06AM +0200, Ingo Molnar wrote:
> PeterZ didn't like exposing the physical RAM address, right?
More than not like; its useless and broken, see below.
> Peter: could we expose the page frame number instead? (Maybe mix it with a
> random seed through the hash-mixer and
* Stephane Eranian wrote:
> > Instead of a full revert we could just turn off the ABI portion
> > minimally and not recognize it for now. Assuming a more complete
> > solution is in the works for v3.13.
>
> That's a possibility. They are also pieces in the perf tool itself. We
> could certain
* David Ahern wrote:
> On 10/8/13 1:54 PM, Stephane Eranian wrote:
> >>>If the current MMAP2 is not a complete solution for what you (Google)
> >>>need, should support be reverted before 3.12 is released? No sense in
> >>>making this part of the forever API if more work is needed on it.
> >>
> >
On 10/8/13 1:54 PM, Stephane Eranian wrote:
If the current MMAP2 is not a complete solution for what you (Google)
need, should support be reverted before 3.12 is released? No sense in
making this part of the forever API if more work is needed on it.
Instead of a full revert we could just turn o
On Tue, Oct 8, 2013 at 9:41 PM, Ingo Molnar wrote:
>
> * David Ahern wrote:
>
>> Stephane:
>>
>> On 9/30/13 9:44 AM, Stephane Eranian wrote:
>> >I was alerted by people trying to use the PERF_RECORD_MMAP2
>> >record to disambiguate virtual address mappings that there is a case
>> >where the recor
* David Ahern wrote:
> Stephane:
>
> On 9/30/13 9:44 AM, Stephane Eranian wrote:
> >I was alerted by people trying to use the PERF_RECORD_MMAP2
> >record to disambiguate virtual address mappings that there is a case
> >where the record does not contain enough information.
> >
> >As you know, th
Stephane:
On 9/30/13 9:44 AM, Stephane Eranian wrote:
I was alerted by people trying to use the PERF_RECORD_MMAP2
record to disambiguate virtual address mappings that there is a case
where the record does not contain enough information.
As you know, the MMAP2 record adds the major, minor, ino n
On Tue, Oct 08, 2013 at 11:42:06AM +0200, Stephane Eranian wrote:
> On Tue, Oct 8, 2013 at 11:36 AM, Peter Zijlstra wrote:
> > On Tue, Oct 08, 2013 at 09:15:30AM +0200, Stephane Eranian wrote:
> >> Yes, it is but I am trying to see whether or not we could unify that and
> >> use a single u64 numbe
On Tue, Oct 8, 2013 at 11:36 AM, Peter Zijlstra wrote:
> On Tue, Oct 08, 2013 at 09:15:30AM +0200, Stephane Eranian wrote:
>> Yes, it is but I am trying to see whether or not we could unify that and
>> use a single u64 number to uniquely identify each mapping.
>
> No you cannot; two unrelated exec
On Tue, Oct 08, 2013 at 09:15:30AM +0200, Stephane Eranian wrote:
> Yes, it is but I am trying to see whether or not we could unify that and
> use a single u64 number to uniquely identify each mapping.
No you cannot; two unrelated executables which have distinct mm_ids can
easily mmap() the same s
On Tue, Oct 8, 2013 at 8:54 AM, Peter Zijlstra wrote:
> On Mon, Oct 07, 2013 at 11:04:38PM +0200, Stephane Eranian wrote:
>> Peter,
>>
>> Ok, so I tried this. It does not cover shmat() cases unfortunately.
>> We need that same ++global_mm_id somewhere on that code path.
>> Haven't looked at it in
On Mon, Oct 07, 2013 at 11:04:38PM +0200, Stephane Eranian wrote:
> Peter,
>
> Ok, so I tried this. It does not cover shmat() cases unfortunately.
> We need that same ++global_mm_id somewhere on that code path.
> Haven't looked at it in details just yet.
shmat() is a regular shared memory thingy
Peter,
On Thu, Oct 3, 2013 at 11:03 AM, Peter Zijlstra wrote:
> On Thu, Oct 03, 2013 at 10:55:28AM +0200, Stephane Eranian wrote:
>> I don't know the MM code but I assume that that vm_mm struct is
>> allocated dynamically
>> and maybe you already grabbing a lock while doing this. Could we
>> lev
On Mon, Oct 07, 2013 at 01:16:35PM +0200, Stephane Eranian wrote:
> I am going to try this out today. I think if it works well, we could
> also simplify the
> MMAP2 record and just pass this unique id for all cases.MMAP2 is only in rcX
> release so far. Is that still possible?
Yeah I think so.
--
On Wed, Oct 2, 2013 at 3:01 PM, Peter Zijlstra wrote:
> On Wed, Oct 02, 2013 at 02:59:32PM +0200, Stephane Eranian wrote:
>> On Wed, Oct 2, 2013 at 2:46 PM, Peter Zijlstra wrote:
>> > On Wed, Oct 02, 2013 at 02:39:53PM +0200, Ingo Molnar wrote:
>> >> - then there are timing attacks, and someone
On Thu, Oct 03, 2013 at 10:55:28AM +0200, Stephane Eranian wrote:
> On Wed, Oct 2, 2013 at 10:31 PM, Peter Zijlstra wrote:
> > On Wed, Oct 02, 2013 at 12:38:54PM -0700, Kees Cook wrote:
> >> On Wed, Oct 2, 2013 at 12:00 PM, Peter Zijlstra
> >> wrote:
> >> > On Wed, Oct 02, 2013 at 11:10:15AM -07
On Thu, Oct 3, 2013 at 2:13 AM, Stephane Eranian wrote:
> On Thu, Oct 3, 2013 at 11:03 AM, Peter Zijlstra wrote:
>> On Thu, Oct 03, 2013 at 10:55:28AM +0200, Stephane Eranian wrote:
>>> I don't know the MM code but I assume that that vm_mm struct is
>>> allocated dynamically
>>> and maybe you alr
On Thu, Oct 3, 2013 at 11:03 AM, Peter Zijlstra wrote:
> On Thu, Oct 03, 2013 at 10:55:28AM +0200, Stephane Eranian wrote:
>> I don't know the MM code but I assume that that vm_mm struct is
>> allocated dynamically
>> and maybe you already grabbing a lock while doing this. Could we
>> leverage tha
On Thu, Oct 03, 2013 at 10:55:28AM +0200, Stephane Eranian wrote:
> I don't know the MM code but I assume that that vm_mm struct is
> allocated dynamically
> and maybe you already grabbing a lock while doing this. Could we
> leverage that lock
> to increment a global generation number?
Sure; somet
On Wed, Oct 2, 2013 at 10:31 PM, Peter Zijlstra wrote:
> On Wed, Oct 02, 2013 at 12:38:54PM -0700, Kees Cook wrote:
>> On Wed, Oct 2, 2013 at 12:00 PM, Peter Zijlstra wrote:
>> > On Wed, Oct 02, 2013 at 11:10:15AM -0700, Kees Cook wrote:
>> >> Seems like a simple enough solution. Surely there mus
On Wed, Oct 02, 2013 at 12:38:54PM -0700, Kees Cook wrote:
> On Wed, Oct 2, 2013 at 12:00 PM, Peter Zijlstra wrote:
> > On Wed, Oct 02, 2013 at 11:10:15AM -0700, Kees Cook wrote:
> >> Seems like a simple enough solution. Surely there must be a catch. :)
> >
> > I didn't want to add this to the cor
On Wed, Oct 2, 2013 at 12:00 PM, Peter Zijlstra wrote:
> On Wed, Oct 02, 2013 at 11:10:15AM -0700, Kees Cook wrote:
>> Seems like a simple enough solution. Surely there must be a catch. :)
>
> I didn't want to add this to the core mm just for perf..
It seems like it would be pretty inexpensive. I
On Wed, Oct 02, 2013 at 11:10:15AM -0700, Kees Cook wrote:
> Seems like a simple enough solution. Surely there must be a catch. :)
I didn't want to add this to the core mm just for perf..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord.
On Wed, Oct 2, 2013 at 10:49 AM, Stephane Eranian wrote:
> On Wed, Oct 2, 2013 at 7:29 PM, Kees Cook wrote:
>> On Wed, Oct 2, 2013 at 10:20 AM, Stephane Eranian wrote:
>>> On Wed, Oct 2, 2013 at 7:14 PM, Kees Cook wrote:
On Wed, Oct 2, 2013 at 6:37 AM, Peter Zijlstra
wrote:
> On
On Wed, Oct 2, 2013 at 7:29 PM, Kees Cook wrote:
> On Wed, Oct 2, 2013 at 10:20 AM, Stephane Eranian wrote:
>> On Wed, Oct 2, 2013 at 7:14 PM, Kees Cook wrote:
>>> On Wed, Oct 2, 2013 at 6:37 AM, Peter Zijlstra wrote:
On Wed, Oct 02, 2013 at 03:13:16PM +0200, Stephane Eranian wrote:
>
On Wed, Oct 2, 2013 at 10:20 AM, Stephane Eranian wrote:
> On Wed, Oct 2, 2013 at 7:14 PM, Kees Cook wrote:
>> On Wed, Oct 2, 2013 at 6:37 AM, Peter Zijlstra wrote:
>>> On Wed, Oct 02, 2013 at 03:13:16PM +0200, Stephane Eranian wrote:
On Wed, Oct 2, 2013 at 3:01 PM, Peter Zijlstra
wr
On Wed, Oct 2, 2013 at 6:37 AM, Peter Zijlstra wrote:
> On Wed, Oct 02, 2013 at 03:13:16PM +0200, Stephane Eranian wrote:
>> On Wed, Oct 2, 2013 at 3:01 PM, Peter Zijlstra wrote:
>> > On Wed, Oct 02, 2013 at 02:59:32PM +0200, Stephane Eranian wrote:
>> >> On Wed, Oct 2, 2013 at 2:46 PM, Peter Zij
On Wed, Oct 2, 2013 at 7:14 PM, Kees Cook wrote:
> On Wed, Oct 2, 2013 at 6:37 AM, Peter Zijlstra wrote:
>> On Wed, Oct 02, 2013 at 03:13:16PM +0200, Stephane Eranian wrote:
>>> On Wed, Oct 2, 2013 at 3:01 PM, Peter Zijlstra wrote:
>>> > On Wed, Oct 02, 2013 at 02:59:32PM +0200, Stephane Eranian
* Peter Zijlstra wrote:
> On Wed, Oct 02, 2013 at 02:39:53PM +0200, Ingo Molnar wrote:
> > - then there are timing attacks, and someone having access to a PMU
> >context and who can trigger this SHA1 computation arbitrarily in task
> >local context can run very accurate and low noise t
On Wed, Oct 02, 2013 at 03:13:16PM +0200, Stephane Eranian wrote:
> On Wed, Oct 2, 2013 at 3:01 PM, Peter Zijlstra wrote:
> > On Wed, Oct 02, 2013 at 02:59:32PM +0200, Stephane Eranian wrote:
> >> On Wed, Oct 2, 2013 at 2:46 PM, Peter Zijlstra
> >> wrote:
> >> > On Wed, Oct 02, 2013 at 02:39:53P
On Wed, Oct 2, 2013 at 2:46 PM, Peter Zijlstra wrote:
> On Wed, Oct 02, 2013 at 02:39:53PM +0200, Ingo Molnar wrote:
>> - then there are timing attacks, and someone having access to a PMU
>>context and who can trigger this SHA1 computation arbitrarily in task
>>local context can run very
On Wed, Oct 2, 2013 at 3:01 PM, Peter Zijlstra wrote:
> On Wed, Oct 02, 2013 at 02:59:32PM +0200, Stephane Eranian wrote:
>> On Wed, Oct 2, 2013 at 2:46 PM, Peter Zijlstra wrote:
>> > On Wed, Oct 02, 2013 at 02:39:53PM +0200, Ingo Molnar wrote:
>> >> - then there are timing attacks, and someone
On Wed, Oct 02, 2013 at 02:59:32PM +0200, Stephane Eranian wrote:
> On Wed, Oct 2, 2013 at 2:46 PM, Peter Zijlstra wrote:
> > On Wed, Oct 02, 2013 at 02:39:53PM +0200, Ingo Molnar wrote:
> >> - then there are timing attacks, and someone having access to a PMU
> >>context and who can trigger t
On Wed, Oct 02, 2013 at 02:39:53PM +0200, Ingo Molnar wrote:
> - then there are timing attacks, and someone having access to a PMU
>context and who can trigger this SHA1 computation arbitrarily in task
>local context can run very accurate and low noise timing attacks...
>
>I don't th
* Peter Zijlstra wrote:
> On Wed, Oct 02, 2013 at 01:23:16PM +0200, Peter Zijlstra wrote:
>
> > So the only thing I can come up with is something like the below;
> > supposedly the sha hash mixing a boot time random seed and the mm
> > pointer is enough to avoid it being a data leak.
>
> That
On Wed, Oct 02, 2013 at 01:23:16PM +0200, Peter Zijlstra wrote:
> So the only thing I can come up with is something like the below;
> supposedly the sha hash mixing a boot time random seed and the mm
> pointer is enough to avoid it being a data leak.
That is, right until it becomes feasible to run
On Tue, Oct 01, 2013 at 01:22:58PM +0200, Stephane Eranian wrote:
> > So the problem is that we don't have a user visible address space
> > identifier; with CLONE_THREAD we have the thread group id that acts
> > like this. But for bare CLONE_VM usage there's nothing afaik.
>
>
> From the tool's p
On Mon, Sep 30, 2013 at 6:54 PM, Peter Zijlstra wrote:
>
> On Mon, Sep 30, 2013 at 06:48:55PM +0200, Stephane Eranian wrote:
> > On Mon, Sep 30, 2013 at 6:15 PM, Peter Zijlstra
> > wrote:
> > > On Mon, Sep 30, 2013 at 05:44:41PM +0200, Stephane Eranian wrote:
> > >> Hi,
> > >>
> > >> I was alert
On Mon, Sep 30, 2013 at 06:48:55PM +0200, Stephane Eranian wrote:
> On Mon, Sep 30, 2013 at 6:15 PM, Peter Zijlstra wrote:
> > On Mon, Sep 30, 2013 at 05:44:41PM +0200, Stephane Eranian wrote:
> >> Hi,
> >>
> >> I was alerted by people trying to use the PERF_RECORD_MMAP2
> >> record to disambiguat
On Mon, Sep 30, 2013 at 6:15 PM, Peter Zijlstra wrote:
> On Mon, Sep 30, 2013 at 05:44:41PM +0200, Stephane Eranian wrote:
>> Hi,
>>
>> I was alerted by people trying to use the PERF_RECORD_MMAP2
>> record to disambiguate virtual address mappings that there is a case
>> where the record does not c
On Mon, Sep 30, 2013 at 05:44:41PM +0200, Stephane Eranian wrote:
> Hi,
>
> I was alerted by people trying to use the PERF_RECORD_MMAP2
> record to disambiguate virtual address mappings that there is a case
> where the record does not contain enough information.
>
> As you know, the MMAP2 record
Hi,
I was alerted by people trying to use the PERF_RECORD_MMAP2
record to disambiguate virtual address mappings that there is a case
where the record does not contain enough information.
As you know, the MMAP2 record adds the major, minor, ino number,
inode generation numbers to a mapping. But it
42 matches
Mail list logo
