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 3C849CD98C0 for ; Tue, 10 Oct 2023 22:48:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 782E88D00E7; Tue, 10 Oct 2023 18:48:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 70CD98D0002; Tue, 10 Oct 2023 18:48:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5AC788D00E7; Tue, 10 Oct 2023 18:48:18 -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 3D6188D0002 for ; Tue, 10 Oct 2023 18:48:18 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 0D247C02B8 for ; Tue, 10 Oct 2023 22:48:18 +0000 (UTC) X-FDA: 81331041876.12.05239B3 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) by imf01.hostedemail.com (Postfix) with ESMTP id 14EAF4000F for ; Tue, 10 Oct 2023 22:48:15 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Qdf2IJQR; spf=pass (imf01.hostedemail.com: domain of keescook@chromium.org designates 209.85.216.46 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696978096; 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=umaq0MSSZP4nebV23a71EOhR8vcMwzVfizynVgVctt0=; b=RcuD+fkU9fOCV21/iP0hn58YCgcfKHfcEJwy56/bXDq5hL3uxl7cGUl4vpE88IJZ9/E7YG YxsnbInS/pP5r+4Zccm5V4GFN1bSRZNmCYuTzlZKnHqVjtBXCljJZOp10JvfmcoevjsA0h 6inQ/L4aNUEY9aEJZDlP2KwCMHTn2Nc= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Qdf2IJQR; spf=pass (imf01.hostedemail.com: domain of keescook@chromium.org designates 209.85.216.46 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696978096; a=rsa-sha256; cv=none; b=687d5iPK/s/BPClwWv4l79RUYMsj9slGsNk7E8J11zIi5Peku9KY1QE+AKC3ZnfUqG1hIe 73aRH0v8gDxGGSvKqZ/bGtjAMZcsPs2lxS0huWKvnBDZzSPd0+6cxTFcOU3MsQqquxuSl4 6VpupYwqAUZIknzs8vhRB72EH44/KJs= Received: by mail-pj1-f46.google.com with SMTP id 98e67ed59e1d1-27cefb5ae1fso786036a91.3 for ; Tue, 10 Oct 2023 15:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1696978095; x=1697582895; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=umaq0MSSZP4nebV23a71EOhR8vcMwzVfizynVgVctt0=; b=Qdf2IJQRpvK7WPLfUD7JxLdad3mUW0cQUXxat6NRQi3FxaBSjNJgNy7f/2Wr60xWlp kbumVvY82PFaZ3LF17/838FfGp4ApOQMfKq03SiFscS+AkJ7xvx0Sp9N+60CFo7i4l7W GaamkDEziVkZupQ7wCySiHVJtCzGVZnoqViRI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696978095; x=1697582895; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=umaq0MSSZP4nebV23a71EOhR8vcMwzVfizynVgVctt0=; b=Pemj9tZYBB4PiH8ICQKwZ9rZp7WVkb0fGgjD+BFU3qWBOEwwA6hcfXiBkVzJslhBoX ROLFy2nF8MpaGNFAMu9hQmBO0dIHZFUly2MFP0NrWcPPRXXqWlN75x04IxUYvqNkJbo6 j2wtjr7q9bPUT4Vj1KZPl1pwsjCgtVa4OVtpSQh+KUVm6KojfPUIuJrM2Lm4i5jZvdrV 1w7SBj8JpJBZf+uJtyQqHmDVotVzjJ/aC6kPSWCzFwJzaa6XoXvRtwYUIEGWcKb+XEZX NDUvWm94VM/UBZIcLuKZX04+EKC2usLgLWiuve2UY5v310KhJ9ncitqBklmh9L1C7LpD pxLA== X-Gm-Message-State: AOJu0YxBGP5fFZ9lE9HyP2JgNByFzeTtElvkDx7Y8oqIZF1Lv/SbsQyM j9ExW94/UKhVS7X59bFZm7IXNg== X-Google-Smtp-Source: AGHT+IENpAsAI6YM70l2/vXTEjXOUieOiaxbcuD746kJfEGMhyOn6kSyHuft6Mnk/j+JgWdkfG/7Xg== X-Received: by 2002:a17:90b:1c0b:b0:268:3f6d:9751 with SMTP id oc11-20020a17090b1c0b00b002683f6d9751mr18076356pjb.23.1696978094874; Tue, 10 Oct 2023 15:48:14 -0700 (PDT) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id s15-20020a17090a5d0f00b00263cca08d95sm12419653pji.55.2023.10.10.15.48.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Oct 2023 15:48:14 -0700 (PDT) Date: Tue, 10 Oct 2023 15:48:11 -0700 From: Kees Cook To: Alyssa Ross 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 Message-ID: <202310101535.CEDA4DB84@keescook> References: <20231010092133.4093612-1-hi@alyssa.is> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20231010092133.4093612-1-hi@alyssa.is> X-Rspamd-Queue-Id: 14EAF4000F X-Rspam-User: X-Stat-Signature: cuwcyym5jso8xodjj1utkfrh4ao9rxzs X-Rspamd-Server: rspam01 X-HE-Tag: 1696978095-875072 X-HE-Meta: U2FsdGVkX18QioRpx/zd2WcFiAzJuB0H3gKpCbKJV2xHHZv0HurWR6owFB4sJO6pJCD7DnuPICSTvJcw469nSijXLJOOAk49r1ovYevKM+wSVEA+v4NCAmFwYDBnBuxz0qJuoxZPhTtQsiZaH33fAXB2acHoPx4vDrg59G9jG5PG5YVb9v0l3+e2M/bVaZ2HIlyaWX5kAuwhuCmT+jWKYLFKNAE1Lpc5Hx4+KPcx26jg03ZYK3euJtnjhi7elUf9crISC8Tvrv5qXEwoNLGbusxzYWTgsMWuVVt/CW68ktTeSaucIykr4D5yjEA5lXRflm6lEKXpsXxe3ven7sQrTSa/FmSZ96/rkkMCsVFYOOXplzxzbacla4z4t5hZu28Ng5zJejoG8AwEYXiPRyXrTwEvqUV5CIUVdjkxGn+ScUf+bAn0lX15ohJwtpbxsI+69PnnAr3Fh9aHlQlK2LEYVU8+PXzCHllT+h/WiPV/lG451yVFU82HmgQHwy2ehMz+s3EvQ9kUKnQz2TYZsHnK2JzYLlSbULtuVb5jRcpW2EiToCOR0svX0MA3EALwzOJhFUnkiP1Fw4UCGJYsonlVkv55svfRDuuDXsaYHp1waZ9xqPMEzXk8cxLxH6lU6DQCafyz8V8HQbLjeJo7jmcrQJq7Vm3cNR/CFoIZA7cHau41eufeMf+SjMM/3mnrRfp7wlZYHM74zwh40UbuRPIJG7+MzG24n76y60XHVLrnor7dkVYaiHBV2YZpIbsq/PcW4g2D3PrAdyo4A2gcxTuBWJGDfVr9JZ0+3mUitUilyNS5+IUk5FHIaHkiJrcfkR9csWVT/P35m4GpbSRkHq7bSus8KMMCHon7RhpKC0NRz+czsXkP8k3ngd0u6Kyhq7AHXruohaoB1LoU2jMzJDACdYX44CBQoCVhqHPmCNWMgbzXcTdYC0yE6HaXASFknxKl9N9nEeITxBClNo5H5GW ca7JUrdD rQh0QLV7pQaWW50USdoVUo8iMHYREBY8BI86u9S6oXE7bzAh5GhU08uO69My8cjq6e+tzU4I+QsOzGbAwwtURw40GpeFwzjqLvCdJOpH2MwId1fGW1irIgsoqW6RcyZpwbVHqbmkY4VDr94q2gSuSY1AooZf0Ad+OG6/IC3nh3OvZfFJjAE71Ss/yyTYhyjlIi9oqfa5RQleJ+UvYxleZneuCQ17r9PGVOMZuaDCe91Lz2Ej9sWDR8ESCqMKklhOMVXKhjnfn+LT03aLWxFrb+e8oyiuxAgymQgwjmXlxoY+h9xWut2X6YRSvgOYSDrKphbfh+7wOx/Jp50+iwkTVJGaXHkX38WDjeu1d X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 — the block device acts just like a regular file. > > 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. > > 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.) > > 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? 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... -Kees -- Kees Cook