[RFC PATCH 00/13] SVM (share virtual memory) with HMM in nouveau

Jerome Glisse jglisse at redhat.com
Tue Mar 13 15:56:46 UTC 2018


On Mon, Mar 12, 2018 at 11:14:47PM -0700, John Hubbard wrote:
> On 03/12/2018 10:50 AM, Jerome Glisse wrote:

[...]

> Yes, on NVIDIA GPUs, the Host/FIFO unit is limited to 40-bit addresses, so
> things such as the following need to be below (1 << 40), and also accessible 
> to both CPU (user space) and GPU hardware. 
>     -- command buffers (CPU user space driver fills them, GPU consumes them), 
>     -- semaphores (here, a GPU-centric term, rather than OS-type: these are
>        memory locations that, for example, the GPU hardware might write to, in
>        order to indicate work completion; there are other uses as well), 
>     -- a few other things most likely (this is not a complete list).
> 
> So what I'd tentatively expect that to translate into in the driver stack is, 
> approximately:
> 
>     -- User space driver code mmap's an area below (1 << 40). It's hard to avoid this,
>        given that user space needs access to the area (for filling out command
>        buffers and monitoring semaphores, that sort of thing). Then suballocate
>        from there using mmap's MAP_FIXED or (future-ish) MAP_FIXED_SAFE flags.
> 
>        ...glancing at the other fork of this thread, I think that is exactly what
>        Felix is saying, too. So that's good.
> 
>     -- The user space program sits above the user space driver, and although the
>        program could, in theory, interfere with this mmap'd area, that would be
>        wrong in the same way that mucking around with malloc'd areas (outside of
>        malloc() itself) is wrong. So I don't see any particular need to do much
>        more than the above.

I am worried that rogue program (i am not worried about buggy program
if people shoot themself in the foot they should feel the pain) could
use that to abuse channel to do something harmful. I am not familiar
enough with the hardware to completely rule out such scenario.

I do believe hardware with userspace queue support have the necessary
boundary to keep thing secure as i would assume for those the hardware
engineers had to take security into consideration.

Note that in my patchset the code that monitor the special vma is small
something like 20lines of code that only get call if something happen
to the reserved area. So i believe it is worth having such thing, cost
is low for little extra peace of mind :)

Cheers,
Jérôme


More information about the dri-devel mailing list