From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8DA47CE7A81 for ; Mon, 25 Sep 2023 09:54:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AEE128D0020; Mon, 25 Sep 2023 05:54:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A9E938D0001; Mon, 25 Sep 2023 05:54:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 965DE8D0020; Mon, 25 Sep 2023 05:54:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 812EA8D0001 for ; Mon, 25 Sep 2023 05:54:00 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 351E9140B2C for ; Mon, 25 Sep 2023 09:54:00 +0000 (UTC) X-FDA: 81274658640.26.7E68499 Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by imf12.hostedemail.com (Postfix) with ESMTP id EBB3D40004 for ; Mon, 25 Sep 2023 09:53:56 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=xmission.com; spf=pass (imf12.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.233 as permitted sender) smtp.mailfrom=ebiederm@xmission.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695635637; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fP69tTyL30oxvh3MJpzAI6C2gXPY0qHeUcsBywKmcpw=; b=CeyRYdWIhp7SLTybGbBrd4/RGII1fL4BbtxwCRgDPg8KFCEXGh3na9U92AQOYTvvRDk8ZX Fua2aGXNHd5tVUnGCIFbU1xeUrhgV0+2DZsI0ajl1p2kd1EntYnmFX+Nnfirf/IpK31ntb wbS/W/Y3jm2NHCk3YZ5BzcpFRcJQOrU= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=xmission.com; spf=pass (imf12.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.233 as permitted sender) smtp.mailfrom=ebiederm@xmission.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695635637; a=rsa-sha256; cv=none; b=PEynysxUnL1NIEYr52OWDP8yOxodctcS77O/RC2oXqWlZjslx+Wv3oQGZ09fJR+exehyEb CnhUANtbTNNE1vBaUY9Ac09JFnFcwC5zXKoTIx4zor3oDgaG1tV0GWQWNs5LDA7j7d0gIC EVERqM/xsXiNa9zCPLPURin7LuuarvI= Received: from in01.mta.xmission.com ([166.70.13.51]:46656) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1qkiHo-0085b5-JY; Mon, 25 Sep 2023 03:53:52 -0600 Received: from ip68-227-168-167.om.om.cox.net ([68.227.168.167]:44374 helo=email.froward.int.ebiederm.org.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1qkiHn-000L9B-C5; Mon, 25 Sep 2023 03:53:52 -0600 From: "Eric W. Biederman" To: Sebastian Ott Cc: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , Alexander Viro , Christian Brauner , Kees Cook , Mark Brown , Willy Tarreau , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20230914-bss-alloc-v1-1-78de67d2c6dd@weissschuh.net> <36e93c8e-4384-b269-be78-479ccc7817b1@redhat.com> <87zg1bm5xo.fsf@email.froward.int.ebiederm.org> <37d3392c-cf33-20a6-b5c9-8b3fb8142658@redhat.com> Date: Mon, 25 Sep 2023 04:50:33 -0500 In-Reply-To: <37d3392c-cf33-20a6-b5c9-8b3fb8142658@redhat.com> (Sebastian Ott's message of "Mon, 25 Sep 2023 11:20:51 +0200 (CEST)") Message-ID: <87ttrimviu.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1qkiHn-000L9B-C5;;;mid=<87ttrimviu.fsf@email.froward.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.168.167;;;frm=ebiederm@xmission.com;;;spf=pass X-XM-AID: U2FsdGVkX18w5NYq0x4TaF0i1cI2dmUlRdefiwsH+Wc= X-SA-Exim-Connect-IP: 68.227.168.167 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH RFC] binfmt_elf: fully allocate bss pages X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) X-Rspamd-Queue-Id: EBB3D40004 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: p9wwpg5aaaje8ss5b3dghfg9admfgbt5 X-HE-Tag: 1695635636-694936 X-HE-Meta: U2FsdGVkX1/SR742NMn9N232TpjcfVo6SbtT1RiVSVveK/61Rh7Jy+C4CfizV4UM3Dtm7aS02+M+nhhjB9XkZTcuBqOdIKAlqvkfBhXm0Nd3BUD029iXxdCT+rp3MgoJUQGoWX4nkFeAFLzVMXRgZLi5hAdsLWU78eyZjrOzfVSt7D9L2T1VAviBJvQLRldtZ6yYtdXOJfVeirpx9QlQZJ4AKDqVVT4W7IAUQwKb/Xv28ZR1/uS/nU7Cp/eRRmSGSTogSxIIE3bkncm5Hr6B0oonsYzGT3Ap7pahsLCTqy1inAk8Q4cKwwV+NGZy631wl1p2shMDwmvBOMu8DJAzhO4LOrM4kOTaCy/38yMlJSyP4XAEJvmT2PC3Rs4HbnNzKUjdWpOnKdnLALnQFtwMOTYmy5Hbs/L7ukkfRDIlJTFMkLN+iFksHqksUkhpJVz222uCd/TMGTs1hcjJB2U53gBkIhZDCFpNxGa97onrxaszF4ToU1/XYtCEAvdYW1ErmIk2w1ZNLa7M58jFrk2/ouBCJHn85G1wIvVGkVX90I36jd0neqcn/4Wyp3O/VXK4VlhN757vzOEce5bGEDPlUf0qq+xKv5fP/s5xDOCU5WrCrbzDrXw2YH+AWZaVNLiQJTvmFuxyqeqFsvX55MeecwTvzzvyNWVD7SvifMYGCvxVXjR9OJRISmVkJokzPJXez2IwYzfDTTb6DvJREk0ufECih3IRJJewwGnfjzHPkuZxw4gpUDnS+Ave9WofXio8if7CIOG4HIfB9+vohF0AG0SaSOdR/jU+DUbLFL2cHs9C8wk7CoSLlxjAEM7ZblzAsG7X3iv5PQo2LecJjkN33zkztrxHo81Tof/8qFL8nruVD6UANqp4RJxprPUNVfXCwPHMA99fNdnUK8+pqZEa86sXoLM6WIC4LjUfG6F8eDduiZH/rKT6hus9d0+90TZmRZWL9nQOLGh1gIG7Gky BYDPRRaI j5XIceXF3P+HAnjF9LveKO1q4vSF71xfd1biVfWn/iAOu2Z412pXbSZBOhs2Cbw7UvNIAtBde/C+R2wjKlCHk43hjvHJnWq1yF2dZ2Q4giY1nySgn1gd3J1OHLwoL8ECsUc19jeWQ/8lwLNUCUzBnWUQ5gA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Sebastian Ott writes: > On Sun, 24 Sep 2023, Eric W. Biederman wrote: >> Sebastian Ott writes: >> >>> Hej, >>> >>> since we figured that the proposed patch is not going to work I've spent a >>> couple more hours looking at this (some static binaries on arm64 segfault >>> during load [0]). The segfault happens because of a failed clear_user() >>> call in load_elf_binary(). The address we try to write zeros to is mapped with >>> correct permissions. >>> >>> After some experiments I've noticed that writing to anonymous mappings work >>> fine and all the error cases happend on file backed VMAs. Debugging showed that >>> in elf_map() we call vm_mmap() with a file offset of 15 pages - for a binary >>> that's less than 1KiB in size. >>> >>> Looking at the ELF headers again that 15 pages offset originates from the offset >>> of the 2nd segment - so, I guess the loader did as instructed and that binary is >>> just too nasty? >>> >>> Program Headers: >>> Type Offset VirtAddr PhysAddr >>> FileSiz MemSiz Flags Align >>> LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 >>> 0x0000000000000178 0x0000000000000178 R E 0x10000 >>> LOAD 0x000000000000ffe8 0x000000000041ffe8 0x000000000041ffe8 >>> 0x0000000000000000 0x0000000000000008 RW 0x10000 >>> NOTE 0x0000000000000120 0x0000000000400120 0x0000000000400120 >>> 0x0000000000000024 0x0000000000000024 R 0x4 >>> GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 >>> 0x0000000000000000 0x0000000000000000 RW 0x10 >>> >>> As an additional test I've added a bunch of zeros at the end of that binary >>> so that the offset is within that file and it did load just fine. >>> >>> On the other hand there is this section header: >>> [ 4] .bss NOBITS 000000000041ffe8 0000ffe8 >>> 0000000000000008 0000000000000000 WA 0 0 1 >>> >>> "sh_offset >>> This member's value gives the byte offset from the beginning of the file to >>> the first byte in the section. One section type, SHT_NOBITS described >>> below, occupies no space in the file, and its sh_offset member locates >>> the conceptual placement in the file. >>> " >>> >>> So, still not sure what to do here.. >>> >>> Sebastian >>> >>> [0] https://lore.kernel.org/lkml/5d49767a-fbdc-fbe7-5fb2-d99ece3168cb@redhat.com/ >> >> I think that .bss section that is being generated is atrocious. >> >> At the same time I looked at what the linux elf loader is trying to do, >> and the elf loader's handling of program segments with memsz > filesz >> has serious remnants a.out of programs allocating memory with the brk >> syscall. >> >> Lots of the structure looks like it started with the assumption that >> there would only be a single program header with memsz > filesz the way >> and that was the .bss. The way things were in the a.out days and >> handling of other cases has been debugged in later. >> >> So I have modified elf_map to always return successfully when there is >> a zero filesz in the program header for an elf segment. >> >> Then I have factored out a function clear_tail that ensures the zero >> padding for an entire elf segment is present. >> >> Please test this and see if it causes your test case to work. > > Sadly, that causes issues for other programs: Bah. Too much cleanup at once. I will respin. > [ 44.164596] Run /init as init process > [ 44.168763] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b > [ 44.176409] CPU: 32 PID: 1 Comm: init Not tainted 6.6.0-rc2+ #89 > [ 44.182404] Hardware name: GIGABYTE R181-T92-00/MT91-FS4-00, BIOS F34 08/13/2020 > [ 44.189786] Call trace: > [ 44.192220] dump_backtrace+0xa4/0x130 > [ 44.195961] show_stack+0x20/0x38 > [ 44.199264] dump_stack_lvl+0x48/0x60 > [ 44.202917] dump_stack+0x18/0x28 > [ 44.206219] panic+0x2e0/0x350 > [ 44.209264] do_exit+0x370/0x390 > [ 44.212481] do_group_exit+0x3c/0xa0 > [ 44.216044] get_signal+0x800/0x808 > [ 44.219521] do_signal+0xfc/0x200 > [ 44.222824] do_notify_resume+0xc8/0x418 > [ 44.226734] el0_da+0x114/0x120 > [ 44.229866] el0t_64_sync_handler+0xb8/0x130 > [ 44.234124] el0t_64_sync+0x194/0x198 > [ 44.237776] SMP: stopping secondary CPUs > [ 44.241740] Kernel Offset: disabled > [ 44.245215] CPU features: 0x03000000,14028142,10004203 > [ 44.250342] Memory Limit: none > [ 44.253383] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- Eric