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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 DF306C2BD09 for ; Fri, 28 Jun 2024 13:40:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=UWPWV5xOWPvWRohvXp3jsd5OyLdElhEyWkgsMgthC0s=; b=s97ODfliu5aFCgAorjoUJ0ChlS YLn/3lw8aFug6biYQLR2h5Qny9llVHUpbIHVBvL8U29z8rIEeINSjiQsRVHXel40B03HP9n861dDE ROq7aJql7fI1HsdYc0JZ16MT9ghCyowqc7+OQy7QcdPfbFPha7EXd+9i3r4CKGtnKXBvBdUmKmtWo zQjFpdLpJaxRGdB6Tagq7GWZbO43lz0gWgHAt1KxjR+vMb9m1KvkOn3L4q2TNfFVFmv4uj7h/9w+R cWbPJnoAqS/1NFHAN/NNCdaB0xLY+FAwh1J9RraVANbiS++g7g5QJOiaN4rLbhUC4hsb+0Gt03MTW 9n0F9XXA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sNBqB-0000000Dqil-1Ogo; Fri, 28 Jun 2024 13:40:39 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sNBq0-0000000Dqet-2q9T; Fri, 28 Jun 2024 13:40:30 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id D365F60C3D; Fri, 28 Jun 2024 13:40:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 08C32C116B1; Fri, 28 Jun 2024 13:40:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1719582025; bh=UWPWV5xOWPvWRohvXp3jsd5OyLdElhEyWkgsMgthC0s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qaAwq6zcOXnpgYUwN0NVIO0yqpZ0Zb5n2YZUgJX5BmAQYP2Cluav1xiJq0hZ1F060 swoFvPvWsQ7X032KHtT6ExmTb2egebRNSVrf4Be3qEMXEjjOWdH0RacwDbG/wbJ/IL Lr5X0sHIKotDF4a8APUYV/YhbMEi97yJeuTM4Ndsjf4JMs3/HwJanR6v9/QibvkRsl 44QEsuf0ytcePzl2v7ab0R9CGcp6eTRGf74VnAJH2ag50Yux/d5x/xrGpW/74HHWh3 x7UXvQscwRb5ZzQo/H0341550qV2Cd13sb0hgnEiICw+icYbkcsRrPH5hsfSsGqiQB YLRRLIPVBVGow== Date: Fri, 28 Jun 2024 15:40:22 +0200 From: "mripard@kernel.org" To: Christian =?utf-8?B?S8O2bmln?= Cc: Jason-JH Lin =?utf-8?B?KOael+edv+elpSk=?= , "daniel@ffwll.ch" , "quic_vjitta@quicinc.com" , "angelogioacchino.delregno@collabora.com" , "sumit.semwal@linaro.org" , "conor+dt@kernel.org" , "jkardatzke@google.com" , "krzysztof.kozlowski+dt@linaro.org" , "joakim.bech@linaro.org" , Youlin Pei =?utf-8?B?KOijtOWPi+aelyk=?= , "logang@deltatee.com" , "dri-devel@lists.freedesktop.org" , Kuohong Wang =?utf-8?B?KOeOi+Wci+m0uyk=?= , Jianjiao Zeng =?utf-8?B?KOabvuWBpeWnoyk=?= , "contact@emersion.fr" , "benjamin.gaignard@collabora.com" , "matthias.bgg@gmail.com" , "linux-mediatek@lists.infradead.org" , "linaro-mm-sig@lists.linaro.org" , "willy@infradead.org" , "pavel@ucw.cz" , "akpm@linux-foundation.org" , "Brian.Starkey@arm.com" , "robh+dt@kernel.org" , "linux-media@vger.kernel.org" , "devicetree@vger.kernel.org" , "tjmercier@google.com" , "jstultz@google.com" , "linux-arm-kernel@lists.infradead.org" , "robin.murphy@arm.com" , Yong Wu =?utf-8?B?KOWQtOWLhyk=?= , "linux-kernel@vger.kernel.org" , "ppaalanen@gmail.com" Subject: Re: [PATCH v5 2/9] scatterlist: Add a flag for the restricted memory Message-ID: <20240628-cuddly-brave-squid-e1cb22@houat> References: <1050c44512374031d1349b5dced228d0efc3fbde.camel@mediatek.com> <3104b765-5666-44e4-8788-f1b1b296fe17@amd.com> <98c11bad7f40bcc79ed7a2039ddb3a46f99908f5.camel@mediatek.com> <75dc1136-7751-4772-9fa7-dd9124684cd2@amd.com> <5739abdb-0234-412a-9f25-49219411bbc6@amd.com> <20240627-impetuous-aboriginal-cougar-cdcbbf@houat> <304c9faa-5a9c-4520-a3d8-0818f76dd7c9@amd.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wmmpztlpkqqsn5hy" Content-Disposition: inline In-Reply-To: <304c9faa-5a9c-4520-a3d8-0818f76dd7c9@amd.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240628_064028_858144_DF3064C1 X-CRM114-Status: GOOD ( 34.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --wmmpztlpkqqsn5hy Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 28, 2024 at 01:42:27PM GMT, Christian K=F6nig wrote: > Am 27.06.24 um 16:40 schrieb mripard@kernel.org: > > [SNIP] > > > > > > > > Why can't you get this information from userspace? > > > > > > Same reason amd and i915/xe also pass this around internally in= the > > > > > kernel, it's just that for those gpus the render and kms node are= the > > > > > same > > > > > driver so this is easy. > > > > >=20 > > > The reason I ask is that encryption here looks just like another para= meter > > > for the buffer, e.g. like format, stride, tilling etc.. > > >=20 > > > So instead of this during buffer import: > > >=20 > > > mtk_gem->secure =3D (!strncmp(attach->dmabuf->exp_name, "restricted",= 10)); > > > mtk_gem->dma_addr =3D sg_dma_address(sg->sgl); > > > mtk_gem->size =3D attach->dmabuf->size; > > > mtk_gem->sg =3D sg; > > >=20 > > > You can trivially say during use hey this buffer is encrypted. > > >=20 > > > At least that's my 10 mile high view, maybe I'm missing some extensiv= e key > > > exchange or something like that. > > That doesn't work in all cases, unfortunately. > >=20 > > If you're doing secure video playback, the firmware is typically in > > charge of the frame decryption/decoding, and you'd get dma-buf back that > > aren't accessible by the CPU (or at least, not at the execution level > > Linux runs with). >=20 > Yeah, that's perfectly fine. At least the AMD encryption solution > works exactly like that as well. > > So nobody can map that buffer, and the firmware driver is the one who > > knows that this buffer cannot be accessed by anyone. >=20 > On most hw I know you can actually map that buffer, it's just that the > CPU sees only garbage in it because you don't have the necessary > decryption keys around. So you can always map and access the buffer, but only if you're in the right "context" the content would be correct? I think that part is pretty different than what ARM SoCs are doing, where they would typically prevent any CPU access and fault on access. > > Putting this on the userspace to know would be pretty weird, and > > wouldn't solve the case where the kernel would try to map it. >=20 > But that's exactly how all other implementations work as far as I know. I > mean what do you do if the kernel maps the encrypted buffer? >=20 > On AMD we also block userspace and kernel CPU accesses, but that is only > done to make it easier to find bugs not for correctness. >=20 > And userspace absolutely needs to be aware that a buffer is encrypted, ca= use > otherwise it could potentially try to access it with the CPU. I absolutely agree. I guess our discussion is whether it's something that should be implicit and understood by applications, or if it should be explicit and discoverable. Maxime --wmmpztlpkqqsn5hy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZn69RgAKCRDj7w1vZxhR xW5vAQD0vblFH/q1MbM1OY/GsWrJEN+h1Zy8F/ROqZxXJoSP4wEA7MhRTaakqRAd 6+tOX4+3tzAEZ0WOa+EHzLr+lzLYvQ0= =ivoa -----END PGP SIGNATURE----- --wmmpztlpkqqsn5hy--