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 6A15ECD98F6 for ; Wed, 11 Oct 2023 07:38:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 95C5D8D00ED; Wed, 11 Oct 2023 03:38:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 90C758D0002; Wed, 11 Oct 2023 03:38:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D3BA8D00ED; Wed, 11 Oct 2023 03:38:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 6D1E78D0002 for ; Wed, 11 Oct 2023 03:38:57 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 3C7DBB470E for ; Wed, 11 Oct 2023 07:38:57 +0000 (UTC) X-FDA: 81332379114.07.96DD519 Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by imf05.hostedemail.com (Postfix) with ESMTP id 8B51A100013 for ; Wed, 11 Oct 2023 07:38:54 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=alyssa.is header.s=fm1 header.b=K+QEtTpU; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=c+u2vqe0; dmarc=none; spf=pass (imf05.hostedemail.com: domain of hi@alyssa.is designates 64.147.123.21 as permitted sender) smtp.mailfrom=hi@alyssa.is ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697009935; 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=tguG2aXRGfx+BtSSdosiAuKFgDBmx4SGy972Szw14Xw=; b=tabXlOV+PNXYlkwBvkYSN/ifZc45ZiB3ikAHogK8C0IzBg2ZPJwhBaVIwGeCvwYZhsX4Zz HNrO3PMcl/cr/L7WplcyuEvyY8THi49nnlaXbFDuvXBVNfvuinw+wC/eyu/lGmxLYrbO+L UjEixhx01tFyw8kZi3SVVH2DW2pF510= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=alyssa.is header.s=fm1 header.b=K+QEtTpU; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=c+u2vqe0; dmarc=none; spf=pass (imf05.hostedemail.com: domain of hi@alyssa.is designates 64.147.123.21 as permitted sender) smtp.mailfrom=hi@alyssa.is ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697009935; a=rsa-sha256; cv=none; b=iCRWybPLDNTveITAlo6MnX2hMWIOPwMOKYER9zuvgHjNnJEXTIfqJuh9k6QFKElc3OeFwN e+6ae7Pm4tFfiCFpBr6gpVGu2Xqbodfh85UfHtE5Rxjq449htZSk5Tq9zkj+Oyo35k+LAv XIc1BAMjqY0iT6GOQuPvJkMMps+BRKo= Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 291A332013E6; Wed, 11 Oct 2023 03:38:52 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 11 Oct 2023 03:38:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1697009931; x=1697096331; bh=tg uG2aXRGfx+BtSSdosiAuKFgDBmx4SGy972Szw14Xw=; b=K+QEtTpUgF75OMaZQu awOhoNWZjzQIEpgcPHus85fajdr6TqnfsBJsZ5w7/Hyhd5QxiVx3HCDAAo37Z3wp uo0ynzf3trRDe6iP5zwOfJB7CC7V1eJgWfm2Ojv3DEy0a+TOQYnL+JNXH7l1D9zP t3JDyNXQ7XjIcnHqFTBoFspVyeCbBmyZrre+s8SKaKV+xt4oyrefhoUOPFVkbycq knhid9ikyWWQ1XD5mmQrvvH3lf9Fm/xrBIkYTiA4aisF04SeC1P/Ir7Wnh70XRlj eg4iI+L6gbpK/gmv4HafNsS373CQHPBuKtwHX8Wm++/bMqf9hHQbZFOTsJcc7DYa dJIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1697009931; x=1697096331; bh=tguG2aXRGfx+B tSSdosiAuKFgDBmx4SGy972Szw14Xw=; b=c+u2vqe0zrP/tiv8UGK023yIbdcxV arlU0jbHPpMOjz+/tXj/1IuUt2tZ6NV3OfkE8Un59DtrdF+QXfU7J7Kfh+9jEmUv TeexUfps7fVBRWR8JnAezLtRb6eSRjlQk2wIYEx2KTG2dcyL+sZRCeMpASUCDLPm hdRsd0PGOE0Qkhz+RnhfvJvnmtHWVBJ8fSxsGQ9tvK7vKYLlK+jfeLHl5rGK04cV 8y0S87gCyHQ4QhFx7mEF6RBDqxV8La9i8+yPeuK1tKkrPQInD9Peden9D1akrm/p YkBfAE/0A11vsdNpKV+AuwR9H8bdy0mpdUed0GnScvlFhDmjsy8+gBxRg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrheejgdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufgjfhffkfggtgesghdtreertddtjeenucfhrhhomheptehlhihsshgr ucftohhsshcuoehhihesrghlhihsshgrrdhisheqnecuggftrfgrthhtvghrnhepteehve dugfejgfehhfeijeduleekleejgedvkeeuuefhhfegvdevfeetveegteeinecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhephhhisegrlhihshhsrg drihhs X-ME-Proxy: Feedback-ID: i12284293:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 11 Oct 2023 03:38:50 -0400 (EDT) Received: by mbp.qyliss.net (Postfix, from userid 1000) id 461BBF0E; Wed, 11 Oct 2023 07:38:48 +0000 (UTC) From: Alyssa Ross To: Kees Cook Cc: Alexander Viro , Christian Brauner , Tetsuo Handa , Eric Biederman , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] exec: allow executing block devices In-Reply-To: <202310101535.CEDA4DB84@keescook> References: <20231010092133.4093612-1-hi@alyssa.is> <202310101535.CEDA4DB84@keescook> Date: Wed, 11 Oct 2023 07:38:39 +0000 Message-ID: <87o7h5vcao.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 8B51A100013 X-Stat-Signature: qo7kfhw1fwmo5wpnesa5whtrg9dd7su4 X-HE-Tag: 1697009934-883535 X-HE-Meta: U2FsdGVkX1983fpyKpRCKBV2Gbg0W2K4oXVZOiwQUJKGXA6WD0fGm3tbcGwM2wST052cnigsXjNTVWlK7lWIMUvMpQqSYy8By7EOffw9qlULub5DdOIWE59+uyDCrhgyw0APplg3MWGAXl5hKPz/GMh/o9EVvq5kIUfjkstLGq8JxSkzRlJirHyVQbz2ON+27oSJOyNGGWLG4yLRMiFtUMNipPHpPg4zdgOGNuCX6fkBujVTP4svtN8/r18LnPahw5NrqvsqmYN0eW3aYf4SirFyXKbgxAQ4iPXFOB5mjilK0LP2ZGbEM6fyXIEIEa2bnu2AlNPGwe4q0DyJ2YDhnkmXDAyTsqEZLUTQBYNq7PYXutZAbA+8pohKB66l7B13kciHsFRnRRa8g6rVxSHM8sAI5LZyBlfCfPiWHVeqp0LMdxh0w/uwn12hSlN5FPkRh/i+lhyAwqmGOGNbFpDSj7EIz58/pfBvDM6SWqIS2QeZXyw+t9kB7HTVOk873VfDigCauWWLyQmzhgJ3/uoHDjHtIayBgntksGG9eT1P8HwAwOOX5nOdVNXLQXKuyiqUjxJgaFWC7G2kUl5qXw5nR/K/Bcsokvrk8L4mTJ0PmnzVDd9qg1ABGCGopPpxfmEi15g9i8IFOHn8MRW8ewc+xZqfMAR3+t2E2ufUwJuv/Pd+zXPPZUZ+GVw9rCTtRbJDrqEus1YLU2+0X/2sW+ptwgR1Krtp5Sm39tA9R0B0mrPnC3/HZXUPQNOP0mp5q/oy3U2w3l/fg5o//W0m1L3AV+FdGt+foP1NiyTrk6DqpZGdDre1dPaDaAM8lVMZ3ao4yoTUBD5BV4coo1iKPmerNzOsfGoJ3Bf3l6aWUbIkqD3bpMaanmAu11Rl5uEuvgUjU992CuqrlJAeiTWnvJlvT5TpBMI6b1X1UDjntEq+nIx1vZ9uts6H2Q4jcX3UY86BX6AbjdRH922WmRPpMPL IAmVp+xI xVUFdlz2U8fqZWTCqwcdvS7Mvz/RNNGDA5fNr4Dxrfe2ZPi6A7VKO2jRA8gyGKMW3viCa4+lsU8QpXxCoxOn9yUh6++T8CREpodsbjOJ6PneP7IQfCHiCKqAT5R/kABck9p93jBVX0ko4/xa/vj/GbZ5jMSJNp0lcodZK5lhc0TDkGUchftN9k84ZWQtMOZ5TMTEOn9W3z8wgmCJzDwtApWX9LjjM7nXf4RgH3amo7czOb52vA7c/aFnTqM69uGTTYfJnniRzU8bsTjrwV5vZErvDWM2zKNgY1XnlznSa9LRlaZpZTN1v443O9rkCEL9YDw/kYu5fZ/5Q+WIEcuQoNomrF2Gvsqd63rmXZ8nO6gsARxBKuvLKyDM8OUqDgrZPypBbzaqZ5AQO8IPSsSBNbCP5Xw== 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: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kees Cook writes: > On Tue, Oct 10, 2023 at 09:21:33AM +0000, Alyssa Ross wrote: >> As far as I can tell, the S_ISREG() check is there to prevent >> executing files where that would be nonsensical, like directories, >> fifos, or sockets. But the semantics for executing a block device are >> quite obvious =E2=80=94 the block device acts just like a regular file. >>=20 >> My use case is having a common VM image that takes a configurable >> payload to run. The payload will always be a single ELF file. >>=20 >> I could share the file with virtio-fs, or I could create a disk image >> containing a filesystem containing the payload, but both of those add >> unnecessary layers of indirection when all I need to do is share a >> single executable blob with the VM. Sharing it as a block device is >> the most natural thing to do, aside from the (arbitrary, as far as I >> can tell) restriction on executing block devices. (The only slight >> complexity is that I need to ensure that my payload size is rounded up >> to a whole number of sectors, but that's trivial and fast in >> comparison to e.g. generating a filesystem image.) >>=20 >> Signed-off-by: Alyssa Ross > > Hi, > > Thanks for the suggestion! I would prefer to not change this rather core > behavior in the kernel for a few reasons, but it mostly revolves around > both user and developer expectations and the resulting fragility. > > For users, this hasn't been possible in the past, so if we make it > possible, what situations are suddenly exposed on systems that are trying > to very carefully control their execution environments? I expect very few, considering it's still necessary to have root chmod the block device to make it executable. > For developers, this ends up exercising code areas that have never been > tested, and could lead to unexpected conditions. For example, > deny_write_access() is explicitly documented as "for regular files". > Perhaps it accidentally works with block devices, but this would need > much more careful examination, etc. > > And while looking at this from a design perspective, it looks like a > layering violation: roughly speaking, the kernel execute files, from > filesystems, from block devices. Bypassing layers tends to lead to > troublesome bugs and other weird problems. > > I wonder, though, if you can already get what you need through other > existing mechanisms that aren't too much more hassle? For example, > what about having a tool that creates a memfd from a block device and > executes that? The memfd code has been used in a lot of odd exec corner > cases in the past... Is it possible to have a file-backed memfd? Strange name if so!=20 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAmUmUP8ACgkQ+dvtSFmy ccC7DhAAgtwwDA4fn/aXYdqL7F7R68MtABW7LyXGNCjuGEmP1kZbkg0lEyEc7UCr +dn5F8EXSzRGK5huEn2RzhPNnzU28KWBxmXN6bFED/YaCDKYBC9MM3cGUaXEbTPG fQyQAGo36qlB5m/hS5j8XMuM/uIcYlsEk8qkgpAkfebNAMEKTxxSTshUSFRyq5wa KTT76URCwrxPooy25Znv4JqjsR2taMPOvXnVV6bf8DXcCNuI+eVeu7J/nZ44LyEe 0GykVN2hBeUwuSQEkyR11iKbaoxlTgYRyMMYOw+ylgaBUgfsJn88tGk1qCDlfRW+ /B1QUJephRtk0LsBLGcjeEqATCJ4ITZaDoIe1CI1pUjluR8tJrMxhmhX9dlyWvjb b4CRpFck2sjXbDaP36sW9s7F7qgp9NspPLzSrcgVmKNPY90c/sTVvrkd8CXca2px 0z1Yxa5P1OFPSSEwBbwqNUpTjsRwQMfsq8TUbcbzJ1h++9F6HEce79WkMz6AHGPD c/rpzHS7MqbHCj/nxHP9IuCU1XyR8rIXRynD9NFdDtp8bJMGwvGselrRHfHVz9+X tzX4PUuz9k+3PEoHSOVrIaHItIY5Ml7i5md1wpeARpi0lz7CeUvTWMLxXPb/Xc4Y BMlmXuKi7CZmjYS/zkw6d1KGddkMhyeZ2I76hkbyGTbfbKDNsU0= =S7sC -----END PGP SIGNATURE----- --=-=-=--