dri-devel June 2021

dri-devel@lists.freedesktop.org

341 participants
878 discussions

[PATCH v9 00/14] Restricted DMA
by Claire Chang 15 Jun '21

15 Jun '21

This series implements mitigations for lack of DMA access control on systems without an IOMMU, which could result in the DMA accessing the system memory at unexpected times and/or unexpected addresses, possibly leading to data leakage or corruption. For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is not behind an IOMMU. As PCI-e, by design, gives the device full access to system memory, a vulnerability in the Wi-Fi firmware could easily escalate to a full system exploit (remote wifi exploits: [1a], [1b] that shows a full chain of exploits; [2], [3]). To mitigate the security concerns, we introduce restricted DMA. Restricted DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a specially allocated region and does memory allocation from the same region. The feature on its own provides a basic level of protection against the DMA overwriting buffer contents at unexpected times. However, to protect against general data leakage and system memory corruption, the system needs to provide a way to restrict the DMA to a predefined memory region (this is usually done at firmware level, e.g. MPU in ATF on some ARM platforms [4]). [1a] https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcom… [1b] https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcom… [2] https://blade.tencent.com/en/advisories/qualpwn/ [3] https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-hig… [4] https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/media… v9: Address the comments in v7 to - set swiotlb active pool to dev->dma_io_tlb_mem - get rid of get_io_tlb_mem - dig out the device struct for is_swiotlb_active - move debugfs_create_dir out of swiotlb_create_debugfs - do set_memory_decrypted conditionally in swiotlb_init_io_tlb_mem - use IS_ENABLED in kernel/dma/direct.c - fix redefinition of 'of_dma_set_restricted_buffer' v8: - Fix reserved-memory.txt and add the reg property in example. - Fix sizeof for of_property_count_elems_of_size in drivers/of/address.c#of_dma_set_restricted_buffer. - Apply Will's suggestion to try the OF node having DMA configuration in drivers/of/address.c#of_dma_set_restricted_buffer. - Fix typo in the comment of drivers/of/address.c#of_dma_set_restricted_buffer. - Add error message for PageHighMem in kernel/dma/swiotlb.c#rmem_swiotlb_device_init and move it to rmem_swiotlb_setup. - Fix the message string in rmem_swiotlb_setup. https://lore.kernel.org/patchwork/cover/1437112/ v7: Fix debugfs, PageHighMem and comment style in rmem_swiotlb_device_init https://lore.kernel.org/patchwork/cover/1431031/ v6: Address the comments in v5 https://lore.kernel.org/patchwork/cover/1423201/ v5: Rebase on latest linux-next https://lore.kernel.org/patchwork/cover/1416899/ v4: - Fix spinlock bad magic - Use rmem->name for debugfs entry - Address the comments in v3 https://lore.kernel.org/patchwork/cover/1378113/ v3: Using only one reserved memory region for both streaming DMA and memory allocation. https://lore.kernel.org/patchwork/cover/1360992/ v2: Building on top of swiotlb. https://lore.kernel.org/patchwork/cover/1280705/ v1: Using dma_map_ops. https://lore.kernel.org/patchwork/cover/1271660/ Claire Chang (14): swiotlb: Refactor swiotlb init functions swiotlb: Refactor swiotlb_create_debugfs swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used swiotlb: Add restricted DMA pool initialization swiotlb: Update is_swiotlb_buffer to add a struct device argument swiotlb: Update is_swiotlb_active to add a struct device argument swiotlb: Bounce data from/to restricted DMA pool if available swiotlb: Move alloc_size to find_slots swiotlb: Refactor swiotlb_tbl_unmap_single dma-direct: Add a new wrapper __dma_direct_free_pages() swiotlb: Add restricted DMA alloc/free support. dma-direct: Allocate memory from restricted DMA pool if available dt-bindings: of: Add restricted DMA pool of: Add plumbing for restricted DMA pool .../reserved-memory/reserved-memory.txt | 36 ++- drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +- drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +- drivers/iommu/dma-iommu.c | 12 +- drivers/of/address.c | 33 +++ drivers/of/device.c | 6 + drivers/of/of_private.h | 6 + drivers/pci/xen-pcifront.c | 2 +- drivers/xen/swiotlb-xen.c | 2 +- include/linux/device.h | 4 + include/linux/swiotlb.h | 45 +++- kernel/dma/Kconfig | 14 + kernel/dma/direct.c | 62 +++-- kernel/dma/direct.h | 9 +- kernel/dma/swiotlb.c | 242 +++++++++++++----- 15 files changed, 376 insertions(+), 101 deletions(-) -- 2.32.0.272.g935e593368-goog

