linux-kernel - Re: [PATCH 3/3] X86: Add a thread cpu time implementation to vDSO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141210225627.GA11754@devbig257.prn2.facebook.com>
Date:	Wed, 10 Dec 2014 14:56:29 -0800
From:	Shaohua Li <shli@...com>
To:	Andy Lutomirski <luto@...capital.net>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>, <kernel-team@...com>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH 3/3] X86: Add a thread cpu time implementation to vDSO

On Wed, Dec 10, 2014 at 02:13:23PM -0800, Andy Lutomirski wrote:
> On Wed, Dec 10, 2014 at 1:57 PM, Shaohua Li <shli@...com> wrote:
> > On Wed, Dec 10, 2014 at 11:10:52AM -0800, Andy Lutomirski wrote:
> >> On Sun, Dec 7, 2014 at 7:03 PM, Shaohua Li <shli@...com> wrote:
> >> > This primarily speeds up clock_gettime(CLOCK_THREAD_CPUTIME_ID, ..). We
> >> > use the following method to compute the thread cpu time:
> >>
> >> I like the idea, and I like making this type of profiling fast.  I
> >> don't love the implementation because it's an information leak (maybe
> >> we don't care) and it's ugly.
> >>
> >> The info leak could be fixed completely by having a per-process array
> >> instead of a global array.  That's currently tricky without wasting
> >> memory, but it could be created on demand if we wanted to do that,
> >> once my vvar .fault patches go in (assuming they do -- I need to ping
> >> the linux-mm people).
> >
> > those info leak really doesn't matter.
> 
> Why not?

Ofcourse I can't make sure completely, but how could this info be used
as attack?

> > But we need the global array
> > anyway. The context switch detection should be per-cpu data and should
> > be able to access in remote cpus.
> 
> Right, but the whole array could be per process instead of global.
> 
> I'm not saying I'm sure that would be better, but I think it's worth
> considering.

right, it's possible to be per process. As you said, this will waster a
lot of memory. and you can't even do on-demand, as the context switch
path will write the count to the per-process/per-thread vvar. Or you can
maintain the count in kernel and let the .fault copy the count to vvar
page (if the vvar page is absent). But this still wastes memory if
applications use the vdso. I'm wondering how you handle page fault in
context switch too if you don't pin the vdso pages.

Thanks,
Shaohua
--
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/