linux-kernel - Re: [PATCH drm-misc-next 3/3] drm/vc4: crtc: protect device resources after removal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220819072930.fg56dkzbdu6f7s25@houat>
Date:   Fri, 19 Aug 2022 09:29:30 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     Danilo Krummrich <dakr@...hat.com>
Cc:     daniel@...ll.ch, airlied@...ux.ie, tzimmermann@...e.de,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH drm-misc-next 3/3] drm/vc4: crtc: protect device
 resources after removal

Hi,

On Fri, Aug 19, 2022 at 02:29:05AM +0200, Danilo Krummrich wrote:
> (Hardware) resources which are bound to the driver and device lifecycle
> must not be accessed after the device and driver are unbound.
> 
> However, the DRM device isn't freed as long as the last user closed it,
> hence userspace can still call into the driver.
> 
> Therefore protect the critical sections which are accessing those
> resources with drm_dev_enter() and drm_dev_exit().
> 
> Fixes: 7cc4214c27cf ("drm/vc4: crtc: Switch to drmm_kzalloc")
> Signed-off-by: Danilo Krummrich <dakr@...hat.com>
> ---
>  drivers/gpu/drm/vc4/vc4_crtc.c | 41 +++++++++++++++++++++++++++++++++-
>  1 file changed, 40 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 2def6e2ad6f0..51daf190196e 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -39,6 +39,7 @@
>  #include <drm/drm_atomic_uapi.h>
>  #include <drm/drm_fb_dma_helper.h>
>  #include <drm/drm_framebuffer.h>
> +#include <drm/drm_drv.h>
>  #include <drm/drm_print.h>
>  #include <drm/drm_probe_helper.h>
>  #include <drm/drm_vblank.h>
> @@ -295,10 +296,17 @@ struct drm_encoder *vc4_get_crtc_encoder(struct drm_crtc *crtc,
>  static void vc4_crtc_pixelvalve_reset(struct drm_crtc *crtc)
>  {
>  	struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> +	struct drm_device *dev = crtc->dev;
> +	int idx;
> +
> +	if (!drm_dev_enter(dev, &idx))
> +		return;
>  
>  	/* The PV needs to be disabled before it can be flushed */
>  	CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) & ~PV_CONTROL_EN);
>  	CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_FIFO_CLR);
> +
> +	drm_dev_exit(idx);
>  }
>  
>  static void vc4_crtc_config_pv(struct drm_crtc *crtc, struct drm_encoder *encoder,
> @@ -321,6 +329,10 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc, struct drm_encoder *encode
>  	u32 format = is_dsi1 ? PV_CONTROL_FORMAT_DSIV_24 : PV_CONTROL_FORMAT_24;
>  	u8 ppc = pv_data->pixels_per_clock;
>  	bool debug_dump_regs = false;
> +	int idx;
> +
> +	if (!drm_dev_enter(dev, &idx))
> +		return;
>  
>  	if (debug_dump_regs) {
>  		struct drm_printer p = drm_info_printer(&vc4_crtc->pdev->dev);
> @@ -410,6 +422,8 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc, struct drm_encoder *encode
>  			 drm_crtc_index(crtc));
>  		drm_print_regset32(&p, &vc4_crtc->regset);
>  	}
> +
> +	drm_dev_exit(idx);
>  }
>  
>  static void require_hvs_enabled(struct drm_device *dev)
> @@ -430,13 +444,18 @@ static int vc4_crtc_disable(struct drm_crtc *crtc,
>  	struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
>  	struct drm_device *dev = crtc->dev;
>  	struct vc4_dev *vc4 = to_vc4_dev(dev);
> -	int ret;
> +	int idx, ret;
> +
> +	if (!drm_dev_enter(dev, &idx))
> +		return -ENODEV;
>  
>  	CRTC_WRITE(PV_V_CONTROL,
>  		   CRTC_READ(PV_V_CONTROL) & ~PV_VCONTROL_VIDEN);
>  	ret = wait_for(!(CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN), 1);
>  	WARN_ONCE(ret, "Timeout waiting for !PV_VCONTROL_VIDEN\n");
>  
> +	drm_dev_exit(idx);
> +

I think this would be easier to follow if we were protecting the entire
function with our lock.

Having locks taken in the middle of the function is harder to identify
whether or not one particular function is safe or not.

The same applies to the plane patch

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)