1 17

[PATCH] drm/nouveau: fix double free in nouveau_gem_new()
by Dan Carpenter 15 Jun '21

15 Jun '21

The ttm_bo_init_reserved() function calls ttm_bo_put(bo) which calls nouveau_bo_del_ttm() which frees the "nvbo.bo" so the nouveau_bo_ref() call leads to a double free. Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- This fix is obvious enough and fixes my double free, but unfortunately there are other bugs here so my system still hangs when I try to open ten latest version Firefox windows in a row. drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index c88cbb85f101..d612c1a720f8 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -211,10 +211,8 @@ nouveau_gem_new(struct nouveau_cli *cli, u64 size, int align, uint32_t domain, } ret = nouveau_bo_init(nvbo, size, align, domain, NULL, NULL); - if (ret) { - nouveau_bo_ref(NULL, &nvbo); + if (ret) return ret; - } /* we restrict allowed domains on nv50+ to only the types * that were requested at creation time. not possibly on -- 2.30.2

1 0

[PATCH] drm/i915/ttm: Fix memory leaks
by Thomas Hellström 15 Jun '21

15 Jun '21

Fix two memory leaks introduced with the ttm backend. Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend") Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> --- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c index 08b72c280cb5..8059cb61bc3c 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c @@ -122,6 +122,7 @@ static void i915_ttm_tt_destroy(struct ttm_device *bdev, struct ttm_tt *ttm) struct i915_ttm_tt *i915_tt = container_of(ttm, typeof(*i915_tt), ttm); ttm_tt_destroy_common(bdev, ttm); + ttm_tt_fini(ttm); kfree(i915_tt); } @@ -217,6 +218,7 @@ static void i915_ttm_delete_mem_notify(struct ttm_buffer_object *bo) if (likely(obj)) { /* This releases all gem object bindings to the backend. */ + i915_ttm_free_cached_io_st(obj); __i915_gem_free_object(obj); } } -- 2.31.1

2 1

[PATCH 1/2] drm/gud: Free buffers on device removal
by Noralf Trønnes 15 Jun '21

15 Jun '21

Free transfer and compression buffers on device removal instead of at DRM device removal time. This ensures that the usual 2x8MB buffers are released when the device is unplugged and not kept around should userspace keep the DRM device fd open. At least Ubuntu 20.04 doesn't release the DRM device on unplug. Signed-off-by: Noralf Trønnes <noralf(a)tronnes.org> --- drivers/gpu/drm/gud/gud_drv.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c index e8b672dc9832..820c7331b3b3 100644 --- a/drivers/gpu/drm/gud/gud_drv.c +++ b/drivers/gpu/drm/gud/gud_drv.c @@ -394,12 +394,14 @@ static const struct drm_driver gud_drm_driver = { .minor = 0, }; -static void gud_free_buffers_and_mutex(struct drm_device *drm, void *unused) +static void gud_free_buffers_and_mutex(void *data) { - struct gud_device *gdrm = to_gud_device(drm); + struct gud_device *gdrm = data; vfree(gdrm->compress_buf); + gdrm->compress_buf = NULL; kfree(gdrm->bulk_buf); + gdrm->bulk_buf = NULL; mutex_destroy(&gdrm->ctrl_lock); mutex_destroy(&gdrm->damage_lock); } @@ -455,7 +457,7 @@ static int gud_probe(struct usb_interface *intf, const struct usb_device_id *id) INIT_WORK(&gdrm->work, gud_flush_work); gud_clear_damage(gdrm); - ret = drmm_add_action_or_reset(drm, gud_free_buffers_and_mutex, NULL); + ret = devm_add_action(dev, gud_free_buffers_and_mutex, gdrm); if (ret) return ret; -- 2.23.0

