linux-kernel - Re: Detailed Stack Information Patch [2/3]

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] [day] [month] [year] [list]

Date:	Fri, 3 Apr 2009 10:54:06 +0200
From:	Mikael Pettersson <mikpe@...uu.se>
To:	Stefani Seibold <stefani@...bold.net>
Cc:	Mikael Pettersson <mikpe@...uu.se>, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Joerg Engel <joern@...fs.org>
Subject: Re: Detailed Stack Information Patch [2/3]

Stefani Seibold writes:
 > Am Freitag, den 03.04.2009, 09:32 +0200 schrieb Mikael Pettersson:
 > > Stefani Seibold writes:
 > >  > I think a user space daemon will be the a good way if the /proc/*/maps
 > >  > or /proc/*/stack will provide the following information:
 > >  > 
 > >  > - start address of the stack
 > >  > - current address of the stack pointer
 > >  > - highest used address in the stack
 > > 
 > > You're assuming
 > > 1. a thread has exactly one stack
 > > 2. the stack is a single unbroken area
 > > 3. the kernel knows the location of this area
 > > 
 > > None of these assumptions are necessarily valid, esp. in
 > > the presence of virtualizers, managed runtimes, or mixed
 > > interpreted/JIT language implementations.
 > 
 > We are talking about the kernel view. And from this point a thread has
 > only one stack and it is a single mapped continuous area. There are only
 > one exception and that is the sigaltstack().

So you're proposing to have the kernel export data which,
while accurate from the kernel's limited view, may be
arbitrarily inaccurate for the user-space process in question?

Also I'm not sure you even need a kernel extension for the
optimistic case of a single simple stack. ptrace to get stack
pointer then scan /proc/$tid/maps to identify the corresponding
mapping should give the same information, no?
--
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/