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 BBC7DEE49B1 for ; Tue, 22 Aug 2023 19:55:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D488F94002E; Tue, 22 Aug 2023 15:55:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CF88C940007; Tue, 22 Aug 2023 15:55:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BBFCE94002E; Tue, 22 Aug 2023 15:55:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id A8277940007 for ; Tue, 22 Aug 2023 15:55:31 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 75845B1D7E for ; Tue, 22 Aug 2023 19:55:31 +0000 (UTC) X-FDA: 81152795262.06.A95DEC6 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by imf25.hostedemail.com (Postfix) with ESMTP id A3A90A001B for ; Tue, 22 Aug 2023 19:55:29 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=ndufresne-ca.20221208.gappssmtp.com header.s=20221208 header.b=e3zMTcqZ; dmarc=none; spf=none (imf25.hostedemail.com: domain of nicolas@ndufresne.ca has no SPF policy when checking 209.85.160.175) smtp.mailfrom=nicolas@ndufresne.ca ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692734129; 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=1Q9PzSJsZpgiOu1CVR72fJVbG7GMfY5u21uosrtHcwo=; b=guok60UJ360XyHP/zI4xahE4nhN/ROMi1/R4ou47eub4YDSvQkq1wc8SWiYjlvUH2fsqib wXReAmdm44y3lfGH0tijHevynvCwh6+3EVB/q1dnZzr8brYVWtA+a0/JkPz0PhBWsJF04W Vl28kreRjPEPI1plbKgWchkBChPn7y4= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=ndufresne-ca.20221208.gappssmtp.com header.s=20221208 header.b=e3zMTcqZ; dmarc=none; spf=none (imf25.hostedemail.com: domain of nicolas@ndufresne.ca has no SPF policy when checking 209.85.160.175) smtp.mailfrom=nicolas@ndufresne.ca ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692734129; a=rsa-sha256; cv=none; b=f9dZ3SMYtX6ToGE1bl9bVNr/QWvy8OHGGDAHw+NP/cBIw/S4O5BtBa/heOurPlhbkD4WtO cVH6y2wfzI17MmRFS1MysetyruDkFT2L7Nl33SjZsZrI/yWZmanbWnJkWDmyy7uaWajEAU 4XkhgBXAmJb2dhWQt3KxQmU+ViWQAJ8= Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-41090ef118eso19076851cf.1 for ; Tue, 22 Aug 2023 12:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ndufresne-ca.20221208.gappssmtp.com; s=20221208; t=1692734129; x=1693338929; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=1Q9PzSJsZpgiOu1CVR72fJVbG7GMfY5u21uosrtHcwo=; b=e3zMTcqZjXEoGwBVWslC3ZpORwORyOL8dxtzfaTXF0oqIPtpxkjNbFkGpNXZCbEG6V p3l8wskGUPtH5zQuvFZd4rieO5HZAaAumQFvuhWH0dIwYKcQ86kSCVyGCr0XFT08LPPx Hrh/+4VQmxmbCoo0AH+lCdwcW2FXaVSuYhf4JHrSxYSw0cEqa2WqgdzUKn5Re66+AGop JBPDgHVp3djIAPe+8R9TapVgrTkconhjvsKcU+lFzcU9j3914mj1Dq10kAno3MvAcKQe JrFrZ34MWWkV6OShu8/9uWHsOoaCynSGhgZFOMp+y6Cd8gT5+O/7IdZtqX+dS1WD0BBF eBKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692734129; x=1693338929; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=1Q9PzSJsZpgiOu1CVR72fJVbG7GMfY5u21uosrtHcwo=; b=b3GSbLobcEIrz6uXAMqoRl0FyY+210Kh8R/1SX2FFhHtKPdsTJekXzSKNKScdV2yBv LVSOalx0d1l2+kbKwGHdyjWCHmWJFtaJ6FpSexofN/+HP1dBmrJw1ZxMZYfsWa5y9fDL xEm8fY6t4UJK2XpU3UFPytJwj0f0aDyWpb4XQqU2ILZMdevKa/CxeOzmKd+xzCIvWpJY Ub3/gFXs884AN8qLZCQxnkmwST7ctqBexQAdDRw85AKJx8/uUPh1xm0yS5mMKlm2m8Uk Ychckqiq5JThP4R0YcfjVXVS2sK5ODqv7bjGj6X9QXFKIREmy+NwU3WYO5uFjHxfFTqO qGqg== X-Gm-Message-State: AOJu0Yx45+3Qecfv4EDdELeZEpB7txHDyw9mCJH4hT3qUCiJ5WxmADOJ +ddT2JAAB9Uh+IUhSLbVEIaSPg== X-Google-Smtp-Source: AGHT+IEObsx+c/lJX6FbQ9Yn/pe9TNRfUYz1pwlmVs/i9iXFeO8P55SdRnWrfg6NgJo4SUTzH6qpmw== X-Received: by 2002:a05:622a:1907:b0:3e4:e2ce:526f with SMTP id w7-20020a05622a190700b003e4e2ce526fmr15163657qtc.39.1692734128793; Tue, 22 Aug 2023 12:55:28 -0700 (PDT) Received: from nicolas-tpx395.localdomain ([2606:6d00:15:bae9::7a9]) by smtp.gmail.com with ESMTPSA id e19-20020ac86713000000b00407ffb2c24dsm3227005qtp.63.2023.08.22.12.55.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Aug 2023 12:55:28 -0700 (PDT) Message-ID: <9e3c7a11ed1d50c4afdf4f181aae7d4a6a425329.camel@ndufresne.ca> Subject: Re: [RFC]: shmem fd for non-DMA buffer sharing cross drivers From: Nicolas Dufresne To: Hsia-Jun Li , linux-mm@kvack.org Cc: dri-devel@lists.freedesktop.org, Linux Media Mailing List , hughd@google.com, akpm@linux-foundation.org, Simon Ser , Hans Verkuil , Tomasz Figa , daniels@collabora.com, ayaka , linux-kernel@vger.kernel.org Date: Tue, 22 Aug 2023 15:55:27 -0400 In-Reply-To: <029b982f-da62-4fa8-66c4-ab11a515574a@synaptics.com> References: <029b982f-da62-4fa8-66c4-ab11a515574a@synaptics.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: A3A90A001B X-Stat-Signature: pfreapcxao4pe1g1wnp9g7yudyrtfuaf X-HE-Tag: 1692734129-815904 X-HE-Meta: U2FsdGVkX19UYybTHNGzAlyC6a9DKEkOw+UN/PmMHzBTgf+ESaQPDBut6myDo0PrPAZYiWlVvci+BeZ6Om6zLxZFeTmcbdx6+s23EoLz5b8hmvLa3egDNg1m7We9r4rjH05XHOyZe6wZXsMdIKbwiwvHQ0W8lr0jIfoJHevj0iUcV+006t/heVk73CDIp2LEX206THO0ytya8dnsQayVZ4fscGH7ZuWmKASkgl861wUkM5I3zUiL2mStHTgfDrnyZpgUznab2l0OrMUSnFfMk0uLTsAu/s2aI/H+3LgfNxD9SiL4tfhT6J97pOddeWrTVbwi2iPf7gNpBymiHpuB90bIHXXs5tWtiiRXR72o0THUtDyOdRHkIElEn+jXJ8Wk1HZXrrQb9JxDeaFQwM8PTPi4vsZbx8BHJwXb2QUqoqaUkPH65AUTrGToE2awXn9DqNPKupQv4xl55mPeTeUklvbrKhUz22hj2MOQ/RG22Cni7kdLgGCNKqJPZ1hT0UHtAXdhcHDEYUvTsZktr40jh0mNwdfYz/sjxMSeEU28l3+VR0QkN8JQt46jL4uxyUnSP96ZtQu1WMJdtobz7hC9tPcpAey4R03WbR/2ajNzDmIyyBvWZ1AFo8Ucv/JH5KMa1zc+pR6Bdury6aOixl5+Lt/hE92PrXFXwRHFTwdYzb0PSHhan+vWP05lnE/hyQYa3ZKOqa4S5QhB2e+nVf2pWAw3BV7x2BDLFki9B0ODoCNF9Vf2JscXFTWIWeed7QNBq60ETanmAK4EU4hwhY5shbU9DPTymD0w3Y2WaA5DELa5+AAzrkpie+aZ6BReFe057afScE8QLtTDQH4O0TNMweoNT87zNadOdS4oivjMeUZr9PSUjm4lRsfgybj3JAb+8LHdK/vMGmLn5AYfttzdK1+WnzFCRG1jIc/fxnXnNe5ulwK7qEKwIMTqRR1OAmxDgOrlQMn0dzMqX6Wu2xg AkIa+UH/ U1fQiaXeP9mFST2GuCZ+QFPCoUycaYxIH++Y1J/Q5YtJjLUndQdqsnJ+LP2bqdUrLb9HBlLIPu+8ILOhA8EJGyGiH4jUMM/LyPtuMknJDHuiaAKj0z/gPm2KhaqlLpTjalj1xw3Ow7udUJD4fbs16lXepEF3C7DRMk3LFJSOB5fchcJkfIaiOq375jJc7yYNlBSlKa4WY9maRN/j2y7/Li73Xj+2SZFHruHO44fSw/UqVVak/9Vn+6XUUqfLBGcdMWd72N9dNQ1YmaYUuPKgVaUW3PjUNBsF6nCXmVRPmjexX8VnagLPcZ1caKLKI3xFGS0E0Ds/URyne8a9wQ1/XMjZVAEwnbd6R4Ek2QyDYeNb93809lAfdYEuGHu/nhiSYdVnsE92zV2RRZjq9DeRFNNJ974MT3A91NnVOjFYZDFDGwizMaIx2ADhJFondBZXJGaS0yyInLZaUy8mfyaBfAlswjYMfdbf2vMYH X-Bogosity: Ham, tests=bogofilter, spamicity=0.000018, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi, Le mardi 22 ao=C3=BBt 2023 =C3=A0 19:14 +0800, Hsia-Jun Li a =C3=A9crit=C2= =A0: > Hello >=20 > I would like to introduce a usage of SHMEM slimier to DMA-buf, the major= =20 > purpose of that is sharing metadata or just a pure container for cross= =20 > drivers. >=20 > We need to exchange some sort of metadata between drivers, likes dynamic= =20 > HDR data between video4linux2 and DRM. Or the graphics frame buffer is= =20 > too complex to be described with plain plane's DMA-buf fd. > An issue between DRM and V4L2 is that DRM could only support 4 planes=20 > while it is 8 for V4L2. It would be pretty hard for DRM to expend its=20 > interface to support that 4 more planes which would lead to revision of= =20 > many standard likes Vulkan, EGL. >=20 > Also, there is no reason to consume a device's memory for the content=20 > that device can't read it, or wasting an entry of IOMMU for such data. > Usually, such a metadata would be the value should be written to a=20 > hardware's registers, a 4KiB page would be 1024 items of 32 bits register= s. >=20 > Still, I have some problems with SHMEM: > 1. I don't want thhe userspace modify the context of the SHMEM allocated= =20 > by the kernel, is there a way to do so? > 2. Should I create a helper function for installing the SHMEM file as a f= d? Please have a look at memfd and the seal feature, it does cover the reason = why unsealed shared memory require full trust. For controls, the SEAL_WRITE is = even needed, as with appropriate timing, a malicous process can modify the data = in- between validation and allocation, causing possible memory overflow. https://man7.org/linux/man-pages/man2/memfd_create.2.html File sealing In the absence of file sealing, processes that communicate via shared memory must either trust each other, or take measures to deal with the possibility that an untrusted peer may manipulate the shared memory region in problematic ways. For example, an untrusted peer might modify the contents of the shared memory at any time, or shrink the shared memory region. The former possibility leaves the local process vulnerable to time-of-check- to-time-of-use race conditions (typically dealt with by copying data from the shared memory region before checking and using it). The latter possibility leaves the local process vulnerable to SIGBUS signals when an attempt is made to access a now- nonexistent location in the shared memory region. (Dealing with this possibility necessitates the use of a handler for the SIGBUS signal.) Dealing with untrusted peers imposes extra complexity on code that employs shared memory. Memory sealing enables that extra complexity to be eliminated, by allowing a process to operate secure in the knowledge that its peer can't modify the shared memory in an undesired fashion. [...] regards, Nicolas