Message ID | 20231106120423.23364-5-yunfei.dong@mediatek.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:8f47:0:b0:403:3b70:6f57 with SMTP id j7csp2607244vqu; Mon, 6 Nov 2023 04:06:21 -0800 (PST) X-Google-Smtp-Source: AGHT+IEt7gE7cEAKS5TeS5isSz71hD2PWmPiOgspCOiK/8O92SCaksyX2PlFZvOJuqLWUjPAumi0 X-Received: by 2002:a17:902:cec9:b0:1cc:6b55:fd3 with SMTP id d9-20020a170902cec900b001cc6b550fd3mr20328836plg.42.1699272381439; Mon, 06 Nov 2023 04:06:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699272381; cv=none; d=google.com; s=arc-20160816; b=YYE9slPThzRmRuRwNIUfJNGUGFNgjAT40ZZtLeVetHfmUEMjKZ+GfSJXF3E+Ut2mTf kP0/f5Mb2UGCxG1f+HV7RL/9rrzn2Qx74x07z1O3uOl/BVMDui95IwLrQ/gxlxqQxDbV YjOstru8kdIp4Lbu9WXN8+O5dLWid7HjvDQ/+cxY4528Ul5cOeRcPirDYmxeTkcRR5h6 3/fv58kCOtkg8KwgqySApLqJeBUeHBu//pR4QFfR0/j86I3Pf2jUGnb16dxjh20bAH73 AiHUYc4rCAMT2fQfj1pxMOV7dD2NcgUMISAAdqCVIj0vPAsHqhRqLyNmd2lCPvEyzCNR nSZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=urgImsiByBgrXegm6WMvOjpTwwvXom0xQlrJXyilo6s=; fh=8U7QuxU7cADb+Zu8vDAVVKQqqLyxXSbl7CN71zWgSeE=; b=oE7lZIIebQk6WZcHIg/DUFTOEiiX9zcXhC1ic7jHUEg55KeaCHcxU62IxFVD8/O/yk C+Y3/My8tym1XQBZ4dMXZA81xP+h8yUILqXrooshCPVj42/6SHpvP+FrkLCVpfv8ujcJ TPYzRRriJ4EbOKSBxKcfPTv8gw+F7pNUE/rKpcgSy/cJDctvUq4orDo/qYAyyv1SKKGY 7w9IOBgQtAmIS3WYKu+sQg34jJZua1N8dIX4l3V182FdqhCQXyFbo727wythKUcoij2o jHCUyGIAurXUlF+hy9r4CQI0krXRKPextYQSlwJEuMRfvci9edp0b4+qFC9IWAsGmiH+ Tjug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mediatek.com header.s=dk header.b=qKnkrskH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=mediatek.com Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id n18-20020a170902e55200b001c3e98a0d79si8447682plf.401.2023.11.06.04.06.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Nov 2023 04:06:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@mediatek.com header.s=dk header.b=qKnkrskH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=mediatek.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id DDEE08051A34; Mon, 6 Nov 2023 04:05:52 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231650AbjKFMEw (ORCPT <rfc822;jaysivo@gmail.com> + 36 others); Mon, 6 Nov 2023 07:04:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41886 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231522AbjKFMEi (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 6 Nov 2023 07:04:38 -0500 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8175EA; Mon, 6 Nov 2023 04:04:34 -0800 (PST) X-UUID: a4b79ab47c9c11ee8051498923ad61e6-20231106 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Type:Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:CC:To:From; bh=urgImsiByBgrXegm6WMvOjpTwwvXom0xQlrJXyilo6s=; b=qKnkrskHkY+kzMklu//q1b2259OyPitj+miD50DZQlG6D8h8G38SermwJPEjR+cL03dnF+W9n8bTD8PVrcfUDh/jBt6NVc5Zy33m76/N8UOD0+UdEmFslcg6gGJudsjD+4W4PrVk4SIUOubtO3Ze0sbembvpGXwdLkWmSLipc4k=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.33,REQID:93776f81-8e25-4599-bdad-c69615034838,IP:0,U RL:0,TC:0,Content:0,EDM:0,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_Ham,ACTION: release,TS:0 X-CID-META: VersionHash:364b77b,CLOUDID:cb2035fc-4a48-46e2-b946-12f04f20af8c,B ulkID:nil,BulkQuantity:0,Recheck:0,SF:102,TC:nil,Content:0,EDM:-3,IP:nil,U RL:0,File:nil,Bulk:nil,QS:nil,BEC:nil,COL:0,OSI:0,OSA:0,AV:0,LES:1,SPR:NO, DKR:0,DKP:0,BRR:0,BRE:0 X-CID-BVR: 0,NGT X-CID-BAS: 0,NGT,0,_ X-CID-FACTOR: TF_CID_SPAM_SNR X-UUID: a4b79ab47c9c11ee8051498923ad61e6-20231106 Received: from mtkmbs10n2.mediatek.inc [(172.21.101.183)] by mailgw02.mediatek.com (envelope-from <yunfei.dong@mediatek.com>) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 738908743; Mon, 06 Nov 2023 20:04:31 +0800 Received: from mtkmbs11n1.mediatek.inc (172.21.101.185) by mtkmbs13n2.mediatek.inc (172.21.101.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.26; Mon, 6 Nov 2023 20:04:30 +0800 Received: from mhfsdcap04.gcn.mediatek.inc (10.17.3.154) by mtkmbs11n1.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.1118.26 via Frontend Transport; Mon, 6 Nov 2023 20:04:29 +0800 From: Yunfei Dong <yunfei.dong@mediatek.com> To: Jeffrey Kardatzke <jkardatzke@google.com>, "T . J . Mercier" <tjmercier@google.com>, John Stultz <jstultz@google.com>, Yong Wu <yong.wu@mediatek.com>, =?utf-8?q?N=C3=ADcolas_F_=2E_R_=2E_A_=2E_Pr?= =?utf-8?q?ado?= <nfraprado@collabora.com>, Nicolas Dufresne <nicolas.dufresne@collabora.com>, Hans Verkuil <hverkuil-cisco@xs4all.nl>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, Benjamin Gaignard <benjamin.gaignard@collabora.com>, Nathan Hebert <nhebert@chromium.org> CC: Chen-Yu Tsai <wenst@chromium.org>, Hsin-Yi Wang <hsinyi@chromium.org>, Fritz Koenig <frkoenig@chromium.org>, Daniel Vetter <daniel@ffwll.ch>, Steve Cho <stevecho@chromium.org>, Yunfei Dong <yunfei.dong@mediatek.com>, <linux-media@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-mediatek@lists.infradead.org>, <Project_Global_Chrome_Upstream_Group@mediatek.com> Subject: [PATCH v2,04/21] v4l: add documentation for secure memory flag Date: Mon, 6 Nov 2023 20:04:06 +0800 Message-ID: <20231106120423.23364-5-yunfei.dong@mediatek.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20231106120423.23364-1-yunfei.dong@mediatek.com> References: <20231106120423.23364-1-yunfei.dong@mediatek.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-MTK: N X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Mon, 06 Nov 2023 04:05:53 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781816236485524116 X-GMAIL-MSGID: 1781816236485524116 |
Series |
add driver to support secure video decoder
|
|
Commit Message
Yunfei Dong (董云飞)
Nov. 6, 2023, 12:04 p.m. UTC
From: Jeffrey Kardatzke <jkardatzke@google.com> Adds documentation for V4L2_MEMORY_FLAG_SECURE. Signed-off-by: Jeffrey Kardatzke <jkardatzke@google.com> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> --- Documentation/userspace-api/media/v4l/buffer.rst | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
Comments
Hi! > From: Jeffrey Kardatzke <jkardatzke@google.com> > > Adds documentation for V4L2_MEMORY_FLAG_SECURE. > --- a/Documentation/userspace-api/media/v4l/buffer.rst > +++ b/Documentation/userspace-api/media/v4l/buffer.rst > @@ -696,7 +696,7 @@ enum v4l2_memory > > .. _memory-flags: > > -Memory Consistency Flags > +Memory Flags > ------------------------ > > .. raw:: latex > @@ -728,6 +728,12 @@ Memory Consistency Flags > only if the buffer is used for :ref:`memory mapping <mmap>` I/O and the > queue reports the :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS > <V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS>` capability. > + * .. _`V4L2-MEMORY-FLAG-SECURE`: > + > + - ``V4L2_MEMORY_FLAG_SECURE`` > + - 0x00000002 > + - DMA bufs passed into the queue will be validated to ensure they were > + allocated from a secure dma-heap. Could we get some more information somewhere? Why would userspace want to work with "secure" DMA heaps? How exactly are they different from others? What attacks are these secure against? What is goal of all this? DRM? BR, Pavel
Mediatek, What happened to the RFC cover letter that explained more overall for what this is for? That should be included in the 0th patch for each of the series. Pavel, This is for secure video playback where the memory is 'secure' (TrustZone in this case) and is only accessible in the TEE and specific HW blocks. Userspace has FDs that reference the memory, but kernel/userspace can't actually map/access that memory. And yes, this is for supporting DRM (Digital Rights Management) playback. Cheers, Jeff On Sat, Nov 11, 2023 at 11:06 AM Pavel Machek <pavel@ucw.cz> wrote: > > Hi! > > > From: Jeffrey Kardatzke <jkardatzke@google.com> > > > > Adds documentation for V4L2_MEMORY_FLAG_SECURE. > > > --- a/Documentation/userspace-api/media/v4l/buffer.rst > > +++ b/Documentation/userspace-api/media/v4l/buffer.rst > > @@ -696,7 +696,7 @@ enum v4l2_memory > > > > .. _memory-flags: > > > > -Memory Consistency Flags > > +Memory Flags > > ------------------------ > > > > .. raw:: latex > > @@ -728,6 +728,12 @@ Memory Consistency Flags > > only if the buffer is used for :ref:`memory mapping <mmap>` I/O and the > > queue reports the :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS > > <V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS>` capability. > > + * .. _`V4L2-MEMORY-FLAG-SECURE`: > > + > > + - ``V4L2_MEMORY_FLAG_SECURE`` > > + - 0x00000002 > > + - DMA bufs passed into the queue will be validated to ensure they were > > + allocated from a secure dma-heap. > > Could we get some more information somewhere? Why would userspace want > to work with "secure" DMA heaps? How exactly are they different from > others? What attacks are these secure against? What is goal of all > this? DRM? > > BR, > Pavel > -- > People of Russia, stop Putin before his war on Ukraine escalates.
diff --git a/Documentation/userspace-api/media/v4l/buffer.rst b/Documentation/userspace-api/media/v4l/buffer.rst index 52bbee81c080..a5a7d1c72d53 100644 --- a/Documentation/userspace-api/media/v4l/buffer.rst +++ b/Documentation/userspace-api/media/v4l/buffer.rst @@ -696,7 +696,7 @@ enum v4l2_memory .. _memory-flags: -Memory Consistency Flags +Memory Flags ------------------------ .. raw:: latex @@ -728,6 +728,12 @@ Memory Consistency Flags only if the buffer is used for :ref:`memory mapping <mmap>` I/O and the queue reports the :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS <V4L2-BUF-CAP-SUPPORTS-MMAP-CACHE-HINTS>` capability. + * .. _`V4L2-MEMORY-FLAG-SECURE`: + + - ``V4L2_MEMORY_FLAG_SECURE`` + - 0x00000002 + - DMA bufs passed into the queue will be validated to ensure they were + allocated from a secure dma-heap. .. raw:: latex