Date: Mon, 19 Sep 2011 16:47:57 +0300 From: Michael Pounov <misho@elwix.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: threads/160708: Bypass process stack quota :) Message-ID: <20110919164757.dcbae5a1.misho@elwix.org> In-Reply-To: <201109190843.27576.jhb@freebsd.org> References: <201109171150.p8HBo8lZ071542@freefall.freebsd.org> <201109190843.27576.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 19 Sep 2011 08:43:27 -0400 John Baldwin <jhb@freebsd.org> wrote: > On Saturday, September 17, 2011 7:50:08 am Michael Pounov wrote: > > The following reply was made to PR threads/160708; it has been noted by > GNATS. > > > > From: Michael Pounov <misho@elwix.org> > > To: freebsd-gnats-submit@freebsd.org > > Cc: > > Subject: Re: threads/160708: Bypass process stack quota :) > > Date: Sat, 17 Sep 2011 14:26:11 +0300 > > > > Hmm, you no so right Peter. > > > > Yes I can move esp pointer in any other address, but please > > start program and see address of allocated memory for every thread. > > All this allocations is made in upper memory called stack. > > > > Try same alloca() in main program thread and you see how > > system terminate program if you going over stack limit. > > It's not very practical to apply this limit to multithreaded apps. Would you > want it to be a global limit (i.e. all stacks summed together must be <= > limit) or a per-thread limit (i.e. each thread's stack must be <= limit). > Also, given that RLIMIT_DATA is now obsolete (since malloc() defaults to using > MAP_ANON with mmap() rather than sbrk()), using RLIMIT_AS is probably the > right thing if you are trying to prevent local DOS. > > -- > John Baldwin My opinion from security viewpoint is all stacks summed together must be <= limit. Also reasonable solution is each thread's stack must be <= limit. Problem is not from own software, problem appears from buggy software of customer installed on server. I am not happy with that, when customer able get all resources with user account. This should be avoided when posible. -- Michael Pounov <misho@elwix.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110919164757.dcbae5a1.misho>