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 82593E7070F for ; Thu, 21 Sep 2023 10:36:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E7A376B0160; Thu, 21 Sep 2023 06:36:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E29606B0180; Thu, 21 Sep 2023 06:36:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF0B16B0181; Thu, 21 Sep 2023 06:36:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id BEDFC6B0160 for ; Thu, 21 Sep 2023 06:36:41 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9716FB437A for ; Thu, 21 Sep 2023 10:36:41 +0000 (UTC) X-FDA: 81260251002.18.B99B76C Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf18.hostedemail.com (Postfix) with ESMTP id 7983A1C0006 for ; Thu, 21 Sep 2023 10:36:39 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=aMaLCw6N; spf=pass (imf18.hostedemail.com: domain of sebott@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=sebott@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695292599; 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:dkim-signature; bh=n5pyZLuCo/XvXRs78cLj8dcUE4Os6CZvVNQ9E5PNqc8=; b=kyu5RwKHWhv2wy5WGSmhyApB/iSUo9RvS/A8B1mqX1jCmNG1zIzAgmv56sRzUC5BfVkOar pAAd++MrUhP9cH54oF4CBmhNwIHRtEa0mWdfoh3tjWnCdbqnkxQMeWuCcLZCthCBidbn3u /T9zi8nsvJ27PlLB4KV51HIqovmXehY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695292599; a=rsa-sha256; cv=none; b=qkt8hhM9WzEM30jDtpvbG7W1UFEPCXahUKPD7TuVP5IuZs33m102X3cJ4Q+sXVNtt1j7hu ZYvordGKsrhnJfmTyeOU/SSUOS0TVD1pEnH5jtQJOYSP5IKew5Z+zwbFml87ce39cWQ+Jr W6ksNVOneLLrXM3ebH/c9ohgULq9qqU= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=aMaLCw6N; spf=pass (imf18.hostedemail.com: domain of sebott@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=sebott@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695292598; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=n5pyZLuCo/XvXRs78cLj8dcUE4Os6CZvVNQ9E5PNqc8=; b=aMaLCw6NUDEf/C2K5oNnO/BFp1zlPjFJ6Wqf1vPc3LGBYugn/yyT+K7bJd3f5V4kVTgUVY G/408cr3EPSaTVrxJ967L4YphbeavRZqYiKuZ7zNzRxQY2rUkV2pfktwHmv1NskzBlLYUQ odojSZE9JdP2KGq4X8Qj1OW8sIPF3B8= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-108-aFcIAM8IPuKwcfeHzqZr3Q-1; Thu, 21 Sep 2023 06:36:37 -0400 X-MC-Unique: aFcIAM8IPuKwcfeHzqZr3Q-1 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-40514ce8387so6016965e9.3 for ; Thu, 21 Sep 2023 03:36:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695292596; x=1695897396; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=n5pyZLuCo/XvXRs78cLj8dcUE4Os6CZvVNQ9E5PNqc8=; b=SxeHJTR9A1NiNfCOQFPSlYSzQCqxyozy5RzlkN8K8Dkw0fEPxOk+s/qTjewGNuiiRU fxpsDVEU7LT4zSxPm+C6nIt26d3nqkxRxzPN6xhjoL7TyjJHjL1MtfcTgg2dqr7Ixuk5 NGLE/zt0dmOlnHWuU7D/L5K8PE8eoxBcNWG2RR8B+AKxtUmpHRuwAm3VXoCNClApyHkZ 3VWIRsP1QyLic5QVsRHgznxfg+I+YfM7Eo2ob/HyqLV+5ZKD5Hy7Yf7RiLsS5JNjWT/e EPwx7SChWt7fy/smfdpuiNuPicP7llyHJKxvLqlAiP+6w953gjPQ3SH9OhXz99I0m/wX I0VQ== X-Gm-Message-State: AOJu0Yzjw0oYU2lFMOs+fuyPlu/qW7hKy95u4n/9RyaufJiHYl4ukS0R t1dzTHDY2pUsDWFGR5rVyQGBA7dhOJQ5pczROxH4l39SMwXZM+y3MSSYv32fvq6xHU2O7PvQIn+ vVJhPCAMWYqQ= X-Received: by 2002:adf:fe8a:0:b0:31a:d4a9:bdac with SMTP id l10-20020adffe8a000000b0031ad4a9bdacmr4758969wrr.11.1695292596354; Thu, 21 Sep 2023 03:36:36 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHo4IlMYvVaA5s4LWesfAld9qk/d4qdTGLbpvwo6KlcwOZdqJ9/fXFN20xWoWzNksmmABizyA== X-Received: by 2002:adf:fe8a:0:b0:31a:d4a9:bdac with SMTP id l10-20020adffe8a000000b0031ad4a9bdacmr4758950wrr.11.1695292595980; Thu, 21 Sep 2023 03:36:35 -0700 (PDT) Received: from rh (p200300c93f1ec600a890fb4d684902d4.dip0.t-ipconnect.de. [2003:c9:3f1e:c600:a890:fb4d:6849:2d4]) by smtp.gmail.com with ESMTPSA id z8-20020adff748000000b0031fedb25b85sm1378553wrp.84.2023.09.21.03.36.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Sep 2023 03:36:35 -0700 (PDT) Date: Thu, 21 Sep 2023 12:36:34 +0200 (CEST) From: Sebastian Ott To: =?ISO-8859-15?Q?Thomas_Wei=DFschuh?= cc: Alexander Viro , Christian Brauner , Eric Biederman , Kees Cook , Mark Brown , Willy Tarreau , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH RFC] binfmt_elf: fully allocate bss pages In-Reply-To: <20230914-bss-alloc-v1-1-78de67d2c6dd@weissschuh.net> Message-ID: <36e93c8e-4384-b269-be78-479ccc7817b1@redhat.com> References: <20230914-bss-alloc-v1-1-78de67d2c6dd@weissschuh.net> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII; format=flowed X-Stat-Signature: t4nhfg8k8f1bctn6be4ihxri9mt388rb X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 7983A1C0006 X-Rspam-User: X-HE-Tag: 1695292599-539784 X-HE-Meta: U2FsdGVkX18jkDKjQmlo63nsjnZCWTeQv9SBLUJw/s75YuzBnT0EU0DtbY0KyVwz+U+ojtXD9dBKJh/g1q862zc9n54K1tkyEdLoya8h7YdLTqKSWfZ1jFw6i7zhcC9mkZU4gXcb4eH+kWNlfSxH02C+IIKOE5YAW+UEcJGDGPHhYdyWIe6z0kVtEdVQQDyHuhsC4T+A4hUqGX+dO+r6NkSF+NBJ1CzXQtO8dxu7tmV6rf6l9jOGeAQI1Cf3saIEz68LSUeQ8bGeIEJD7r6aWAk6nljVncGtiTwK9YGRCkjlsQNvcV6IzyFgmA67E+So6bdJgqqDnzO8dp3FWM5xpODZeaPulL92CGSgx+eETdDk5Ojrpv+arI5hZw+80k++80X8ki/Ebx40sAR9YPcySiV4C5Ehgi824HA2mvo2TuYK65teV37NDBYLXfCngmQVX7oeXFXQQIZLJuZUgGCZZB/7re6oFeWUH+Jn5TcPiaR86u0Gcks6DvYwwfPNWHUD0jTobF3q3JpMIgTvOr1Hg44LxXGISZh3MDO4Z4gn1ZRa1FrkomzoXRx+1JoCmVKBxkdsFFlmq+E3EQjCfO03isF5UDFUYrL7Q5UZsnxX30vCo6hwITt/gANuI7kR5R3twa0OEuQOBhV+UcAsrL+iQNXaNNlkLGLyRy8kA4rFR38wHe/2cYeM6dJCtHOCjUWWk01hwwwfvKThSMknEbarIaD7d7PNT9iVNM/SyxxJIW8UJh7Wc38RcS/PiFR15V5ViVZu2jFULOSF6SKJjz5CrA5CCmzPcqeoaJRVf35c7CQFcVuyhpWqlyFAs6Yg+W9EflN2HYlri9cW2BZ7fJvxIosy45RG4lvF11+XWXRXknbh+7bwbgYEmtnGAh9XEymx1V+4gh/8kl20O+OU4gQ7r3CxHQa4Vt/1/Fu3VAnpkwPmUM/IdHRzj1ZnOomcB5LW1EK58MpkVjYBTAR83rd mZPUEwLp Q0l1AUNJIG9twc0Y6T9vYsCf2gK2NWLyQz+bQ92tZMqlgc0uJ7eLznHOo+DaJrzMzzl6E5wYiS8+1jgES7Zu4God4dkpRDEV/5DPB4PDkShGuWKSEMKwQnFf1BD6GFU5nzYPYWDu5NQQLM6GlMi6y9SWnHfn5k50m4lZRZtEC72B/pJB8y8lHI960tfEyu6OtTyS3b2zWIfEXKuz7D0QOA2fuL0DP8TRxwY5gfw/FMeI3jvnRhuxGuAe8dt6dA7sSxnO408st9JNv6SACrhCWm+NFYYmB+mgu6Djfh5GIbvMwubJA/csLleS6tX5ycI2OVaQaxQUYD2mwRoROFWgLLpJS3HBk1eIUp2sF1gzlXMWvEy1zHaAzQNoLykvAWa6GgmHnKEVgTBEkkcvNTKFkoEiRtBDvnhbWSv0b0Z2l+MGVMK5l5H4g1/jEqwAUnsdkTv3NnMG+1DHVdNWZjqLb0gxwTyeTAIfmj3fg 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: 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/