[PATCH] dma-buf: Give dma-fence-array distinct lockclasses

[Koenig, Christian]

Am 24.08.19 um 21:12 schrieb Chris Wilson:
> Quoting Koenig, Christian (2019-08-24 20:04:43)
>> Am 24.08.19 um 15:58 schrieb Chris Wilson:
>>> In order to allow dma-fence-array as a generic container for fences, we
>>> need to allow for it to contain other dma-fence-arrays. By giving each
>>> dma-fence-array construction their own lockclass, we allow different
>>> types of dma-fence-array to nest, but still do not allow on class of
>>> dma-fence-array to contain itself (even though they have distinct
>>> locks).
>>>
>>> In practice, this means that each subsystem gets its own dma-fence-array
>>> class and we can freely use dma-fence-arrays as containers within the
>>> dmabuf core without angering lockdep.
>> I've considered this for as well. E.g. to use the dma_fence_array
>> implementation instead of coming up with the dma_fence_chain container.
>>
>> But as it turned out when userspace can control nesting, it is trivial
>> to chain enough dma_fence_arrays together to cause an in kernel stack
>> overflow. Which in turn creates a really nice attack vector.
>>
>> So as long as userspace has control over dma_fence_array nesting this is
>> a clear NAK and actually extremely dangerous.
> You are proposing to use recursive dma_fence_array containers for
> dma_resv...

Hui? Where? I've tried rather hard to avoid that.

That was certainly not intentional,
Christian.

>
>> It actually took me quite a while to get the dma_fence_chain container
>> recursion less to avoid stuff like this.
> Sure, we've been avoiding recursion for years.
> -Chris