linux-kernel - Re: Detailed Stack Information Patch [0/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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 31 Mar 2009 20:22:15 +0200
From:	Stefani Seibold <stefani@...bold.net>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-mm <linux-mm@...ck.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...e.hu>, Joerg Engel <joern@...fs.org>
Subject: Re: Detailed Stack Information Patch [0/3]

Hi Andi,

Am Dienstag, den 31.03.2009, 17:49 +0200 schrieb Andi Kleen:
> Stefani Seibold <stefani@...bold.net> writes:
> >
> > - Get out of virtual memory by creating a lot of threads
> >  (f.e. the developer did assign each of them the default size)
> 
> The application just fails then? I don't think that needs
> a new monitoring tool.
> 

First, this patch is not only a monitoring tool. Only the last part 3/3
is the monitoring tool.

Patch 1/3 enhance the the proc/<pid>/task/<tid>/maps by the marking the
thread stack.

Patch 2/3 gives you an overview of the current process/thread stack
usage with the /proc/stackmon entry.

> > - Misuse the thread stack for big temporary data buffers
> 
> That would be better checked for at compile time
> (except for alloca, but that is quite rare)

Fine but it did not work for functions like:

void foo(int n)
{
	char buf[n*1024];

}

This is valid with gcc.

> 
> > - Thread stack overruns
> 
> Your method would be racy at best to determine this because
> you don't keep track of the worst case, only the current case.
> 
> So e.g. if you monitoring app checks once per second the stack
> could overflow between your monitoring intervals, but already
> have bounced back before the checker comes in.
> 

The Monitor is part 3/3. And you are right it is not a complete rock
solid solution. But it works in many cases and thats is what counts.

> Alternatively you could keep
> track of consumption in the VMA that has the stack,  but
> that can't handle very large jumps (like f() { char x[1<<30]; } )
> The later can only be handled well by the compiler.

Thats is exactly what i am doing, i walk through the pages of the thread
stack mapped memory and keep track of the highest access page. So i have
the high water mark of the used stack.

The patches are not intrusive, especially part 1.

> 

Stefani


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