<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Am 22.07.20 um 09:19 schrieb Christian
      König:<br>
    </div>
    <blockquote type="cite" cite="mid:ed03508d-c87d-681e-4c24-c5c8e26ed72a@amd.com">
      
      <div class="moz-cite-prefix">Am 22.07.20 um 02:22 schrieb
        Gurchetan Singh:<br>
      </div>
      <blockquote type="cite" cite="mid:CAAfnVB=9o=xy13Z1ErgXVhcBf24TLQMGJHnfDKoSMSw2MZdg2A@mail.gmail.com">
        
        <div dir="ltr">+Christian who added DMABUF_MOVE_NOTIFY which
          added the relevant blurb:<br>
          <br>
          <a href="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" originalsrc="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/dma-buf/Kconfig#n46" shash="yyaoe2hSEpCmz9gS2ABf68G75NegfDtXQm3ItoR77iWnl+h6sCCgSSEIGOCBjWjVf1bkpl3AKQ0QPsuk6oUAceH0wPQHlMvOTW1cwcqxeCM0lEMf/jaCXJnobjOdnvoUaKNNqT5gJkLxekf8X6iJf2vdFXXVFCGLwRsmLtVCDuU=" target="_blank" moz-do-not-send="true">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/dma-buf/Kconfig#n46</a><br>
          <br>
          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.<br>
        </div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Tue, Jul 21, 2020 at 1:03
            PM Chia-I Wu <<a href="mailto:olvaffe@gmail.com" target="_blank" moz-do-not-send="true">olvaffe@gmail.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">Hi list,<br>
            <br>
            virtio-gpu is moving in the direction where BO pages are
            pinned for<br>
            the lifetime for simplicity.  I am wondering if that is
            considered a<br>
            security issue in general, especially after running into the<br>
            description of the new DMABUF_MOVE_NOTIFY config option.<br>
          </blockquote>
        </div>
      </blockquote>
      <br>
      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.<br>
      <br>
      DMA-buf an pinning for scanout are the only exceptions since the
      implementation wouldn't have been possible otherwise.<br>
    </blockquote>
    <br>
    Or better say for scanout pinning is a hardware requirement. For
    DMA-buf we obviously can have a better approach :)<br>
    <br>
    Christian.<br>
    <br>
    <blockquote type="cite" cite="mid:ed03508d-c87d-681e-4c24-c5c8e26ed72a@amd.com"> <br>
      <blockquote type="cite" cite="mid:CAAfnVB=9o=xy13Z1ErgXVhcBf24TLQMGJHnfDKoSMSw2MZdg2A@mail.gmail.com">
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex"> <br>
            Most drivers do not have a shrinker, or whether a BO is
            purgeable is<br>
            entirely controlled by the userspace (madvice).  They can be<br>
            categorized as "a security problem where userspace is able
            to pin<br>
            unrestricted amounts of memory".  But those drivers are
            normally found<br>
            on systems without swap.  I don't think the issue applies.<br>
          </blockquote>
        </div>
      </blockquote>
      <br>
      This is completely independent of the availability of swap or not.<br>
      <br>
      Pinning of pages in large quantities can result in all kind of
      problems and needs to be prevented even without swap.<br>
      <br>
      Otherwise you can ran into problems even with simple I/O
      operations for example.<br>
      <br>
      <blockquote type="cite" cite="mid:CAAfnVB=9o=xy13Z1ErgXVhcBf24TLQMGJHnfDKoSMSw2MZdg2A@mail.gmail.com">
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex"> <br>
            Of the desktop GPU drivers, i915's shrinker certainly
            supports purging<br>
            to swap.  TTM is a bit hard to follow.  I can't really tell
            if amdgpu<br>
            or nouveau supports that.  virtio-gpu is more commonly found
            on<br>
            systems with swaps so I think it should follow the desktop
            practices?<br>
          </blockquote>
        </div>
      </blockquote>
      <br>
      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.<br>
      <br>
      <blockquote type="cite" cite="mid:CAAfnVB=9o=xy13Z1ErgXVhcBf24TLQMGJHnfDKoSMSw2MZdg2A@mail.gmail.com">
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex"> <br>
            Truth is, the emulated virtio-gpu device always supports
            page moves<br>
            with VIRTIO_GPU_CMD_RESOURCE_{ATTACH,DETACH}_BACKING.  It is
            just that<br>
            the driver does not make use of them.  That makes this less
            of an<br>
            issue because the driver can be fixed anytime (finger
            crossed that the<br>
            emulator won't have bugs in these untested paths).  This
            issue becomes<br>
            more urgent because we are considering adding a new HW
            command[1]<br>
            where page moves will be disallowed.  We definitely don't
            want a HW<br>
            command that is inherently insecure, if BO pages pinned for
            the<br>
            lifetime is considered a security issue on desktops.<br>
          </blockquote>
        </div>
      </blockquote>
      <br>
      Yeah, that's probably not such a good idea :)<br>
      <br>
      Regards,<br>
      Christian.<br>
      <br>
      <blockquote type="cite" cite="mid:CAAfnVB=9o=xy13Z1ErgXVhcBf24TLQMGJHnfDKoSMSw2MZdg2A@mail.gmail.com">
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex"> <br>
            [1] VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB<br>
            <a href="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" originalsrc="https://gitlab.freedesktop.org/virgl/drm-misc-next/-/blob/virtio-gpu-next/include/uapi/linux/virtio_gpu.h#L396" shash="ulg+yfZNfs/CnDBw+4UbI7ZmvExEa9IOR/hAuciCSBshHcDSj5J9plFAwahuQsLXy+TC9/d3rFFC+iiGAImJLe+trO+Og2B7ldlHV6zvFP0KfQQelCqWKWI/PE9eMpP9j83dVHRUKAsD1IIwWyB57/6rZJVClkOeVbTm7PVXWpw=" rel="noreferrer" target="_blank" moz-do-not-send="true">https://gitlab.freedesktop.org/virgl/drm-misc-next/-/blob/virtio-gpu-next/include/uapi/linux/virtio_gpu.h#L396</a><br>
          </blockquote>
        </div>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>