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: <20120328151230.GF4826@redhat.com>
Date:	Wed, 28 Mar 2012 11:12:30 -0400
From:	"Frank Ch. Eigler" <fche@...hat.com>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	acme@...hat.com, a.p.zijlstra@...llo.nl, mingo@...e.hu,
	paulus@...ba.org, cjashfor@...ux.vnet.ibm.com, fweisbec@...il.com,
	eranian@...gle.com, gorcunov@...nvz.org, tzanussi@...il.com,
	mhiramat@...hat.com, rostedt@...dmis.org, robert.richter@....com,
	linux-kernel@...r.kernel.org, mjw@...hat.com
Subject: Re: [PATCH 04/15] perf: Add ability to dump user regs

Hi, Jiri -

> [...]
> > [...]  Upon a normal syscall entry to the kernel, not
> > all user registers are saved explicitly for such easy retrieval.  The
> > others may be spilled to the stack by gcc during the various sys_*
> > functions or elsewhere.  [...]
> 
> Are you reffering to x86_64 where only portion of registers
> is stored by SAVE_ARGS macro? Seems like 32 bits stores the
> whole pt_regs.

I believe that's the right area.  I'm not sure even the 32-bit variant
is complete enough, for example exempting MMX/SSE registers.  These
may also contain spilled registers before long.


> Generally you could need all the registers to start the unwind, but
> I was assuming that for most cases the stack pointer and instruction
> pointer should be enough.. but I might be wrong here.

Yeah; the question is how much is missed besides those "most cases".


> > To recover these registers at run time, we found that the kernel
> > stack itself has to be partially unwound [... Without that, it ...]
> > may accidentally pass garbage data to perf userspace.  Correcting
> > this could require a kernel-space libunwind.

> AFAIK not going to happen any time soon ;)

Understood.  Then the code needs to ensure that it does not purport to
pass register values that it does not know.  (Back when we were at
this stage in systemtap, we got some reasonable backtraces even
without kernel unwinding, ie. tolerating missing registers.)


- FChE
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