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
Attachment:
signature.asc
Description: PGP signature
