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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 35822CD5BB0 for ; Thu, 21 May 2026 09:11:01 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9021F10E107; Thu, 21 May 2026 09:11:00 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.b="S4kVgTtn"; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0D74C10E107 for ; Thu, 21 May 2026 09:10:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779354658; 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; bh=tL4bc9P4R8KGMQCjOMGjzl7XMoB1LctMJh1QnkgN/GQ=; b=S4kVgTtnIErRHNGmxjWLOmPYtcb8xm7rXmRu2RNHs5X9GF/nUNN3gfFgbIRxN8bipqhAqz z1P5SMGS4ZnrULLcYkuE6XjLp8ZkvC4tKjGB5TtH37u4pA4ZAG54Nzbi5pdtN/oMW2ASyA 29S9EwFj7LHqdS9CkG0Up2gRYz+zxbI= 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-395-3wFvOmq4Mn6ew9z9wV80vw-1; Thu, 21 May 2026 05:10:54 -0400 X-MC-Unique: 3wFvOmq4Mn6ew9z9wV80vw-1 X-Mimecast-MFC-AGG-ID: 3wFvOmq4Mn6ew9z9wV80vw_1779354652 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (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 798831956056; Thu, 21 May 2026 09:10:52 +0000 (UTC) Received: from [192.168.1.153] (headnet01.pony-001.prod.iad2.dc.redhat.com [10.2.32.101]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 380DD19560A3; Thu, 21 May 2026 09:10:49 +0000 (UTC) From: Albert Esteve Subject: [PATCH 0/2] dma-buf: add DMA_BUF_IOCTL_DERIVE for reduced-permission aliases Date: Thu, 21 May 2026 11:10:13 +0200 Message-Id: <20260521-dmabuf-limit-access-v1-0-26c01e27365a@redhat.com> MIME-Version: 1.0 X-B4-Tracking: v=1; b=H4sIAAAAAAAC/x3MSQqAMAxA0atI1gY6OOFVxEWtUQNONCqCeHeLy 7f4/wGhwCRQJw8Eulh4WyN0moCf3DoSch8NRplC5UZhv7juHHDmhQ903pMIltYU2ua2yrSDWO6 BBr7/a9O+7wfhdnW9ZQAAAA== X-Change-ID: 20260520-dmabuf-limit-access-73261353841a To: Sumit Semwal , =?utf-8?q?Christian_K=C3=B6nig?= , Benjamin Gaignard , Brian Starkey , John Stultz , "T.J. Mercier" , Shuah Khan Cc: linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Albert Esteve , mripard@kernel.org X-Developer-Signature: v=1; a=ed25519-sha256; t=1779354648; l=3435; i=aesteve@redhat.com; s=20260303; h=from:subject:message-id; bh=LUVEbF2qik6JDxZLdpWxQMrWMt8EdXOnTWHgU/bDF84=; b=1nbNWgdOgax/ZiztigFfGJVUWcZKvRsY/6bLBBCxRH9PBuJ2gSbSAkKc9o7ctC21xFonFEIBn UfK5yxy7NMID+5Z66wciWiUPogDnxCkZe9uRxn+1h/0yrM9AwPOE0eF X-Developer-Key: i=aesteve@redhat.com; a=ed25519; pk=YSFz6sOHd2L45+Fr8DIvHTi6lSIjhLZ5T+rkxspJt1s= X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-MFC-PROC-ID: zqA4nFwUrZ201jsfoIxPsfjZR7arokf08gAIn4qpu5M_1779354652 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" When sharing a dma-buf between components of different trust levels, the allocator may need to hand a consumer a read-only view of a buffer it holds with read-write access. An example is a camera pipeline where the capture component writes frames into a buffer and needs to pass a read-only handle to a downstream processing component that should not be able to modify the data. However, no such mechanism exists today. The access mode of a dma-buf file descriptor is fixed at export time, and the standard POSIX interfaces for duplicating or changing file descriptors (i.e., dup(2), dup3(2), and fcntl(F_SETFL)) cannot alter the read/write access mode of the copy. One natural candidate would be reopening via /proc/self/fd/ with O_RDONLY, which works for regular files. For dma-buf this would fail (that is, if we were to add a new handler for open f_op) with ENXIO because the dmabuf pseudo-filesystem carries SB_NOUSER, which prevents the VFS from opening its files through path-based resolution from userspace. Alternatively, exporting the buffer twice would produce two independent dma_buf instances, which breaks fence synchronization. Therefore we add a new DMA_BUF_IOCTL_DERIVE ioctl, which produces a new file descriptor for an existing dma-buf with a caller-specified subset of the original permissions: ``` struct dma_buf_derive { __u32 flags; __s32 fd; }; struct dma_buf_derive req = { .flags = O_RDONLY | O_CLOEXEC }; ioctl(rw_fd, DMA_BUF_IOCTL_DERIVE, &req); /* req.fd is now a read-only alias of the same buffer */ ``` Permission escalation is rejected with -EACCES. The new fd aliases the same struct dma_buf as the original, same dma_resv, same exporter ops, same underlying memory; so importers attaching to either fd see the same fence timeline and operate on the same object. Access control for which components may receive or pass on restricted descriptors can be layered on top via SELinux file:read and file:write permissions. A shared writable mapping (PROT_WRITE | MAP_SHARED) on the read-only fd is rejected with -EACCES in dma_buf_mmap_internal(). Two small internal adjustments accompany the ioctl: - __dma_buf_list_del() is moved to dma_buf_release() so it fires exactly once on dentry destruction rather than on every file close. - dma_buf_file_release() is updated to call dma_buf_put() only for files that are not the primary dma-buf file. This may not be the best approach, but after considering different options and alternatives (as described above), we decided to raise the discussion upstream. Thus, we welcome any alternative proposal or ideas. The series is structured as: - Patch 1 adds the new ioctl implementation. - Patch 2 adds selftests covering the new ioctl. Signed-off-by: Albert Esteve --- Albert Esteve (2): dma-buf: add DMA_BUF_IOCTL_DERIVE for reduced-permission aliases selftests: dma-buf: add DERIVE ioctl tests drivers/dma-buf/dma-buf.c | 58 ++++++++++- include/uapi/linux/dma-buf.h | 28 +++++ tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 114 ++++++++++++++++++++- 3 files changed, 198 insertions(+), 2 deletions(-) --- base-commit: ab5fce87a778cb780a05984a2ca448f2b41aafbf change-id: 20260520-dmabuf-limit-access-73261353841a Best regards, -- Albert Esteve