3 6

Re: [PATCH 07/10] vfio/mdev: Allow the mdev_parent_ops to specify the device driver to bind
by Cornelia Huck 15 Jun '21

15 Jun '21

On Mon, Jun 14 2021, Christoph Hellwig <hch(a)lst.de> wrote: > From: Jason Gunthorpe <jgg(a)nvidia.com> > > This allows a mdev driver to opt out of using vfio_mdev.c, instead the > driver will provide a 'struct mdev_driver' and register directly with the > driver core. > > Much of mdev_parent_ops becomes unused in this mode: > - create()/remove() are done via the mdev_driver probe()/remove() > - mdev_attr_groups becomes mdev_driver driver.dev_groups > - Wrapper function callbacks are replaced with the same ones from > struct vfio_device_ops > > Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> > Signed-off-by: Christoph Hellwig <hch(a)lst.de> > --- > drivers/vfio/mdev/mdev_core.c | 30 ++++++++++++++++++++++-------- > drivers/vfio/mdev/mdev_driver.c | 10 ++++++++++ > include/linux/mdev.h | 2 ++ > 3 files changed, 34 insertions(+), 8 deletions(-) Reviewed-by: Cornelia Huck <cohuck(a)redhat.com>

1 0

Re: [PATCH 06/10] vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICE
by Cornelia Huck 15 Jun '21

15 Jun '21

On Mon, Jun 14 2021, Christoph Hellwig <hch(a)lst.de> wrote: > From: Jason Gunthorpe <jgg(a)nvidia.com> > > For some reason the vfio_mdev shim mdev_driver has its own module and > kconfig. As the next patch requires access to it from mdev.ko merge the > two modules together and remove VFIO_MDEV_DEVICE. > > A later patch deletes this driver entirely. > > Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> > Signed-off-by: Christoph Hellwig <hch(a)lst.de> > --- > Documentation/s390/vfio-ap.rst | 1 - > arch/s390/Kconfig | 2 +- > drivers/gpu/drm/i915/Kconfig | 2 +- > drivers/vfio/mdev/Kconfig | 7 ------- > drivers/vfio/mdev/Makefile | 3 +-- > drivers/vfio/mdev/mdev_core.c | 16 ++++++++++++++-- > drivers/vfio/mdev/mdev_private.h | 2 ++ > drivers/vfio/mdev/vfio_mdev.c | 24 +----------------------- > samples/Kconfig | 6 +++--- > 9 files changed, 23 insertions(+), 40 deletions(-) Reviewed-by: Cornelia Huck <cohuck(a)redhat.com>

1 0

Re: [PATCH 05/10] driver core: Export device_driver_attach()
by Cornelia Huck 15 Jun '21

15 Jun '21

On Mon, Jun 14 2021, Christoph Hellwig <hch(a)lst.de> wrote: > From: Jason Gunthorpe <jgg(a)nvidia.com> > > This is intended as a replacement API for device_bind_driver(). It has at > least the following benefits: > > - Internal locking. Few of the users of device_bind_driver() follow the > locking rules > > - Calls device driver probe() internally. Notably this means that devm > support for probe works correctly as probe() error will call > devres_release_all() > > - struct device_driver -> dev_groups is supported > > - Simplified calling convention, no need to manually call probe(). > > The general usage is for situations that already know what driver to bind > and need to ensure the bind is synchronized with other logic. Call > device_driver_attach() after device_add(). > > If probe() returns a failure then this will be preserved up through to the > error return of device_driver_attach(). > > Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> > Signed-off-by: Christoph Hellwig <hch(a)lst.de> > --- > drivers/base/base.h | 1 - > drivers/base/dd.c | 3 +++ > include/linux/device.h | 2 ++ > 3 files changed, 5 insertions(+), 1 deletion(-) Reviewed-by: Cornelia Huck <cohuck(a)redhat.com>

