Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752913AbdGCI3O (ORCPT ); Mon, 3 Jul 2017 04:29:14 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:40068 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752369AbdGCI3N (ORCPT ); Mon, 3 Jul 2017 04:29:13 -0400 Subject: Re: Question regarding MAX_ARG_STRLEN with execve() To: Michal Hocko References: <8138c533-dae2-6a6a-fabd-d090b72d4d99@linux.vnet.ibm.com> <20170630142218.GB22923@dhcp22.suse.cz> Cc: Linux Kernel Mailing List , Ingo Molnar , Alexander Viro From: Anshuman Khandual Date: Mon, 3 Jul 2017 13:58:59 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170630142218.GB22923@dhcp22.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable x-cbid: 17070308-0004-0000-0000-000002229296 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17070308-0005-0000-0000-00005E06B91E Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-03_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707030143 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1545 Lines: 39 On 06/30/2017 07:52 PM, Michal Hocko wrote: > On Fri 30-06-17 11:59:37, Anshuman Khandual wrote: >> Hello, >> >> execve() system call should support argument length of >> MAX_ARG_STRLEN (PAGE_SIZE * 32). On 64K page size systems, we >> are not able to pass 32 * PAGE_SIZE arguments into the execve() >> system call because of the following reasons. >> >> * struct linux_binprm's vma starts with a size of PAGE_SIZE >> >> vma->vm_end = STACK_TOP_MAX; >> vma->vm_start = vma->vm_end - PAGE_SIZE; >> >> * The VMA expands as much depending upon the argument size. So >> for 32 * PAGE_SIZE argument, it becomes 33 * PAGE_SIZE. >> >> * 33 * PAGE_SIZE with 64K pages fails the following test in >> get_arg_page() function. 33 * PAGE_SIZE is more than 2MB >> (8 MB /4) with 64K page size. >> >> if (size > READ_ONCE(rlim[RLIMIT_STACK].rlim_cur) / 4) >> >> * Right now RLIMIT_STACK is hard coded 8MB which does not take >> PAGE_SIZE into account. >> >> Wondering what should be the solution for this problem ? >> >> * Change the default stack size from 8MB ? > just increase the ulimit if you want to use such a large arguments. > Yeah that is possible but it does not still offset the fact that the calculation is broken on the page size of 64K. I mean, yeah its not practical to have such a large argument. But the point is whether we would want to support the MAX_ARG_STRLEN semantic for execve system call or not. At present its broken for 64K and I am asking whether we will be willing to revisit the '1/4th of the stack' condition.