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
| ||
|
Date: Tue, 28 Apr 2020 16:41:04 -0400 From: "Michael S. Tsirkin" <mst@...hat.com> To: Srivatsa Vaddagiri <vatsa@...eaurora.org> Cc: konrad.wilk@...cle.com, jasowang@...hat.com, jan.kiszka@...mens.com, will@...nel.org, stefano.stabellini@...inx.com, iommu@...ts.linux-foundation.org, virtualization@...ts.linux-foundation.org, virtio-dev@...ts.oasis-open.org, tsoni@...eaurora.org, pratikp@...eaurora.org, christoffer.dall@....com, alex.bennee@...aro.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 5/5] virtio: Add bounce DMA ops On Tue, Apr 28, 2020 at 11:19:52PM +0530, Srivatsa Vaddagiri wrote: > * Michael S. Tsirkin <mst@...hat.com> [2020-04-28 12:17:57]: > > > Okay, but how is all this virtio specific? For example, why not allow > > separate swiotlbs for any type of device? > > For example, this might make sense if a given device is from a > > different, less trusted vendor. > > Is swiotlb commonly used for multiple devices that may be on different trust > boundaries (and not behind a hardware iommu)? Even a hardware iommu does not imply a 100% security from malicious hardware. First lots of people use iommu=pt for performance reasons. Second even without pt, unmaps are often batched, and sub-page buffers might be used for DMA, so we are not 100% protected at all times. > If so, then yes it sounds like a > good application of multiple swiotlb pools. > > > All this can then maybe be hidden behind the DMA API. > > Won't we still need some changes to virtio to make use of its own pool (to > bounce buffers)? Something similar to its own DMA ops proposed in this patch? If you are doing this for all devices, you need to either find a way to do this without chaning DMA ops, or by doing some automatic change to all drivers. > > > +void virtio_bounce_set_dma_ops(struct virtio_device *vdev) > > > +{ > > > + if (!bounce_buf_paddr) > > > + return; > > > + > > > + set_dma_ops(vdev->dev.parent, &virtio_dma_ops); > > > > > > I don't think DMA API maintainers will be happy with new users > > of set_dma_ops. > > Is there an alternate API that is more preffered? all this is supposed to be part of DMA API itself. new drivers aren't supposed to have custom DMA ops. > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation
Powered by blists - more mailing lists