linux-kernel - Re: [RFC PATCH V2 0/7] Do not read from descripto ring

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YJ1TgoFSwOkQrC+1@stefanha-x1.localdomain>
Date:   Thu, 13 May 2021 17:27:46 +0100
From:   Stefan Hajnoczi <stefanha@...hat.com>
To:     Jason Wang <jasowang@...hat.com>
Cc:     mst@...hat.com, virtualization@...ts.linux-foundation.org,
        linux-kernel@...r.kernel.org, xieyongji@...edance.com,
        file@...t.tu-berlin.de, ashish.kalra@....com,
        konrad.wilk@...cle.com, kvm@...r.kernel.org, hch@...radead.org
Subject: Re: [RFC PATCH V2 0/7] Do not read from descripto ring

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

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)