Received: by 2002:a05:7412:37c9:b0:e2:908c:2ebd with SMTP id jz9csp451653rdb; Mon, 18 Sep 2023 23:33:12 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHf4lFm+h50J4Rh7OKlZdozP/hpHC9h1wJBLolbYt+yRYUPuc2cNhqsqGtOY0Vl4W7xGINr X-Received: by 2002:a05:6a21:7894:b0:14c:4deb:3de2 with SMTP id bf20-20020a056a21789400b0014c4deb3de2mr12259461pzc.46.1695105191710; Mon, 18 Sep 2023 23:33:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695105191; cv=none; d=google.com; s=arc-20160816; b=IW+dMBUKcaBS60WXTHmcgF2/zVsdBXfreEivU6cjQqj3I/FkWg6MFdnX7Y7blADnoB lsnyx1+L0fKcdSqz1aA9MtI4atrCcPg2stVrCpWShoC9XRLvnFSExNOmScUBWUidtUkA 6TZBkHbnOWApndt6JNnm2lIScbdguhPDD6bdijJ0U91BLCOI9iBQ7o/z8eQFJNcXUqmL QhFrDMImJmE+zc069dy/JVufn+MaxVbikFKadkGoZGK1eli2mvDfhdlQ7f8zy0UBTS16 DypUnNVr/INKjua5qS3RUdxLai9Ncme2idkHsJqToqdifNnCIYz3Kbn/E0t8OJxeNeoy 3bMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=GbXneqlvqIGCYRFq8SaQCy+9zDbbsrcbESBLAJ+M0h4=; fh=gxK9QP/5ELf7C5/l/kO1rMkj2lvvnJ6j/GWvbiKEzg8=; b=r11Uon6v+Aox5TeZAhWqFc8lzFiITrS7HPg9bMc7/WLo3do8AJDXY6MfGpL4o/BUU7 8YhU6uHD4J0sfhagB5FfiJ12p6oCg08h+/EgfonD935j1ERicL1flFuerqv8k6OKT30c 8uc0c07+zZMxjk6mzBhYCYgf40s/QYdL54PpU8fMsE1HqBLqOkpSdVmGWmYaQLBtehmo sSkJmlCtWxLPQc2hgcgXvjmF3bEamkcEm1mphNNZ1pGHRW+pwwHJKXauW6Zm5o8uKubh DnyJTKiwK3jnP+jAtReIxIdXkHPTTZA0aFUQUG1LwgYZ/vx5jUhpq2BK/UwiZXTUOxD0 /i2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@fooishbar-org.20230601.gappssmtp.com header.s=20230601 header.b=Xqb4aqcH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id ne10-20020a17090b374a00b00262ebe643a2si9044767pjb.186.2023.09.18.23.33.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Sep 2023 23:33:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@fooishbar-org.20230601.gappssmtp.com header.s=20230601 header.b=Xqb4aqcH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 29F9A802174A; Mon, 18 Sep 2023 23:33:09 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231519AbjISGdH (ORCPT + 99 others); Tue, 19 Sep 2023 02:33:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55420 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230017AbjISGdF (ORCPT ); Tue, 19 Sep 2023 02:33:05 -0400 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 95B42116 for ; Mon, 18 Sep 2023 23:32:58 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-9ae22bf33a0so176939866b.0 for ; Mon, 18 Sep 2023 23:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fooishbar-org.20230601.gappssmtp.com; s=20230601; t=1695105177; x=1695709977; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GbXneqlvqIGCYRFq8SaQCy+9zDbbsrcbESBLAJ+M0h4=; b=Xqb4aqcH/mtSprIbTMmuPlGtNpLgLIFKrFe6vR9y1G8EOoniPOKh2czR4P/Er06XCT ToHfJOxlwfLl9cME//Mc2Fkaz31Qyhy48NQaqOXgdz+dqKn4iym2cpF+NJxpTePsbPFd qKEEvBr1yOQl2IMzs+KpeCq9zfo3/nZSKzueTDsnvhs/J1hSdrFHU+bpBHNZikZYqffP JeOTw9sajiHm3dS6uj+aSDRKrrJjyiUa3ke03Q68nfvlv9pNS0zrJCZQV8EN5T0S7EaA qs4KrrnsdW5sJ/M6gTv8LUDzfyJlokOBoT2eBGNAUbMUHWVngDDRjb09JqoDlCsasCCi BY/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695105177; x=1695709977; h=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=GbXneqlvqIGCYRFq8SaQCy+9zDbbsrcbESBLAJ+M0h4=; b=OJLhN8UU+hwkesvOqB2tFqs3/7WMc6P/FH7NaeYeG0l7LKKVuEz0wyXOd1/xmGk8ke 7YHfMIBhFERcVa/IjAa811j5yCEFRswb+P43i6CoMLFXlyTL0OForpAK6WL6sEbzIb9o BTq/lmZWWevVdrAnoJo45SNJeDpm9l8qHaTUyrfURCKQ1otbxwngm26K1qOxABpd8TSc T/H88CIvzwhi1QRVUf6Kqu1Pq9i4ak39rNU8ZTtY/Za6Uu55bFaTvMBuJIytRqk97PKC ygGwbtARy/IetIR2AkzlIOHSlC2napRlVvgtCDtIGKrSGUoCRHsWE9megP4KNYbh4gAL c3Eg== X-Gm-Message-State: AOJu0YwM+X49tqGDuBUb/AjiGX2BZF4zkeFU6kujYc3pqmGeWKgFy70a n9/RyBw1Vvt8/tf7ya7dvs1XNrHt2zKjw46rf0EOEQ== X-Received: by 2002:a17:907:97cb:b0:9aa:f7f:e276 with SMTP id js11-20020a17090797cb00b009aa0f7fe276mr2314608ejc.38.1695105176878; Mon, 18 Sep 2023 23:32:56 -0700 (PDT) MIME-Version: 1.0 References: <20230919030345.8629-1-jason-jh.lin@mediatek.com> In-Reply-To: <20230919030345.8629-1-jason-jh.lin@mediatek.com> From: Daniel Stone Date: Tue, 19 Sep 2023 07:32:44 +0100 Message-ID: Subject: Re: [PATCH 00/10] Add mediate-drm secure flow for SVP To: "Jason-JH.Lin" Cc: Rob Herring , Krzysztof Kozlowski , Matthias Brugger , AngeloGioacchino Del Regno , Chun-Kuang Hu , devicetree@vger.kernel.org, Conor Dooley , Project_Global_Chrome_Upstream_Group@mediatek.com, Singo Chang , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, Jason-ch Chen , Nancy Lin , linux-mediatek@lists.infradead.org, Shawn Sung , Johnson Wang , linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Mon, 18 Sep 2023 23:33:09 -0700 (PDT) Hi Jason, CK, On Tue, 19 Sept 2023 at 04:04, Jason-JH.Lin wrote: > The patch series provides drm driver support for enabling secure video > path (SVP) playback on MediaiTek hardware in the Linux kernel. > > [...] > > Memory Usage in SVP: > The overall flow of SVP starts with encrypted video coming in from an > outside source into the REE. The REE will then allocate a 'secure > buffer' and send the corresponding 'secure handle' along with the > encrypted, compressed video data to the TEE. The TEE will then decrypt > the video and store the result in the 'secure buffer'. The REE will > then allocate a 'secure surface'. The REE will pass the 'secure > handles' for both the 'secure buffer' and 'secure surface' into the > TEE for video decoding. The video decoder HW will then decode the > contents of the 'secure buffer' and place the result in the 'secure > surface'. The REE will then attach the 'secure surface' to the overlay > plane for rendering of the video. > > Everything relating to ensuring security of the actual contents of the > 'secure buffer' and 'secure surface' is out of scope for the REE and > is the responsibility of the TEE. > > DRM driver handles allocation of gem objects that are backed by a 'secure > surface' and for displaying a 'secure surface' on the overlay plane. > This introduces a new flag for object creation called > DRM_MTK_GEM_CREATE_ENCRYPTED which indicates it should be a 'secure > surface'. All changes here are in MediaTek specific code. To be honest, it seems strange that DRM is being used as the allocator for buffers which will mostly be used by codec hardware which is not mentioned here. I can understand that minigbm and gbm_gralloc make this easy to implement, but it's not really right to add this all to mtk-drm just to support some codec features. NXP posted a patchset a while ago to add secure-memory support to dma-heaps[0]. This would be much cleaner (e.g. avoiding strcmp on allocating name, avoiding mtk-drm being a render node when it can't render) I think, and also allow common secure-path semantics between different vendors. Having common secure-path semantics between different vendors would be very helpful, because the first question when we add new uAPI is 'where is the open-source userspace?'. If there is at least a common interface through e.g. dma-heaps, then we could have some standard cross-vendor userspace code which would work well with the standard interface. Cheers, Daniel [0]: https://lore.kernel.org/lkml/20220805135330.970-2-olivier.masse@nxp.com/