linux-kernel - Re: [PATCH 5/5] virtio: Add bounce DMA ops

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20200429100953.GE5097@quicinc.com>
Date:   Wed, 29 Apr 2020 15:39:53 +0530
From:   Srivatsa Vaddagiri <vatsa@...eaurora.org>
To:     "Michael S. Tsirkin" <mst@...hat.com>
Cc:     Lu Baolu <baolu.lu@...ux.intel.com>, tsoni@...eaurora.org,
        virtio-dev@...ts.oasis-open.org, konrad.wilk@...cle.com,
        jan.kiszka@...mens.com, jasowang@...hat.com,
        christoffer.dall@....com,
        virtualization@...ts.linux-foundation.org, alex.bennee@...aro.org,
        iommu@...ts.linux-foundation.org, stefano.stabellini@...inx.com,
        will@...nel.org, linux-kernel@...r.kernel.org,
        pratikp@...eaurora.org
Subject: Re: [PATCH 5/5] virtio: Add bounce DMA ops

* Michael S. Tsirkin <mst@...hat.com> [2020-04-29 05:52:05]:

> > > So it seems that with modern Linux, all one needs
> > > to do on x86 is mark the device as untrusted.
> > > It's already possible to do this with ACPI and with OF - would that be
> > > sufficient for achieving what this patchset is trying to do?
> > 
> > In my case, its not sufficient to just mark virtio device untrusted and thus
> > activate the use of swiotlb. All of the secondary VM memory, including those
> > allocate by swiotlb driver, is private to it.
> 
> So why not make the bounce buffer memory shared then?

Its a limitation by our hypervisor. When a secondary VM is created, two
memory segments are allocated - one private and other shared. There is no
provision for the secondary VM to make part of its private memory shared after
it boots. I can perhaps consider a change in swiotlb driver to accept the second
shared memory segment as its main working area (rather than allocate its own).

That would still not work I think where swiotlb is used for pass-thr devices
(when private memory is fine) as well as virtio devices (when shared memory is
required).

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation