From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH/RFC] user_ns: fix missing limiting of user_ns counts Date: Fri, 28 Dec 2012 19:21:52 +0000 Message-ID: <20121228192152.GA4939@ZenIV.linux.org.uk> References: <20121228175627.GA7683@cachalot> <20121228184334.GZ4939@ZenIV.linux.org.uk> <20121228190435.GA8690@cachalot> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20121228190435.GA8690@cachalot> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Vasily Kulikov Cc: "Eric W. Biederman" , Containers , "Serge E. Hallyn" , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kernel-hardening-ZwoEplunGu1jrUoiu81ncdBPR1lH4CV8@public.gmane.org List-Id: containers.vger.kernel.org On Fri, Dec 28, 2012 at 11:04:35PM +0400, Vasily Kulikov wrote: > > I'm sorry, but this is not a solution. Kernel is not x86-only; there are > > architectures with far bigger minimal stack frame size. E.g. on sparc64 > > every fucking stack frame is at least 176 bytes. So your 100 calls deep > > call chain will happily overflow the damn stack all by itself - kernel > > stack on sparc64 is 16Kb total, including struct thread_info living there. > > Understood. How to properly fix it then? Looks like there are quite > many kernel structures which may reference other structures which > indirectly reference each other via kref, IOW it is not user_ns specific > issue. With unprivileged user_ns the way it should be freed must be > somehow changed. There are many damn good reasons why kref should *not* be used without thinking. It's been oversold as easy solution to all refcounting problems; it isn't one. Don't use it here. From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com Date: Fri, 28 Dec 2012 19:21:52 +0000 From: Al Viro Message-ID: <20121228192152.GA4939@ZenIV.linux.org.uk> References: <20121228175627.GA7683@cachalot> <20121228184334.GZ4939@ZenIV.linux.org.uk> <20121228190435.GA8690@cachalot> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121228190435.GA8690@cachalot> Sender: Al Viro Subject: [kernel-hardening] Re: [PATCH/RFC] user_ns: fix missing limiting of user_ns counts To: Vasily Kulikov Cc: kernel-hardening@lists.openwall.com, Containers , "Serge E. Hallyn" , linux-kernel@vger.kernel.org, "Eric W. Biederman" List-ID: On Fri, Dec 28, 2012 at 11:04:35PM +0400, Vasily Kulikov wrote: > > I'm sorry, but this is not a solution. Kernel is not x86-only; there are > > architectures with far bigger minimal stack frame size. E.g. on sparc64 > > every fucking stack frame is at least 176 bytes. So your 100 calls deep > > call chain will happily overflow the damn stack all by itself - kernel > > stack on sparc64 is 16Kb total, including struct thread_info living there. > > Understood. How to properly fix it then? Looks like there are quite > many kernel structures which may reference other structures which > indirectly reference each other via kref, IOW it is not user_ns specific > issue. With unprivileged user_ns the way it should be freed must be > somehow changed. There are many damn good reasons why kref should *not* be used without thinking. It's been oversold as easy solution to all refcounting problems; it isn't one. Don't use it here. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932488Ab2L1TWA (ORCPT ); Fri, 28 Dec 2012 14:22:00 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:39906 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753857Ab2L1TV5 (ORCPT ); Fri, 28 Dec 2012 14:21:57 -0500 Date: Fri, 28 Dec 2012 19:21:52 +0000 From: Al Viro To: Vasily Kulikov Cc: kernel-hardening@lists.openwall.com, Containers , "Serge E. Hallyn" , linux-kernel@vger.kernel.org, "Eric W. Biederman" Subject: Re: [PATCH/RFC] user_ns: fix missing limiting of user_ns counts Message-ID: <20121228192152.GA4939@ZenIV.linux.org.uk> References: <20121228175627.GA7683@cachalot> <20121228184334.GZ4939@ZenIV.linux.org.uk> <20121228190435.GA8690@cachalot> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121228190435.GA8690@cachalot> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 28, 2012 at 11:04:35PM +0400, Vasily Kulikov wrote: > > I'm sorry, but this is not a solution. Kernel is not x86-only; there are > > architectures with far bigger minimal stack frame size. E.g. on sparc64 > > every fucking stack frame is at least 176 bytes. So your 100 calls deep > > call chain will happily overflow the damn stack all by itself - kernel > > stack on sparc64 is 16Kb total, including struct thread_info living there. > > Understood. How to properly fix it then? Looks like there are quite > many kernel structures which may reference other structures which > indirectly reference each other via kref, IOW it is not user_ns specific > issue. With unprivileged user_ns the way it should be freed must be > somehow changed. There are many damn good reasons why kref should *not* be used without thinking. It's been oversold as easy solution to all refcounting problems; it isn't one. Don't use it here.