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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 20 Apr 2016 13:15:56 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Dmitry Safonov <dsafonov@...tuozzo.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
	Robert Richter <rric@...nel.org>, oprofile-list@...ts.sf.net,
	Dmitry Safonov <0x7f454c46@...il.com>
Subject: Re: [PATCH 1/4] x86/events: down with test_thread_flag(TIF_IA32)

On Thu, Apr 14, 2016 at 11:32:07AM -0700, Andy Lutomirski wrote:
> On Thu, Apr 14, 2016 at 11:10 AM, Dmitry Safonov <dsafonov@...tuozzo.com> wrote:
> > We can use user_64bit_mode(regs) here instead of thread flag
> > because we have full register frame.
> >
> > Signed-off-by: Dmitry Safonov <dsafonov@...tuozzo.com>
> > ---
> >  arch/x86/events/core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> > index 041e442a3e28..91d101a9a6e9 100644
> > --- a/arch/x86/events/core.c
> > +++ b/arch/x86/events/core.c
> > @@ -2269,7 +2269,7 @@ perf_callchain_user32(struct pt_regs *regs, struct perf_callchain_entry *entry)
> >         struct stack_frame_ia32 frame;
> >         const void __user *fp;
> >
> > -       if (!test_thread_flag(TIF_IA32))
> > +       if (user_64bit_mode(regs))
> >                 return 0;

Urgh, so why didn't I get Cc'ed to these patches to begin with?

> Peter, I got lost in the code that calls this.  Are regs coming from
> the overflow interrupt's regs, current_pt_regs(), or
> perf_get_regs_user?

So get_perf_callchain() will get regs from:

 - interrupt/NMI regs
 - perf_arch_fetch_caller_regs()

And when user && !user_mode(), we'll use:

 - task_pt_regs() (which arguably should maybe be perf_get_regs_user())

to call perf_callchain_user(), which then, ands up calling
perf_callchain_user32() which is expected to NO-OP for 64bit userspace.

> If it's the perf_get_regs_user, then this should be okay, but passing
> in the ABI field directly would be even nicer.  If they're coming from
> the overflow interrupt's regs or current_pt_regs(), could we change
> that?
> 
> It might also be nice to make sure that we call perf_get_regs_user
> exactly once per overflow interrupt -- i.e. we could push it into the
> main code rather than the regs sampling code.

The risk there is that we might not need the user regs at all to handle
the overflow thingy, so doing it unconditionally would be unwanted.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