Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 13 May 2021 17:27:46 +0100
From:   Stefan Hajnoczi <stefanha@redhat.com>
To:     Jason Wang <jasowang@redhat.com>
Cc:     mst@redhat.com, virtualization@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org, xieyongji@bytedance.com,
        file@sect.tu-berlin.de, ashish.kalra@amd.com,
        konrad.wilk@oracle.com, kvm@vger.kernel.org, hch@infradead.org
Subject: Re: [RFC PATCH V2 0/7] Do not read from descripto ring
Message-ID: <YJ1TgoFSwOkQrC+1@stefanha-x1.localdomain>
References: <20210423080942.2997-1-jasowang@redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="kSjLBUWR7rqI1Fnp"
Content-Disposition: inline
In-Reply-To: <20210423080942.2997-1-jasowang@redhat.com>
Precedence: bulk


--kSjLBUWR7rqI1Fnp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Fri, Apr 23, 2021 at 04:09:35PM +0800, Jason Wang wrote:
> Sometimes, the driver doesn't trust the device. This is usually
> happens for the encrtpyed VM or VDUSE[1].

Thanks for doing this.

Can you describe the overall memory safety model that virtio drivers
must follow? For example:

- Driver-to-device buffers must be on dedicated pages to avoid
  information leaks.

- Driver-to-device buffers must be on dedicated pages to avoid memory
  corruption.

When I say "pages" I guess it's the IOMMU page size that matters?

What is the memory access granularity of VDUSE?

I'm asking these questions because there is driver code that exposes
kernel memory to the device and I'm not sure it's safe. For example:

  static int virtblk_add_req(struct virtqueue *vq, struct virtblk_req *vbr,
                  struct scatterlist *data_sg, bool have_data)
  {
          struct scatterlist hdr, status, *sgs[3];
          unsigned int num_out = 0, num_in = 0;

          sg_init_one(&hdr, &vbr->out_hdr, sizeof(vbr->out_hdr));
	                    ^^^^^^^^^^^^^
          sgs[num_out++] = &hdr;

          if (have_data) {
                  if (vbr->out_hdr.type & cpu_to_virtio32(vq->vdev, VIRTIO_BLK_T_OUT))
                          sgs[num_out++] = data_sg;
                  else
                          sgs[num_out + num_in++] = data_sg;
          }

          sg_init_one(&status, &vbr->status, sizeof(vbr->status));
                               ^^^^^^^^^^^^
          sgs[num_out + num_in++] = &status;

          return virtqueue_add_sgs(vq, sgs, num_out, num_in, vbr, GFP_ATOMIC);
  }

I guess the drivers don't need to be modified as long as swiotlb is used
to bounce the buffers through "insecure" memory so that the memory
surrounding the buffers is not exposed?

Stefan

--kSjLBUWR7rqI1Fnp
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmCdU4EACgkQnKSrs4Gr
c8jIXQf/bDxDNATkynJc8tGJ7x7Bp5ZiiG3XuUvb5LEsvtzjs+2kmYIZyhESbHN6
pasUhocXLHhIiBmRf5XAHiSbQI+cdOgjgf/Owykd4xM5esusvzNOQy8I8oUCrbX/
yxPI+spnxLyM3U7f7He68vjS86KPn/5pvwbXiRNfFF9KPjk6qE7w+daSgZLOh/NP
BafdMFIW1E7csCnTPZjqEr2gw8WqHAAwD6vd2dkytBkoGfL1UHT4OwUpP1Ig5Vmb
ytJDZ/tx+mG2JVfBfzXAj0n1FOXosho5Md9BcUPMNw1yqwwzJrmzfg22wdJacPzQ
D+K0W3qs/r3YDv++4i/cJa96khB/ng==
=T94O
-----END PGP SIGNATURE-----

--kSjLBUWR7rqI1Fnp--