pages pinned for BO lifetime and security

[Christian König]

Am 22.07.20 um 09:19 schrieb Christian König:
> Am 22.07.20 um 02:22 schrieb Gurchetan Singh:
>> +Christian who added DMABUF_MOVE_NOTIFY which added the relevant blurb:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/dma-buf/Kconfig#n46 
>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2Fdrivers%2Fdma-buf%2FKconfig%23n46&data=02%7C01%7Cchristian.koenig%40amd.com%7C5a933ce308c94d852d9708d82dd55ba6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637309742143442589&sdata=ynsmCVRnd28gmcvQwd8PMAH3838RzbREu0ZfWUdpPpU%3D&reserved=0>
>>
>> Currently, the user seems to amdgpu for P2P dma-buf and it seems to 
>> plumb ttm (*move_notify) callback to dma-buf.  We're not sure if it's 
>> a security issue occurring across DRM drivers, or one more specific 
>> to the new amdgpu use case.
>>
>> On Tue, Jul 21, 2020 at 1:03 PM Chia-I Wu <olvaffe at gmail.com 
>> <mailto:olvaffe at gmail.com>> wrote:
>>
>>     Hi list,
>>
>>     virtio-gpu is moving in the direction where BO pages are pinned for
>>     the lifetime for simplicity.  I am wondering if that is considered a
>>     security issue in general, especially after running into the
>>     description of the new DMABUF_MOVE_NOTIFY config option.
>>
>
> Yes, that is generally considered a deny of service possibility and so 
> far Dave and Daniel have rejected all tries to upstream stuff like 
> this as far as I know.
>
> DMA-buf an pinning for scanout are the only exceptions since the 
> implementation wouldn't have been possible otherwise.

Or better say for scanout pinning is a hardware requirement. For DMA-buf 
we obviously can have a better approach :)

Christian.

>
>>
>>     Most drivers do not have a shrinker, or whether a BO is purgeable is
>>     entirely controlled by the userspace (madvice).  They can be
>>     categorized as "a security problem where userspace is able to pin
>>     unrestricted amounts of memory".  But those drivers are normally
>>     found
>>     on systems without swap.  I don't think the issue applies.
>>
>
> This is completely independent of the availability of swap or not.
>
> Pinning of pages in large quantities can result in all kind of 
> problems and needs to be prevented even without swap.
>
> Otherwise you can ran into problems even with simple I/O operations 
> for example.
>
>>
>>     Of the desktop GPU drivers, i915's shrinker certainly supports
>>     purging
>>     to swap.  TTM is a bit hard to follow.  I can't really tell if amdgpu
>>     or nouveau supports that.  virtio-gpu is more commonly found on
>>     systems with swaps so I think it should follow the desktop practices?
>>
>
> What we do at least in the amdgpu, radeon, i915 and nouveau is to only 
> allow it for scanout and that in turn is limited by the physical 
> number of CRTCs on the board.
>
>>
>>     Truth is, the emulated virtio-gpu device always supports page moves
>>     with VIRTIO_GPU_CMD_RESOURCE_{ATTACH,DETACH}_BACKING.  It is just
>>     that
>>     the driver does not make use of them.  That makes this less of an
>>     issue because the driver can be fixed anytime (finger crossed
>>     that the
>>     emulator won't have bugs in these untested paths).  This issue
>>     becomes
>>     more urgent because we are considering adding a new HW command[1]
>>     where page moves will be disallowed.  We definitely don't want a HW
>>     command that is inherently insecure, if BO pages pinned for the
>>     lifetime is considered a security issue on desktops.
>>
>
> Yeah, that's probably not such a good idea :)
>
> Regards,
> Christian.
>
>>
>>     [1] VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB
>>     https://gitlab.freedesktop.org/virgl/drm-misc-next/-/blob/virtio-gpu-next/include/uapi/linux/virtio_gpu.h#L396
>>     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fvirgl%2Fdrm-misc-next%2F-%2Fblob%2Fvirtio-gpu-next%2Finclude%2Fuapi%2Flinux%2Fvirtio_gpu.h%23L396&data=02%7C01%7Cchristian.koenig%40amd.com%7C5a933ce308c94d852d9708d82dd55ba6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637309742143452581&sdata=u90WUaJnVMDpc3SzFGHVt9Fjh5laqTr%2BxlFXbLYjp6s%3D&reserved=0>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20200722/5238f611/attachment-0001.htm>