From: Tomasz Figa <tfiga@chromium.org> To: Gerd Hoffmann <kraxel@redhat.com> Cc: "Dmitry Morozov" <dmitry.morozov@opensynergy.com>, "David Stevens" <stevensd@chromium.org>, virtio-dev@lists.oasis-open.org, "Keiichi Watanabe" <keiichiw@chromium.org>, "Alexandre Courbot" <acourbot@chromium.org>, alexlau@chromium.org, dgreid@chromium.org, "Stéphane Marchesin" <marcheu@chromium.org>, "Pawel Osciak" <posciak@chromium.org>, "Hans Verkuil" <hverkuil@xs4all.nl>, "Linux Media Mailing List" <linux-media@vger.kernel.org>, "Daniel Vetter" <daniel@ffwll.ch> Subject: Re: [virtio-dev] [PATCH] [RFC RESEND] vdec: Add virtio video decode device specification Date: Thu, 17 Oct 2019 17:11:38 +0900 [thread overview] Message-ID: <CAAFQd5ByuyTDqwiBeT7U7cVA8omOPGRRxb2tB8=J-u7WYU-urQ@mail.gmail.com> (raw) In-Reply-To: <20191017071952.s3dq2oxdiy3khp5w@sirius.home.kraxel.org> On Thu, Oct 17, 2019 at 4:19 PM Gerd Hoffmann <kraxel@redhat.com> wrote: > > Hi, > > > That said, Chrome OS would use a similar model, except that we don't > > use ION. We would likely use minigbm backed by virtio-gpu to allocate > > appropriate secure buffers for us and then import them to the V4L2 > > driver. > > What exactly is a "secure buffer"? I guess a gem object where read > access is not allowed, only scanout to display? Who enforces this? > The hardware? Or the kernel driver? In general, it's a buffer which can be accessed only by a specific set of entities. The set depends on the use case and the level of security you want to achieve. In Chrome OS we at least want to make such buffers completely inaccessible for the guest, enforced by the VMM, for example by not installing corresponding memory into the guest address space (and not allowing transfers if the virtio-gpu shadow buffer model is used). Beyond that, the host memory itself could be further protected by some hardware mechanisms or another hypervisor running above the host OS, like in the ARM TrustZone model. That shouldn't matter for a VM guest, though. > > It might make sense for virtio-gpu to know that concept, to allow guests > ask for secure buffers. > > And of course we'll need some way to pass around identifiers for these > (and maybe other) buffers (from virtio-gpu device via guest drivers to > virtio-vdec device). virtio-gpu guest driver could generate a uuid for > that, attach it to the dma-buf and also notify the host so qemu can > maintain a uuid -> buffer lookup table. That could be still a guest physical address. Like on a bare metal system with TrustZone, there could be physical memory that is not accessible to the CPU. Best regards, Tomasz
WARNING: multiple messages have this Message-ID (diff)
From: Tomasz Figa <tfiga@chromium.org> To: Gerd Hoffmann <kraxel@redhat.com> Cc: "Dmitry Morozov" <dmitry.morozov@opensynergy.com>, "David Stevens" <stevensd@chromium.org>, virtio-dev@lists.oasis-open.org, "Keiichi Watanabe" <keiichiw@chromium.org>, "Alexandre Courbot" <acourbot@chromium.org>, alexlau@chromium.org, dgreid@chromium.org, "Stéphane Marchesin" <marcheu@chromium.org>, "Pawel Osciak" <posciak@chromium.org>, "Hans Verkuil" <hverkuil@xs4all.nl>, "Linux Media Mailing List" <linux-media@vger.kernel.org>, "Daniel Vetter" <daniel@ffwll.ch> Subject: Re: [virtio-dev] [PATCH] [RFC RESEND] vdec: Add virtio video decode device specification Date: Thu, 17 Oct 2019 17:11:38 +0900 [thread overview] Message-ID: <CAAFQd5ByuyTDqwiBeT7U7cVA8omOPGRRxb2tB8=J-u7WYU-urQ@mail.gmail.com> (raw) In-Reply-To: <20191017071952.s3dq2oxdiy3khp5w@sirius.home.kraxel.org> On Thu, Oct 17, 2019 at 4:19 PM Gerd Hoffmann <kraxel@redhat.com> wrote: > > Hi, > > > That said, Chrome OS would use a similar model, except that we don't > > use ION. We would likely use minigbm backed by virtio-gpu to allocate > > appropriate secure buffers for us and then import them to the V4L2 > > driver. > > What exactly is a "secure buffer"? I guess a gem object where read > access is not allowed, only scanout to display? Who enforces this? > The hardware? Or the kernel driver? In general, it's a buffer which can be accessed only by a specific set of entities. The set depends on the use case and the level of security you want to achieve. In Chrome OS we at least want to make such buffers completely inaccessible for the guest, enforced by the VMM, for example by not installing corresponding memory into the guest address space (and not allowing transfers if the virtio-gpu shadow buffer model is used). Beyond that, the host memory itself could be further protected by some hardware mechanisms or another hypervisor running above the host OS, like in the ARM TrustZone model. That shouldn't matter for a VM guest, though. > > It might make sense for virtio-gpu to know that concept, to allow guests > ask for secure buffers. > > And of course we'll need some way to pass around identifiers for these > (and maybe other) buffers (from virtio-gpu device via guest drivers to > virtio-vdec device). virtio-gpu guest driver could generate a uuid for > that, attach it to the dma-buf and also notify the host so qemu can > maintain a uuid -> buffer lookup table. That could be still a guest physical address. Like on a bare metal system with TrustZone, there could be physical memory that is not accessible to the CPU. Best regards, Tomasz --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2019-10-17 8:11 UTC|newest] Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-19 9:34 [PATCH] [RFC RESEND] vdec: Add virtio video decode device specification Keiichi Watanabe 2019-09-19 9:34 ` [virtio-dev] " Keiichi Watanabe 2019-09-19 9:52 ` Hans Verkuil 2019-09-19 11:15 ` Keiichi Watanabe 2019-09-19 11:15 ` [virtio-dev] " Keiichi Watanabe 2019-09-19 11:17 ` Keiichi Watanabe 2019-09-19 11:17 ` [virtio-dev] " Keiichi Watanabe 2019-09-23 8:56 ` [virtio-dev] " Gerd Hoffmann 2019-09-23 8:56 ` Gerd Hoffmann 2019-10-05 6:08 ` Tomasz Figa 2019-10-05 6:08 ` Tomasz Figa 2019-10-07 14:00 ` Dmitry Morozov 2019-10-07 14:00 ` Dmitry Morozov 2019-10-07 14:14 ` Tomasz Figa 2019-10-07 14:14 ` Tomasz Figa 2019-10-07 15:09 ` Dmitry Morozov 2019-10-07 15:09 ` Dmitry Morozov 2019-10-09 3:55 ` Tomasz Figa 2019-10-09 3:55 ` Tomasz Figa 2019-10-11 8:53 ` Dmitry Morozov 2019-10-11 8:53 ` Dmitry Morozov 2019-10-14 12:34 ` Gerd Hoffmann 2019-10-14 12:34 ` Gerd Hoffmann 2019-10-14 13:05 ` Dmitry Morozov 2019-10-14 13:05 ` Dmitry Morozov 2019-10-15 7:54 ` Gerd Hoffmann 2019-10-15 7:54 ` Gerd Hoffmann 2019-10-15 14:06 ` Dmitry Morozov 2019-10-15 14:06 ` Dmitry Morozov 2019-10-17 8:06 ` Tomasz Figa 2019-10-17 8:06 ` Tomasz Figa 2019-10-17 6:40 ` Tomasz Figa 2019-10-17 6:40 ` Tomasz Figa 2019-10-17 7:19 ` Gerd Hoffmann 2019-10-17 7:19 ` Gerd Hoffmann 2019-10-17 8:11 ` Tomasz Figa [this message] 2019-10-17 8:11 ` Tomasz Figa 2019-10-17 10:13 ` Gerd Hoffmann 2019-10-17 10:13 ` Gerd Hoffmann 2019-10-29 7:39 ` David Stevens 2019-10-31 7:30 ` Keiichi Watanabe 2019-10-31 7:30 ` Keiichi Watanabe 2019-10-31 9:10 ` David Stevens 2019-10-31 9:10 ` David Stevens 2019-11-07 8:29 ` Keiichi Watanabe 2019-11-07 8:29 ` Keiichi Watanabe 2019-10-14 12:19 ` Gerd Hoffmann 2019-10-14 12:19 ` Gerd Hoffmann 2019-10-17 6:58 ` Tomasz Figa 2019-10-17 6:58 ` Tomasz Figa 2019-10-17 7:44 ` Gerd Hoffmann 2019-10-17 7:44 ` Gerd Hoffmann 2019-10-17 8:23 ` Tomasz Figa 2019-10-17 8:23 ` Tomasz Figa 2019-10-17 10:22 ` Gerd Hoffmann 2019-10-17 10:22 ` Gerd Hoffmann 2019-10-17 15:00 ` Frank Yang 2019-10-17 16:22 ` Frank Yang 2019-10-17 7:06 ` David Stevens
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='CAAFQd5ByuyTDqwiBeT7U7cVA8omOPGRRxb2tB8=J-u7WYU-urQ@mail.gmail.com' \ --to=tfiga@chromium.org \ --cc=acourbot@chromium.org \ --cc=alexlau@chromium.org \ --cc=daniel@ffwll.ch \ --cc=dgreid@chromium.org \ --cc=dmitry.morozov@opensynergy.com \ --cc=hverkuil@xs4all.nl \ --cc=keiichiw@chromium.org \ --cc=kraxel@redhat.com \ --cc=linux-media@vger.kernel.org \ --cc=marcheu@chromium.org \ --cc=posciak@chromium.org \ --cc=stevensd@chromium.org \ --cc=virtio-dev@lists.oasis-open.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.