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 C4394C3DA41 for ; Mon, 8 Jul 2024 18:00:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 444B96B009C; Mon, 8 Jul 2024 14:00:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F5726B009D; Mon, 8 Jul 2024 14:00:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BC366B009E; Mon, 8 Jul 2024 14:00:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 0E2916B009C for ; Mon, 8 Jul 2024 14:00:25 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id AA9B71214FE for ; Mon, 8 Jul 2024 18:00:24 +0000 (UTC) X-FDA: 82317349968.21.A957866 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf26.hostedemail.com (Postfix) with ESMTP id B26B014001F for ; Mon, 8 Jul 2024 18:00:22 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Lh0ffxK8; spf=pass (imf26.hostedemail.com: domain of fweimer@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=fweimer@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=1720461608; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ur8aidqR86eMlg5hVh3kQFIlHZgeTOY5AvM2A0WS6wI=; b=5z3CP31pwGp5EW8bHAmpRN1QmOJqoPqwT50zU1Rc3snTUT8ZSOxGLqILaQEvljsdp9xT9v 3sjqpGeA24Ylu+1X7C3QmpPt9Rc4BilPPtjUFd4TXbzinu2ZLuzsvQZQGzTWfSB6V9ZO6x 0MLQo9i7I+GvZYL1AaZzNNvEPQOX6Z0= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Lh0ffxK8; spf=pass (imf26.hostedemail.com: domain of fweimer@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=fweimer@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720461608; a=rsa-sha256; cv=none; b=PEZGVKhiBuZF3MywJLlGnezdgnx8mwQNOieDb2Oml2vpyZ6EgIz0dVfXnltuPYvHVH0JmT ZbKIAjPxIG+6HCxFfIeN0qBdTZyIpidJ/orMEpoq2cbO8M/yU77riMI12LYAbRljtSMXar gaRnpQI5DPd4+Ljtm6aLmfeplW0BZIs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1720461622; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ur8aidqR86eMlg5hVh3kQFIlHZgeTOY5AvM2A0WS6wI=; b=Lh0ffxK8m9v9H/733gYuiKVIRHlB2ZcxbQ9wdG1EryDicy+ZcZFu22c/t+kl8gxhrX6j9S bAVZoR7odXKsfUDCjiUIYMaitmS4H/Ghoye3NYKZZnqdd/ODIVYjPKdeJDSts7Or88UgIL tKtxFSYWuy+d60JfHVbKa7vOv3w9FCU= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-689-BLTMqZN-MRiC1hCbXOT78Q-1; Mon, 08 Jul 2024 14:00:17 -0400 X-MC-Unique: BLTMqZN-MRiC1hCbXOT78Q-1 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id DB5361956048; Mon, 8 Jul 2024 18:00:07 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.45.224.113]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A030B1955F40; Mon, 8 Jul 2024 17:59:48 +0000 (UTC) From: Florian Weimer To: "Eric W. Biederman" Cc: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= , Al Viro , Christian Brauner , Kees Cook , Linus Torvalds , Paul Moore , Theodore Ts'o , Alejandro Colomar , Aleksa Sarai , Andrew Morton , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Christian Heimes , Dmitry Vyukov , Eric Biggers , Eric Chiang , Fan Wu , Geert Uytterhoeven , James Morris , Jan Kara , Jann Horn , Jeff Xu , Jonathan Corbet , Jordan R Abrahams , Lakshmi Ramasubramanian , Luca Boccassi , Luis Chamberlain , "Madhavan T . Venkataraman" , Matt Bobrowski , Matthew Garrett , Matthew Wilcox , Miklos Szeredi , Mimi Zohar , Nicolas Bouchinet , Scott Shell , Shuah Khan , Stephen Rothwell , Steve Dower , Steve Grubb , Thibaut Sautereau , Vincent Strubel , Xiaoming Ni , Yin Fengwei , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] binfmt_elf: Fail execution of shared objects with ELIBEXEC In-Reply-To: <87cynn3hzv.fsf@email.froward.int.ebiederm.org> (Eric W. Biederman's message of "Mon, 08 Jul 2024 12:34:28 -0500") References: <20240704190137.696169-1-mic@digikod.net> <20240704190137.696169-2-mic@digikod.net> <87bk3bvhr1.fsf@oldenburg.str.redhat.com> <20240706.poo9ahd3La9b@digikod.net> <871q46bkoz.fsf@oldenburg.str.redhat.com> <20240708.zooj9Miaties@digikod.net> <878qybet6t.fsf_-_@oldenburg.str.redhat.com> <87cynn3hzv.fsf@email.froward.int.ebiederm.org> Date: Mon, 08 Jul 2024 19:59:45 +0200 Message-ID: <87msmrdasu.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: B26B014001F X-Stat-Signature: boxu1e7ugy6qx41ycem59krjw5xhx5zh X-HE-Tag: 1720461622-488793 X-HE-Meta: U2FsdGVkX1/FXkhkHZNSUwgks2QzPaexSrAPrs8DCPfo7dVJnXwHFsBVDPGJfHI8mD8pXvD9lRouQKfKW0I73du4HTku0hWvNver4AxlYxba2suWHU/8/QZeVOK8mV+Vauy5p+oy4aSnI4QO9s6CifKgXoHY67va0XBYiabwFVtK4U3ZVPyz6j6UxjGi5sbrc5kQqGqPJoenbGLxra+tlgcJukbyBga/ELiVdMLlJ680qafSWedaSn1hUB4kjB/6Y6OnYA9m8z+Orbkeo7Lc+PsILdxzhHJCCOLAXRgS7HPiH8479r3XELZb/iVxWKG9AGCkQydFCGSiROPyEwCe6nCc9DTEicoCgDcK9yKMKzLKhkDyQjj2Bz9V10N3D2LfPgRtBEOwrkGASN57fpi9l78LjE8b3llnDIkhTHsylOnVzaB6BS4j1Dq/Uk4eJe+A8x2VOn5B1+kxFraWbHsBfIHXPx9str185to1MzfwGMwnV6Lj/d+LSBN23KyI4oo+FNH7G2skqsk7UKEhIJE3VwSLOplkgBkxJ71PcJmVBHgdgKv7EHXMYGMsi0kmOCXxiz2glxOBf/kfUdvJ/7d12hpHXrKJP2ePafYa1B7yooHzU5erZhW+T0mIPbzUWFu5AQ6CS7v1rSigi3usWPOnds8zaX+o9jJYj5y276CozRJMxmpVaC3Wk1BZtay6oQXJAiq7e9h70vhAOZigJwymi4qFgZeYNR3ZhMv++NUECsdcHodsRtfDL1ZtE9yP/23W96yBkjQbHoe44wKmIekdDWTz2x/B/WPYZIVK0b9O4GayvQljXxp0vW9n5dTRHIfuDoQD5wBz5Qs1GXT0ybPH0LWD8QEt8lr4D0RObNmDSo0bjtKJucPQN2oU93seQZT//GYOapEF9XP5w1xO3pG8JGPG8hRo37DwNLcVyO5xWNoW9VnQ0gg7oqxM+cqshqLvJUOS6pM8RdW1cfTD7Pb +JyQ9m1F /pCRXEJA6Fqf13Lu6N3JejSHvSbNCmJEAESeNpammw2T7CRi7sdsK5HiQLFF0pDj/1/1udmPm2Nk9iJSDH6JC0TeOeYpLh4frOu2o0JH3Fn2HXNEbJrs/uNeXK4Bvrsr7fCfGZ3Xh3349U8m+hNz853Ry/XnBbY04XSJvqQyiGzzy0Skt7XuZcg4oss5TRYxHVrUqxI/VneEhxjBb7BANe7UxlCvRzQ7xANidEXqvfgh+1Wx05VsjFddzWLrpY+FfggagY0MuiQWqbadX76E83F6zKltQY8Txa2zSdH7BZtcTbJsZA5mU/29iTu/hGptHqlgrmxVaC+PXzeNi07lccIld1Q== 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: List-Subscribe: List-Unsubscribe: * Eric W. Biederman: > As written I find the logic of the patch confusing, and slightly wrong. > > The program header value e_entry is a virtual address, possibly adjusted > by load_bias. Which makes testing it against the file offset of a > PT_LOAD segment wrong. It needs to test against elf_ppnt->p_vaddr. I think we need to test both against zero, or maybe invert the logic: if something is mapped at virtual address zero that doesn't come from a zero file offset, we disable the ELIBEXEC check. > I think performing an early sanity check to avoid very confusing crashes > seems sensible (as long as it is inexpensive). This appears inexpensive > enough that we don't care. This code is also before begin_new_exec > so it is early enough to be meaningful. Yeah, it was quite confusing when it was after begin_new_exec because the ELIBEXEC error is visible under strace, and then the SIGSEGV comes =E2= =80=A6 > I think the check should simply test if e_entry is mapped. So a range > check please to see if e_entry falls in a PT_LOAD segment. It's usually mapped even with e_entry =3D=3D0 because the ELF header is loaded at virtual address zero for ET_DYN using the default linker flags (and this is the case we care about). With -z noseparate-code, it is even mapped executable. > Having code start at virtual address 0 is a perfectly fine semantically > and might happen in embedded scenarios. To keep supporting this case, we need to check that the ELF header is at address zero, because we make a leap of faith and assume it's not really executable even if it is mapped as such because due to its role in the file format, it does not contain executable instructions. That's why the patch is focused on the ELF header. I could remove all these checks and just return ELIBEXEC for a zero entry point. I think this is valid based on the ELF specification, but it may have a backwards compatibility impact. > The program header is not required to be mapped or be first, (AKA > p_offset and p_vaddr can have a somewhat arbitrary relationship) so any > mention of the program header in your logic seems confusing to me. It's the ELF header. > I think your basic structure will work. Just the first check needs to > check if e_entry is lands inside the virtual address of a PT_LOAD > segment. The second check should just be checking a variable to see if > e_entry was inside any PT_LOAD segment, and there is no interpreter. I think the range check doesn't help here. Just checking p_vaddr for zero in addition to p_offset should be sufficient. If you agree, can test and send an updated patch. Thanks, Florian