Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp6859256imu; Wed, 14 Nov 2018 08:02:42 -0800 (PST) X-Google-Smtp-Source: AJdET5drqYP9Erz/v+jbudGyDHzYUBAhHwAX/HeHyoacRaMGqULkaN1QGnKGHMexUU9F1nn1h7Z+ X-Received: by 2002:a17:902:7848:: with SMTP id e8mr2562736pln.100.1542211362169; Wed, 14 Nov 2018 08:02:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542211362; cv=none; d=google.com; s=arc-20160816; b=WDxJ5LCjznbVdxHlT4HE8hFDPeMxQ9E89xECGm7sfk4fqWRHIehMTJn93DqvgoQOPr VkzC8ogzRxEGlZUs5sMCn1HuO/4iJ/QE4egqzFU53iDCCUbxJ7MN+eLIbZrg7EfaYfFn hhfap46IBI2i3aNmTwoFwODB+BdS8mE/4qbPTGKUL+DVQhVSCgg6X8IbGhNWd9ys3d3Q 9Rhkap656gcpqLOH9mv4Bg6c5haZ94Ad8qEKAj0h+HUaS5Agaf4gKzFyGxG/XJwJjb8b b4tp6+lMwa7h1/w18YRGCwTuSg0PcgBbM4TZWwPx7i1qzAIZ198cC3kX97I6+ADi2PI5 O9ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=dHnbG8de3KhZIfljHXrZrCXXQwiGwV/t5WPupQ2hSkQ=; b=MaE0P3NMeoGbGJG+XZrQ5Ow2YZcCK/unrsEoKaOzlY/8xTdd09yN0wKSVgOvH64+ri eAccwe1Q0eI4MR35gczaMJ0BEFlNUHMvt2Jh06mI8rJ/3im+WjrqQys9xlvzqRKeKwck W+afe0vXS30mWER4tL8kcEO0Prb1ow0XvicC5oEFsV2YStP2uziFl0LgemFZWxMWTpJm zPgdJ9sWup/Kco42kcaZXGiwMBjCElEapzGIC0ws/x+3Gdiddzblnw1kpo0GIn/8gihn 6vY4xnaYKaZQWg4pHtX1/wA7X4GK7lq1/QkdUlITIcRjbl1+hNkN6sQPV43s5pZlXWQ2 2vdw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a17-v6si23383550pls.302.2018.11.14.08.02.26; Wed, 14 Nov 2018 08:02:42 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733207AbeKOCFi (ORCPT + 99 others); Wed, 14 Nov 2018 21:05:38 -0500 Received: from mx2.suse.de ([195.135.220.15]:51758 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726295AbeKOCFi (ORCPT ); Wed, 14 Nov 2018 21:05:38 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 3C6E4B007; Wed, 14 Nov 2018 16:01:48 +0000 (UTC) Date: Wed, 14 Nov 2018 17:01:47 +0100 From: Michal Hocko To: Oleg Nesterov Cc: Andrew Morton , Ben Woodard , "Eric W. Biederman" , Kees Cook , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] exec: increase BINPRM_BUF_SIZE to 256 Message-ID: <20181114160147.GD23419@dhcp22.suse.cz> References: <20181112160931.GA28463@redhat.com> <20181112160956.GA28472@redhat.com> <20181112155248.4dde2613979f4c176565629e@linux-foundation.org> <20181113165557.GG30990@redhat.com> <20181113124305.73b8ac9e5a2ef9b18d3444b2@linux-foundation.org> <20181114155413.GC13885@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181114155413.GC13885@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 14-11-18 16:54:14, Oleg Nesterov wrote: > On 11/13, Andrew Morton wrote: > > > > On Tue, 13 Nov 2018 17:55:58 +0100 Oleg Nesterov wrote: > > > > > > However it would be basically cost-free to increase > > > > BINPRM_BUF_SIZE up to the point where sizeof(struct linux_binprm) == > > > > PAGE_SIZE? > > > > > > I don't think we should take sizeof(struct linux_binprm) into account, the > > > new members can come at any time and we can never decrease BINPRM_BUF_SIZE. > > > > My main point is.. why not make BINPRM_BUF_SIZE a lot larger than 256? > > Of course we can make it larger. And of course 256 is just another silly/random > value. Currently it seems to work, but if we have another bug report we should > probably rework load_script() to use vmalloc()'ed buffer. Perhaps we should do > this right now and I am just too lazy. I would rather not over-engineer this after a first bug. Even 256 path seems like a torturing to me ;) We would have to have some limit anyway and arbitrary value might just not work for somebody crazy enough. Making it a part of of rlimit sounds like opening a cane of worms to me. -- Michal Hocko SUSE Labs