From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Jeffrey Kardatzke <jkardatzke@google.com>
Cc: "Yunfei Dong" <yunfei.dong@mediatek.com>,
"Nícolas F . R . A . Prado" <nfraprado@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>,
"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>,
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: Re: [PATCH 11/14] media: medkatek: vcodec: covert secure fd to secure handle
Date: Tue, 19 Sep 2023 19:03:31 -0400 [thread overview]
Message-ID: <1d19be1f21d579b529231882d761554d758db5b4.camel@collabora.com> (raw)
In-Reply-To: <CA+ddPcOFksu6JzXZf0QOFeRDAyX=m0k+t8zwg2DbVmAkweobyg@mail.gmail.com>
Le mardi 19 septembre 2023 à 15:38 -0700, Jeffrey Kardatzke a écrit :
> On Tue, Sep 19, 2023 at 12:43 PM Nicolas Dufresne
> <nicolas.dufresne@collabora.com> wrote:
> >
> > Le lundi 11 septembre 2023 à 20:59 +0800, Yunfei Dong a écrit :
> > > User driver will fill or parse data in optee-os with secure handle,
> > > need to covert secure fd to secure handle in kernel.
> > >
> > > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> > > ---
> > > .../vcodec/decoder/mtk_vcodec_dec_drv.c | 1 +
> > > .../vcodec/decoder/mtk_vcodec_dec_stateless.c | 54 ++++++++++++++++++-
> > > drivers/media/v4l2-core/v4l2-ctrls-defs.c | 5 ++
> > > include/uapi/linux/v4l2-controls.h | 4 ++
> > > 4 files changed, 62 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> > > index 0a89ce452ac3..64e006820f43 100644
> > > --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> > > +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> > > @@ -571,3 +571,4 @@ module_platform_driver(mtk_vcodec_dec_driver);
> > >
> > > MODULE_LICENSE("GPL v2");
> > > MODULE_DESCRIPTION("Mediatek video codec V4L2 decoder driver");
> > > +MODULE_IMPORT_NS(DMA_BUF);
> > > diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> > > index 2ea517883a86..d2b09ce9f1cf 100644
> > > --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> > > +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_stateless.c
> > > @@ -426,6 +426,46 @@ static int mtk_vcodec_get_pic_info(struct mtk_vcodec_dec_ctx *ctx)
> > > return ret;
> > > }
> > >
> > > +static int mtk_dma_contig_get_secure_handle(struct mtk_vcodec_dec_ctx *ctx, int fd)
> > > +{
> > > + int secure_handle = 0;
> > > + struct dma_buf *buf;
> > > + struct dma_buf_attachment *dba;
> > > + struct sg_table *sgt;
> > > + struct device *dev = &ctx->dev->plat_dev->dev;
> > > +
> > > + buf = dma_buf_get(fd);
> > > + if (IS_ERR(buf)) {
> > > + mtk_v4l2_vdec_err(ctx, "dma_buf_get fail fd:%d", fd);
> > > + return 0;
> > > + }
> > > +
> > > + dba = dma_buf_attach(buf, dev);
> > > + if (IS_ERR(dba)) {
> > > + mtk_v4l2_vdec_err(ctx, "dma_buf_attach fail fd:%d", fd);
> > > + goto err_attach;
> > > + }
> > > +
> > > + sgt = dma_buf_map_attachment(dba, DMA_BIDIRECTIONAL);
> > > + if (IS_ERR(sgt)) {
> > > + mtk_v4l2_vdec_err(ctx, "dma_buf_map_attachment fail fd:%d", fd);
> > > + goto err_map;
> > > + }
> > > + secure_handle = sg_dma_address(sgt->sgl);
> >
> > Does it mean if your secure dmabuf is passed to a driver that didn't know it was
> > secure it will pick the handle as a memory address and program the HW with it ?
> > That seems unsafe, the handle should be stored in a dedicated place and mapping
> > should either fail, or provide a dummy buffer.
>
> Since the secure dmabufs don't support any mmap/cpu access to them and
> return -EPERM in those cases; wouldn't that prevent misuse of them in
> other places? (so the mmap operation and CPU access will fail, but
> getting the SG list from the dmabuf succeeds)
My impression is that if userspace can pass this FD to a driver without telling
the driver it is secure memory, the driver may potentially crash trying to use
the handle as an memory address.
In my opinion, sg_dma_address() should return addresses, like its name state. If
you want to get something else, you should find another way to obtain it.
Nicolas
>
> >
> > > +
> > > + dma_buf_unmap_attachment(dba, sgt, DMA_BIDIRECTIONAL);
> > > + dma_buf_detach(buf, dba);
> > > + dma_buf_put(buf);
> > > +
> > > + return secure_handle;
> > > +err_map:
> > > + dma_buf_detach(buf, dba);
> > > +err_attach:
> > > + dma_buf_put(buf);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
> > > {
> > > struct mtk_vcodec_dec_ctx *ctx = ctrl_to_dec_ctx(ctrl);
> > > @@ -436,7 +476,7 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
> > > struct v4l2_ctrl *hdr_ctrl;
> > > const struct mtk_vcodec_dec_pdata *dec_pdata = ctx->dev->vdec_pdata;
> > > const struct mtk_video_fmt *fmt;
> > > - int i = 0, ret = 0;
> > > + int i = 0, ret = 0, sec_fd;
> > >
> > > hdr_ctrl = ctrl;
> > > if (!hdr_ctrl || !hdr_ctrl->p_new.p)
> > > @@ -489,6 +529,12 @@ static int mtk_vdec_s_ctrl(struct v4l2_ctrl *ctrl)
> > > return -EINVAL;
> > > }
> > > break;
> > > + case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:
> > > + sec_fd = ctrl->val;
> > > +
> > > + ctrl->val = mtk_dma_contig_get_secure_handle(ctx, ctrl->val);
> > > + mtk_v4l2_vdec_dbg(3, ctx, "get secure handle: %d => 0x%x", sec_fd, ctrl->val);
> > > + break;
> > > default:
> > > mtk_v4l2_vdec_dbg(3, ctx, "Not supported to set ctrl id: 0x%x\n", hdr_ctrl->id);
> > > return ret;
> > > @@ -525,8 +571,9 @@ static const struct v4l2_ctrl_ops mtk_vcodec_dec_ctrl_ops = {
> > > static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
> > > {
> > > unsigned int i;
> > > + struct v4l2_ctrl *ctrl;
> > >
> > > - v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS);
> > > + v4l2_ctrl_handler_init(&ctx->ctrl_hdl, NUM_CTRLS + 1);
> > > if (ctx->ctrl_hdl.error) {
> > > mtk_v4l2_vdec_err(ctx, "v4l2_ctrl_handler_init failed\n");
> > > return ctx->ctrl_hdl.error;
> > > @@ -543,6 +590,9 @@ static int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_dec_ctx *ctx)
> > > }
> > > }
> > >
> > > + ctrl = v4l2_ctrl_new_std(&ctx->ctrl_hdl, &mtk_vcodec_dec_ctrl_ops,
> > > + V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE, 0, 65535, 1, 0);
> > > +
> > > v4l2_ctrl_handler_setup(&ctx->ctrl_hdl);
> > >
> > > return 0;
> > > diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > index 8696eb1cdd61..d8cf01f76aab 100644
> > > --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> > > @@ -1041,6 +1041,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> > > case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD: return "HEVC Size of Length Field";
> > > case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES: return "Reference Frames for a P-Frame";
> > > case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR: return "Prepend SPS and PPS to IDR";
> > > + case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE: return "MediaTek Decoder get secure handle";
> > >
> > > /* AV1 controls */
> > > case V4L2_CID_MPEG_VIDEO_AV1_PROFILE: return "AV1 Profile";
> > > @@ -1437,6 +1438,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
> > > case V4L2_CID_MPEG_VIDEO_VPX_NUM_REF_FRAMES:
> > > *type = V4L2_CTRL_TYPE_INTEGER_MENU;
> > > break;
> > > + case V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE:
> > > + *type = V4L2_CTRL_TYPE_INTEGER;
> > > + *flags |= V4L2_CTRL_FLAG_WRITE_ONLY;
> > > + break;
> > > case V4L2_CID_USER_CLASS:
> > > case V4L2_CID_CAMERA_CLASS:
> > > case V4L2_CID_CODEC_CLASS:
> > > diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> > > index c3604a0a3e30..7b3694985366 100644
> > > --- a/include/uapi/linux/v4l2-controls.h
> > > +++ b/include/uapi/linux/v4l2-controls.h
> > > @@ -954,6 +954,10 @@ enum v4l2_mpeg_mfc51_video_force_frame_type {
> > > #define V4L2_CID_MPEG_MFC51_VIDEO_H264_ADAPTIVE_RC_STATIC (V4L2_CID_CODEC_MFC51_BASE+53)
> > > #define V4L2_CID_MPEG_MFC51_VIDEO_H264_NUM_REF_PIC_FOR_P (V4L2_CID_CODEC_MFC51_BASE+54)
> > >
> > > +/* MPEG-class control IDs specific to the MediaTek Decoder driver as defined by V4L2 */
> > > +#define V4L2_CID_MPEG_MTK_BASE (V4L2_CTRL_CLASS_CODEC | 0x2000)
> > > +#define V4L2_CID_MPEG_MTK_GET_SECURE_HANDLE (V4L2_CID_MPEG_MTK_BASE+8)
> > > +
> > > /* Camera class control IDs */
> > >
> > > #define V4L2_CID_CAMERA_CLASS_BASE (V4L2_CTRL_CLASS_CAMERA | 0x900)
> >
next prev parent reply other threads:[~2023-09-19 23:03 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-11 12:59 [PATCH 00/14] add driver to support secure video decoder Yunfei Dong
2023-09-11 12:59 ` [PATCH 01/14] media: mediatek: vcodec: add tee client interface to communiate with optee-os Yunfei Dong
2023-09-12 8:04 ` AngeloGioacchino Del Regno
2023-09-11 12:59 ` [PATCH 02/14] media: mediatek: vcodec: allocate tee share memory Yunfei Dong
2023-09-12 8:04 ` AngeloGioacchino Del Regno
2023-09-11 12:59 ` [PATCH 03/14] media: mediatek: vcodec: send share memory data to optee Yunfei Dong
2023-09-12 8:07 ` AngeloGioacchino Del Regno
2023-09-11 12:59 ` [PATCH 04/14] media: mediatek: vcodec: initialize msg and vsi information Yunfei Dong
2023-09-12 8:15 ` AngeloGioacchino Del Regno
2023-09-11 12:59 ` [PATCH 05/14] media: mediatek: vcodec: using encoder's device to alloc/free memory Yunfei Dong
2023-09-11 12:59 ` [PATCH 06/14] media: mediatek: vcodec: add interface to allocate/free secure memory Yunfei Dong
2023-09-11 12:59 ` [PATCH 07/14] media: mediatek: vcodec: using shared memory as vsi address Yunfei Dong
2023-09-11 12:59 ` [PATCH 08/14] media: medkatek: vcodec: support one plane capture buffer Yunfei Dong
2023-09-11 15:44 ` Nicolas Dufresne
2023-09-12 2:08 ` Yunfei Dong (董云飞)
2023-09-12 15:13 ` Nicolas Dufresne
2023-09-11 12:59 ` [PATCH 09/14] media: medkatek: vcodec: re-construct h264 driver to support svp mode Yunfei Dong
2023-09-11 12:59 ` [PATCH 10/14] media: medkatek: vcodec: remove parse nal_info in kernel Yunfei Dong
2023-09-11 12:59 ` [PATCH 11/14] media: medkatek: vcodec: covert secure fd to secure handle Yunfei Dong
2023-09-11 15:47 ` Nicolas Dufresne
2023-09-12 1:55 ` Yunfei Dong (董云飞)
2023-09-12 15:17 ` Nicolas Dufresne
2023-09-19 19:42 ` Nicolas Dufresne
2023-09-19 22:38 ` Jeffrey Kardatzke
2023-09-19 23:03 ` Nicolas Dufresne [this message]
2023-09-19 23:47 ` Jeffrey Kardatzke
2023-09-11 12:59 ` [PATCH 12/14] media: medkatek: vcodec: set secure mode to decoder driver Yunfei Dong
2023-09-11 15:54 ` Nicolas Dufresne
2023-09-12 1:48 ` Yunfei Dong (董云飞)
2023-09-12 15:19 ` Nicolas Dufresne
2023-09-12 9:30 ` Hans Verkuil
2023-09-15 8:25 ` Yunfei Dong (董云飞)
2023-09-15 8:54 ` Hans Verkuil
2023-09-18 9:06 ` Yunfei Dong (董云飞)
2023-09-18 20:57 ` Jeffrey Kardatzke
2023-09-19 8:53 ` Hans Verkuil
2023-09-19 18:51 ` Nicolas Dufresne
2023-09-19 19:49 ` Jeffrey Kardatzke
2023-09-20 7:10 ` Hans Verkuil
2023-09-20 18:13 ` Jeffrey Kardatzke
2023-09-20 18:25 ` Hans Verkuil
2023-09-20 7:20 ` Hans Verkuil
2023-09-20 18:20 ` Jeffrey Kardatzke
2023-09-21 15:46 ` Nicolas Dufresne
2023-09-21 17:58 ` Jeffrey Kardatzke
2023-09-22 3:28 ` Yunfei Dong (董云飞)
2023-09-22 8:44 ` Hans Verkuil
2023-09-22 19:17 ` Jeffrey Kardatzke
2023-09-25 9:00 ` Hans Verkuil
2023-09-25 16:51 ` Jeffrey Kardatzke
2023-09-26 20:59 ` Jeffrey Kardatzke
2023-09-27 7:26 ` Hans Verkuil
2023-09-27 18:30 ` Jeffrey Kardatzke
2023-09-19 19:39 ` Jeffrey Kardatzke
2023-09-18 5:51 ` Yunfei Dong (董云飞)
2023-09-11 12:59 ` [PATCH 13/14] media: medkatek: vcodec: disable wait interrupt for svp mode Yunfei Dong
2023-09-11 12:59 ` [PATCH 14/14] media: medkatek: vcodec: support tee decoder Yunfei Dong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1d19be1f21d579b529231882d761554d758db5b4.camel@collabora.com \
--to=nicolas.dufresne@collabora.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=benjamin.gaignard@collabora.com \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=frkoenig@chromium.org \
--cc=hsinyi@chromium.org \
--cc=hverkuil-cisco@xs4all.nl \
--cc=jkardatzke@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=nfraprado@collabora.com \
--cc=nhebert@chromium.org \
--cc=stevecho@chromium.org \
--cc=wenst@chromium.org \
--cc=yunfei.dong@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).