1 0

Re: [PATCH 03/10] driver core: Flow the return code from ->probe() through to sysfs bind
by Cornelia Huck 15 Jun '21

15 Jun '21

On Mon, Jun 14 2021, Christoph Hellwig <hch(a)lst.de> wrote: > Currently really_probe() returns 1 on success and 0 if the probe() call > fails. This return code arrangement is designed to be useful for > __device_attach_driver() which is walking the device list and trying every > driver. 0 means to keep trying. > > However, it is not useful for the other places that call through to > really_probe() that do actually want to see the probe() return code. > > For instance bind_store() would be better to return the actual error code > from the driver's probe method, not discarding it and returning -ENODEV. > > Reorganize things so that really_probe() returns the error code from > ->probe as a (inverted) positive number, and 0 for successful attach. > > With this, __device_attach_driver can ignore the (positive) probe errors, > return 1 to exit the loop for a successful binding and pass on the > other negative errors, while device_driver_attach simplify inverts the > positive errors and returns all errors to the sysfs code. > > Signed-off-by: Christoph Hellwig <hch(a)lst.de> > --- > drivers/base/bus.c | 6 +----- > drivers/base/dd.c | 29 ++++++++++++++++++++--------- > 2 files changed, 21 insertions(+), 14 deletions(-) Reviewed-by: Cornelia Huck <cohuck(a)redhat.com>

1 0

Re: [PATCH 01/10] driver core: Pull required checks into driver_probe_device()
by Cornelia Huck 15 Jun '21

15 Jun '21

On Mon, Jun 14 2021, Christoph Hellwig <hch(a)lst.de> wrote: > From: Jason Gunthorpe <jgg(a)nvidia.com> > > Checking if the dev is dead or if the dev is already bound is a required > precondition to invoking driver_probe_device(). All the call chains > leading here duplicate these checks. > > Add it directly to driver_probe_device() so the precondition is clear and > remove the checks from device_driver_attach() and > __driver_attach_async_helper(). > > The other call chain going through __device_attach_driver() does have > these same checks but they are inlined into logic higher up the call stack > and can't be removed. > > The sysfs uAPI call chain starting at bind_store() is a bit confused > because it reads dev->driver unlocked and returns -ENODEV if it is !NULL, > otherwise it reads it again under lock and returns 0 if it is !NULL. Fix > this to always return -EBUSY and always read dev->driver under its lock. > > Done in preparation for the next patches which will add additional > callers to driver_probe_device() and will need these checks as well. > > Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> > [hch: drop the extra checks in device_driver_attach and bind_store] > Signed-off-by: Christoph Hellwig <hch(a)lst.de> > --- > drivers/base/bus.c | 2 +- > drivers/base/dd.c | 32 ++++++++++---------------------- > 2 files changed, 11 insertions(+), 23 deletions(-) Reviewed-by: Cornelia Huck <cohuck(a)redhat.com>

1 0

[PATCH -next] drm/hyperv: Remove unused variable
by Pu Lehui 15 Jun '21

15 Jun '21

Fixes gcc '-Wunused-const-variable' warning: drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:152:23: warning: 'hyperv_modifiers' defined but not used [-Wunused-const-variable=] Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c b/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c index 02718e3e859e..3f83493909e6 100644 --- a/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c +++ b/drivers/gpu/drm/hyperv/hyperv_drm_modeset.c @@ -149,11 +149,6 @@ static const uint32_t hyperv_formats[] = { DRM_FORMAT_XRGB8888, }; -static const uint64_t hyperv_modifiers[] = { - DRM_FORMAT_MOD_LINEAR, - DRM_FORMAT_MOD_INVALID -}; - static inline int hyperv_pipe_init(struct hyperv_drm_device *hv) { int ret; -- 2.17.1

3 6

← Newer
1
...
48
49
50
51
52
53
54
...
88
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2021