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 15CF9C5AD49 for ; Sun, 8 Jun 2025 16:33:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 356346B0088; Sun, 8 Jun 2025 12:33:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 307006B0089; Sun, 8 Jun 2025 12:33:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CEF76B008A; Sun, 8 Jun 2025 12:33:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id EF6466B0088 for ; Sun, 8 Jun 2025 12:33:03 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 9A1A7C1BD3 for ; Sun, 8 Jun 2025 16:33:03 +0000 (UTC) X-FDA: 83532777846.03.4522A41 Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by imf30.hostedemail.com (Postfix) with ESMTP id B0D838000A for ; Sun, 8 Jun 2025 16:33:01 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=IDN44jXu; spf=pass (imf30.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=pass (policy=none) header.from=soleen.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749400381; 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=OuRYivZ74nBEObAg4Esdur1pUm1rPSerTOQh0jJQjUg=; b=TAo9X8HWhyLuiAQLB1ugUBFcI/0fz8f+K3bJvo8MDWuR42BRELFsPy4s2GlbCLnCje18xO K2sLXp0GBXY6J/a7XUp/bkgp8DDryx/4AuDOzm3AEBFBpxiBvRl4zud7SdVUhoAdRpg6lD Ff991suncNFaj+Y4c+KmtPcl+oJi79s= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=IDN44jXu; spf=pass (imf30.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=pass (policy=none) header.from=soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749400381; a=rsa-sha256; cv=none; b=6TlQ5mmhyoAHb/GVyz3Bo++u/Ps/XTWzKTPbDTPPBeNVXJ2YO6EGyoQiGb7Wt1lgi7stGh 7qvt6ek4ENaGJRCo3j8kooq/YKKt8etmv9o+hLreCzIrdBUNXnt3HQq8hemClKdir3NeQy 6LBCisyD0ePrqQV9ACPZgkPlagOnblE= Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-4a58ebece05so41365971cf.1 for ; Sun, 08 Jun 2025 09:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1749400381; x=1750005181; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=OuRYivZ74nBEObAg4Esdur1pUm1rPSerTOQh0jJQjUg=; b=IDN44jXuIo18PJqjp7sJOy6ReSsfzfLLa6ppohONHsisRRC26TO/jaQk7t/dxL6Y9Z k8nm4byrY9sEq7ZI5l4RQmtay765qrHKvj4u2DFag8BuzPubdp8ky78qB2D7XITe7BuF 8HcSgXWGMOLo9g7rEJDItm+YhtZ7591GBLFSoVAAX/xIM2e6iI4ltRQ2To/WwONwMQb8 6rcMhhaGO6T6dORRSeOAXtDG42EqZJywJHrZPpfna/2Bc9sURAO+RKFMq+LoBtjJB3Nb IQzjbo9pQGDes1kwvq/SZeiUuce2C8JwefpUQGge3W3qUJdndJq8nWilfTctNNygLjSq rXMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749400381; x=1750005181; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OuRYivZ74nBEObAg4Esdur1pUm1rPSerTOQh0jJQjUg=; b=j66iOGMGhd+3ApBSuIhtx2TPrLVuCU8TQPfkS64V+HHbBzexqzp3BymHul+Hlafrki xchR9pSYLWAd8G1wki6qlBFJqvL93LKiAG3i9jF6qf5Dnynw80xGxI2VoL+/kj8YySuw G7hfZpcJXUZXETX7GazY0WrY7m3Lj9jVoff8jINSEzxVqzLKaCz1nv9ys41mMN6fY//0 SIGTipC98IwD7oN+UMwVpzwdcixcu8IFqOlN7jkDpIe6XRcacgXW2c1xDYg0nwS7366I mCnmj/wtcU98CBVA4fjHJNJ8OKUsmKPPyost/5/VF2d2IpX2pr1HUCyke5y7t6cbbcd7 LvfQ== X-Forwarded-Encrypted: i=1; AJvYcCVkVSYphRo13IyTqKwcdV/7NEDbSEaWtpWPjkZ/iZr9OzZkTbxYowqM7oEZvHZOJhbQFebwSG7Tiw==@kvack.org X-Gm-Message-State: AOJu0YwmQpbPC2FGb0txSVU8zZj5RdP/3lj/SaEKLRLETUt+r7ueW7TJ Qd4fLJnQapMMdrbXX3RKH47vOz5+dB6kj6zrlnRpc/a144Cfn1/Qs+WV9uBLykHyhE+B30DGsFm gjeyjbkT2i4lgKXvEo0boTble1wjsP2mktP0f53VnTQ== X-Gm-Gg: ASbGncsjiShDW0popGgLx40cRXrt/z5bQqaKYQXte80OXIzTUT7RV5EGDtK7PSe+vid CCfa4BTpVMMtMjFkrdN5h/oLkCBj1S/ewbrAIaWI3P8zs4kLd18aIlXH8eK9UZ53mtCx06ksgoi zlW6EiW+Hkz4TeIc0ceHpkU3dfIeL+CQ== X-Google-Smtp-Source: AGHT+IHM7A0yo5EwU0URGl5qPD/nSWVFx1Uch1mkQMPpJ9jiESTc768PtJKyMnU3hW6gMNfEhsZROCE5EGkLP46xzl4= X-Received: by 2002:a05:622a:5a15:b0:4a2:719b:122e with SMTP id d75a77b69052e-4a5b9a40939mr176026001cf.18.1749400380740; Sun, 08 Jun 2025 09:33:00 -0700 (PDT) MIME-Version: 1.0 References: <20250515182322.117840-1-pasha.tatashin@soleen.com> <20250515182322.117840-11-pasha.tatashin@soleen.com> In-Reply-To: From: Pasha Tatashin Date: Sun, 8 Jun 2025 12:32:23 -0400 X-Gm-Features: AX0GCFshnOWS2B6OWr1wN-XQzYf4DQDY1vQdBPzBZzA3h43rNR_DwPDF1zPI47g Message-ID: Subject: Re: [RFC v2 10/16] luo: luo_ioctl: add ioctl interface To: David Matlack Cc: pratyush@kernel.org, jasonmiu@google.com, graf@amazon.com, changyuanl@google.com, rppt@kernel.org, rientjes@google.com, corbet@lwn.net, rdunlap@infradead.org, ilpo.jarvinen@linux.intel.com, kanie@linux.alibaba.com, ojeda@kernel.org, aliceryhl@google.com, masahiroy@kernel.org, akpm@linux-foundation.org, tj@kernel.org, yoann.congal@smile.fr, mmaurer@google.com, roman.gushchin@linux.dev, chenridong@huawei.com, axboe@kernel.dk, mark.rutland@arm.com, jannh@google.com, vincent.guittot@linaro.org, hannes@cmpxchg.org, dan.j.williams@intel.com, david@redhat.com, joel.granados@kernel.org, rostedt@goodmis.org, anna.schumaker@oracle.com, song@kernel.org, zhangguopeng@kylinos.cn, linux@weissschuh.net, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, gregkh@linuxfoundation.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, rafael@kernel.org, dakr@kernel.org, bartosz.golaszewski@linaro.org, cw00.choi@samsung.com, myungjoo.ham@samsung.com, yesanishhere@gmail.com, Jonathan.Cameron@huawei.com, quic_zijuhu@quicinc.com, aleksander.lobakin@intel.com, ira.weiny@intel.com, andriy.shevchenko@linux.intel.com, leon@kernel.org, lukas@wunner.de, bhelgaas@google.com, wagi@kernel.org, djeffery@redhat.com, stuart.w.hayes@gmail.com, ptyadav@amazon.de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: B0D838000A X-Rspamd-Server: rspam09 X-Stat-Signature: 36xacndjdzipaf9zu8tm9g7qut7ze5pr X-HE-Tag: 1749400381-218556 X-HE-Meta: U2FsdGVkX18m23c3DsfjZ5q1X5CUnYt1cJPiPK1LPK6I5JSISmKTL1Q9eF5BJ54LOQTria+cIrybZzPm0uPOjFD+Ebeg6VvgYs2IPJ5LCv+R93Az9WdwevpQY8ZhSZ9uMGvEkj+BB8gF/VeLvvqn4MlOYGwSThkJoQXhXXzZmroyjYBplUT+B6l34JCnBhFjoa1blmbBlwm66bojVyhuD76+UP7+IwpniP7iugIzpX+73kUs+YwNPIO9X2rSRRYSOJ20B5T+AMwAXyn1fK9Vev1E8r11IAzxSaT5r/G3TxlWAdQSE39BLptevrBEWMdPRYE2+Y649t+QTwJ/ldMOsLSdUw4zv7LK0xsuzmjNGElXr+PTtXlMM8XZMs1zPkZfz54E8yeKpzdXAsD/a3RkkRevga/bFVVhgGZYUEgY3LErhu5gK6WjoGuB98rsarT8ezndiCEwfI4xvXmbT3K/nHmB84oBbaPSwsrIwWt/KCw2GrB4l+wqSmSHyViU/f0tsR0k9q1N4MEep9mascgm26IpJ8/9Pmoc2zw+QKYbOJmiBUUSwytmC4mQdnhstFghO/Tog4QSeOumt5keqoKaHJzREvaYj6HBcVtpLDELtXeN3Mtdh3TNhU6rRj9xRRSni1oog7IxazNLsfsrbl/jVdm2Sgy1wFVjfpvi+NHf6jKy+5fsJE+9PlR18R9Q0m/Po8gyOv5vAmB4oTghP8mtKqMpiAllkIjVIRyp18QXeheny6Misqfbfp5bYuKuHWyHmw/7Jfr5NwwBTdgmfI+gwwR5Z5Z5+mEnbTBD88cJn7ehxJJXzq+b9tdsza4By7qSQXAPqZoWjIOnLy/TO1ELnii17hRQdOsmQ2ExPJ4F1j8S/XVJyFyXXebHfbTzF13PqMq0WluEGYHNZbel4vWhHXWG+nf56O+k8Rz7FmvL0y5uNfHK0gqRVi5WxzNAsGCgViVPHEn3azN8dUBTANy Pt5yRGHi E+AiYnIvEmoybC8iMH55XkoQTzA/7WLzcNnTCrAdoSSo/wbobMpCP9zq3cvVyAHyvblsjGEwZWZ/ba/vVPs5rgG2AcdbBHTQJVMWSZqfSzBUXggThCOw42DC5SB7W//fiky1hGKZo8vcNd+XzKdivNarSfr7cZDQASVR/JCH6g+ks3bnwPRoI4OB2V0psF50dMk3RLtmhw8JQgGkqOeKjrB933GV9B2BmyD4hDpGTevs8FJf5P3JTo0x9mI/GvtCychWd20WryNMe8AFtZBNNhLKd36ymiZ9AFcMiIZzL+0awqLkMQ0L2DXC8lL0ksA54tmTULZ6rYRK2vpo1dBgQTB8TQTQPAIBivKFjNtZj+eQm9PivCmpSkn82cp+R83JynlqjTBpoyX6Iy0fFqoQjDaGHB8LPCuWOEnsTwz9mtFYSwOn3cQUwYYLUTS0oz0kGYUKtWcIZ31Eq6n7BuF+saYrErcSLO/vO9buL 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: On Wed, May 28, 2025 at 4:29=E2=80=AFPM David Matlack = wrote: > > On Thu, May 15, 2025 at 11:23=E2=80=AFAM Pasha Tatashin > wrote: > > +static int luo_open(struct inode *inodep, struct file *filep) > > +{ > > + if (!capable(CAP_SYS_ADMIN)) > > + return -EACCES; > > It makes sense that LIVEUPDATE_IOCTL_EVENT* would require > CAP_SYS_ADMIN. But I think requiring it for LIVEUPDATE_IOCTL_FD* will > add a lot of complexity. > It would essentially require a central userspace process to mediate > all preserving/restoring of file descriptors across Live Update to > enforce security. If we need a central authority to enforce security, > I don't see why that authority can't just be the kernel or what the > industry gains by punting the problem to userspace. It seems like all > users of LUO are going to want the same security guarantees when it > comes to FDs: a FD preserved inside a given "security domain" should > not be accessible outside that domain. > > One way to do this in the kernel would be to have the kernel hand out > Live Update security tokens (say, some large random number). Then > require userspace to pass in a security token when preserving an FD. > Userspace can then only restore or unpreserve an FD if it passes back > in the security token associated with the FD. Then it's just up to > each userspace process to remember their token across kexec, keep it > secret from other untrusted processes, and pass it back in when > recovering FDs. > > All the kernel has to do is generate secure tokens, which I imagine > can't be that hard. Based on current discussions at the bi-weekly hypervisor live update sync [1], one proposed idea is for LIVEUPDATE_IOCTL_FD_* operations to be managed by a dedicated userspace agent. This agent would be responsible for preserving and restoring file descriptors, subsequently passing them to their respective owners (e.g., VMMs). While the complexity of implementing such a userspace architecture in a cloud environment is unclear to me, introducing kernel-enforced security boundaries around /dev/liveupdate tokens themselves (instead of CAP_SYS_ADMIN for the device node) seems too complex and potentially risky to incorporate at this stage of LUO's development. If finer-grained, token-based security is necessary, it could perhaps be an optional extension to LUO in the future managed by a dedicated CONFIG_*. [1] https://lore.kernel.org/all/958b2ec3-f5f1-b714-1256-1b06dcf7470f@google= .com/