Re: [PATCH v3] drm/virtio: Add option to disable KMS support

[Rob Clark <robdclark@gmail.com>]

On Tue, Feb 28, 2023 at 4:34 AM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>
> Hi
>
> Am 27.02.23 um 19:15 schrieb Rob Clark:
> > On Mon, Feb 27, 2023 at 9:57 AM Dmitry Osipenko
> > <dmitry.osipenko@collabora.com> wrote:
> >>
> >> On 2/27/23 20:38, Rob Clark wrote:
> >> ...
> >>> +     if (IS_ENABLED(CONFIG_DRM_VIRTIO_GPU_KMS)) {
> >>> +             /* get display info */
> >>> +             virtio_cread_le(vgdev->vdev, struct virtio_gpu_config,
> >>> +                             num_scanouts, &num_scanouts);
> >>> +             vgdev->num_scanouts = min_t(uint32_t, num_scanouts,
> >>> +                                         VIRTIO_GPU_MAX_SCANOUTS);
> >>> +             if (!vgdev->num_scanouts) {
> >>> +                     /*
> >>> +                      * Having an EDID but no scanouts is non-sensical,
> >>> +                      * but it is permitted to have no scanouts and no
> >>> +                      * EDID (in which case DRIVER_MODESET and
> >>> +                      * DRIVER_ATOMIC are not advertised)
> >>> +                      */
> >>> +                     if (vgdev->has_edid) {
> >>> +                             DRM_ERROR("num_scanouts is zero\n");
> >>> +                             ret = -EINVAL;
> >>> +                             goto err_scanouts;
> >>> +                     }
> >>> +                     dev->driver_features &= ~(DRIVER_MODESET | DRIVER_ATOMIC);
> >>
> >> If it's now configurable by host, why do we need the
> >> CONFIG_DRM_VIRTIO_GPU_KMS?
> >
> > Because a kernel config option makes it more obvious that
> > modeset/atomic ioctls are blocked.  Which makes it more obvious about
> > where any potential security issues apply and where fixes need to get
> > backported to.  The config option is the only thing _I_ want,
> > everything else is just a bonus to help other people's use-cases.
>
> I find this very vague. What's the security thread?

The modeset ioctls are a big potential attack surface area.  Which in
the case of CrOS VM guests serves no legitimate purpose.  (kms is
unused in the guest, instead guest window surfaces are proxied to host
for composition alongside host window surfaces.)

There have been in the past potential security bugs (use-after-free,
etc) found in the kms ioctls.  We should assume that there will be
more in the future.  So it seems like simple common sense to want to
block unused ioctls.

> And if the config option is useful, shouldn't it be DRM-wide? The
> modesetting ioctl calls are shared among all drivers.

Maybe, if there is a use?  The situation of compositing guest windows
in the host seems a bit unique to virtgpu, which is why I went with a
config option specific to virtgpu.

BR,
-R

> Best regards
> Thomas
>
> >
> > BR,
> > -R
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev