From: Jason Wang <jasowang@redhat.com> To: Max Gurtovoy <mgurtovoy@nvidia.com> Cc: "Michael S. Tsirkin" <mst@redhat.com>, Yongji Xie <xieyongji@bytedance.com>, Stefan Hajnoczi <stefanha@redhat.com>, virtualization <virtualization@lists.linux-foundation.org>, linux-block@vger.kernel.org, linux-kernel <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v5] virtio-blk: Add validation for block size in config space Date: Tue, 24 Aug 2021 10:47:47 +0800 [thread overview] Message-ID: <CACGkMEuc0C0=te3O6z76BniiuHJgfxHnaAZoX=+PCy4Y7DxRow@mail.gmail.com> (raw) In-Reply-To: <b9636f39-1237-235e-d1fe-8f5c0d422c7d@nvidia.com> On Tue, Aug 24, 2021 at 6:31 AM Max Gurtovoy <mgurtovoy@nvidia.com> wrote: > > > On 8/23/2021 3:13 PM, Michael S. Tsirkin wrote: > > On Mon, Aug 23, 2021 at 01:45:31PM +0300, Max Gurtovoy wrote: > >> It helpful if there is a justification for this. > >> > >> In this case, no such HW device exist and the only device that can cause > >> this trouble today is user space VDUSE device that must be validated by the > >> emulation VDUSE kernel driver. > >> > >> Otherwise, will can create 1000 commit like this in the virtio level (for > >> example for each feature for each virtio device). > > Yea, it's a lot of work but I don't think it's avoidable. > > > >>>>>>> And regardless of userspace device, we still need to fix it for other cases. > >>>>>> which cases ? Do you know that there is a buggy HW we need to workaround ? > >>>>>> > >>>>> No, there isn't now. But this could be a potential attack surface if > >>>>> the host doesn't trust the device. > >>>> If the host doesn't trust a device, why it continues using it ? > >>>> > >>> IIUC this is the case for the encrypted VMs. > >> what do you mean encrypted VM ? > >> > >> And how this small patch causes a VM to be 100% encryption supported ? > >> > >>>> Do you suggest we do these workarounds in all device drivers in the kernel ? > >>>> > >>> Isn't it the driver's job to validate some unreasonable configuration? > >> The check should be in different layer. > >> > >> Virtio blk driver should not cover on some strange VDUSE stuff. > > Yes I'm not convinced VDUSE is a valid use-case. I think that for > > security and robustness it should validate data it gets from userspace > > right there after reading it. > > But I think this is useful for the virtio hardening thing. > > https://lwn.net/Articles/865216/ > > I don't see how this change is assisting confidential computing. > > Confidential computingtalks about encrypting guest memory from the host, > and not adding some quirks to devices. In the case of confidential computing, the hypervisor and hard device is not in the trust zone. It means the guest doesn't trust the cloud vendor. That's why we need to validate any input from them. Thanks > > > > > Yongji - I think the commit log should be much more explicit that > > this is hardening. Otherwise people get confused and think this > > needs a CVE or a backport for security. > > >
WARNING: multiple messages have this Message-ID (diff)
From: Jason Wang <jasowang@redhat.com> To: Max Gurtovoy <mgurtovoy@nvidia.com> Cc: "Michael S. Tsirkin" <mst@redhat.com>, linux-kernel <linux-kernel@vger.kernel.org>, virtualization <virtualization@lists.linux-foundation.org>, linux-block@vger.kernel.org, Yongji Xie <xieyongji@bytedance.com>, Stefan Hajnoczi <stefanha@redhat.com> Subject: Re: [PATCH v5] virtio-blk: Add validation for block size in config space Date: Tue, 24 Aug 2021 10:47:47 +0800 [thread overview] Message-ID: <CACGkMEuc0C0=te3O6z76BniiuHJgfxHnaAZoX=+PCy4Y7DxRow@mail.gmail.com> (raw) In-Reply-To: <b9636f39-1237-235e-d1fe-8f5c0d422c7d@nvidia.com> On Tue, Aug 24, 2021 at 6:31 AM Max Gurtovoy <mgurtovoy@nvidia.com> wrote: > > > On 8/23/2021 3:13 PM, Michael S. Tsirkin wrote: > > On Mon, Aug 23, 2021 at 01:45:31PM +0300, Max Gurtovoy wrote: > >> It helpful if there is a justification for this. > >> > >> In this case, no such HW device exist and the only device that can cause > >> this trouble today is user space VDUSE device that must be validated by the > >> emulation VDUSE kernel driver. > >> > >> Otherwise, will can create 1000 commit like this in the virtio level (for > >> example for each feature for each virtio device). > > Yea, it's a lot of work but I don't think it's avoidable. > > > >>>>>>> And regardless of userspace device, we still need to fix it for other cases. > >>>>>> which cases ? Do you know that there is a buggy HW we need to workaround ? > >>>>>> > >>>>> No, there isn't now. But this could be a potential attack surface if > >>>>> the host doesn't trust the device. > >>>> If the host doesn't trust a device, why it continues using it ? > >>>> > >>> IIUC this is the case for the encrypted VMs. > >> what do you mean encrypted VM ? > >> > >> And how this small patch causes a VM to be 100% encryption supported ? > >> > >>>> Do you suggest we do these workarounds in all device drivers in the kernel ? > >>>> > >>> Isn't it the driver's job to validate some unreasonable configuration? > >> The check should be in different layer. > >> > >> Virtio blk driver should not cover on some strange VDUSE stuff. > > Yes I'm not convinced VDUSE is a valid use-case. I think that for > > security and robustness it should validate data it gets from userspace > > right there after reading it. > > But I think this is useful for the virtio hardening thing. > > https://lwn.net/Articles/865216/ > > I don't see how this change is assisting confidential computing. > > Confidential computingtalks about encrypting guest memory from the host, > and not adding some quirks to devices. In the case of confidential computing, the hypervisor and hard device is not in the trust zone. It means the guest doesn't trust the cloud vendor. That's why we need to validate any input from them. Thanks > > > > > Yongji - I think the commit log should be much more explicit that > > this is hardening. Otherwise people get confused and think this > > needs a CVE or a backport for security. > > > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2021-08-24 2:48 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-09 10:16 [PATCH v5] virtio-blk: Add validation for block size in config space Xie Yongji 2021-08-10 3:05 ` Jason Wang 2021-08-10 3:05 ` Jason Wang 2021-08-10 4:59 ` Yongji Xie 2021-08-10 6:59 ` Jason Wang 2021-08-10 6:59 ` Jason Wang 2021-08-22 23:17 ` Max Gurtovoy 2021-08-23 4:31 ` Yongji Xie 2021-08-23 8:07 ` Max Gurtovoy 2021-08-23 8:35 ` Yongji Xie 2021-08-23 9:04 ` Max Gurtovoy 2021-08-23 9:27 ` Yongji Xie 2021-08-23 9:38 ` Max Gurtovoy 2021-08-23 10:33 ` Yongji Xie 2021-08-23 10:45 ` Max Gurtovoy 2021-08-23 11:41 ` Yongji Xie 2021-08-23 12:13 ` Michael S. Tsirkin 2021-08-23 12:13 ` Michael S. Tsirkin 2021-08-23 12:40 ` Yongji Xie 2021-08-23 16:02 ` Michael S. Tsirkin 2021-08-23 16:02 ` Michael S. Tsirkin 2021-08-23 22:31 ` Max Gurtovoy 2021-08-24 2:47 ` Jason Wang [this message] 2021-08-24 2:47 ` Jason Wang 2021-08-24 10:11 ` Max Gurtovoy 2021-08-24 12:52 ` Yongji Xie 2021-08-24 13:30 ` Max Gurtovoy 2021-08-24 13:38 ` Yongji Xie 2021-08-24 13:48 ` Max Gurtovoy 2021-10-04 15:27 ` Michael S. Tsirkin 2021-10-04 15:27 ` Michael S. Tsirkin 2021-10-04 15:39 ` Michael S. Tsirkin 2021-10-04 15:39 ` Michael S. Tsirkin 2021-10-05 15:52 ` Yongji Xie 2021-10-05 10:42 ` Michael S. Tsirkin 2021-10-05 10:42 ` Michael S. Tsirkin 2021-10-05 15:45 ` Yongji Xie 2021-10-05 18:26 ` Martin K. Petersen 2021-10-05 18:26 ` Martin K. Petersen 2021-10-11 11:40 ` Christoph Hellwig 2021-10-11 11:40 ` Christoph Hellwig 2021-10-13 12:21 ` Michael S. Tsirkin 2021-10-13 12:21 ` Michael S. Tsirkin 2021-10-13 12:34 ` Yongji Xie 2021-10-13 12:51 ` Michael S. Tsirkin 2021-10-13 12:51 ` Michael S. Tsirkin 2021-10-13 12:59 ` Yongji Xie 2021-10-05 15:24 ` Yongji Xie
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='CACGkMEuc0C0=te3O6z76BniiuHJgfxHnaAZoX=+PCy4Y7DxRow@mail.gmail.com' \ --to=jasowang@redhat.com \ --cc=linux-block@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mgurtovoy@nvidia.com \ --cc=mst@redhat.com \ --cc=stefanha@redhat.com \ --cc=virtualization@lists.linux-foundation.org \ --cc=xieyongji@bytedance.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: 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.