linux-kernel - Re: [PATCH] swiotlb: Validate bounce size in the sync/unmap path

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]

Date:   Fri, 5 Feb 2021 18:58:52 +0100
From:   Christoph Hellwig <hch@....de>
To:     Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:     Christoph Hellwig <hch@....de>,
        Martin Radev <martin.b.radev@...il.com>,
        m.szyprowski@...sung.com, robin.murphy@....com,
        iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
        joro@...tes.org, kirill.shutemov@...ux.intel.com,
        thomas.lendacky@....com, robert.buhren@...t.tu-berlin.de,
        file@...t.tu-berlin.de, mathias.morbitzer@...ec.fraunhofer.de,
        virtualization@...ts.linux-foundation.org, kvm@...r.kernel.org
Subject: Re: [PATCH] swiotlb: Validate bounce size in the sync/unmap path

On Wed, Feb 03, 2021 at 02:36:38PM -0500, Konrad Rzeszutek Wilk wrote:
> > So what?  If you guys want to provide a new capability you'll have to do
> > work.  And designing a new protocol based around the fact that the
> > hardware/hypervisor is not trusted and a copy is always required makes
> > a lot of more sense than throwing in band aids all over the place.
> 
> If you don't trust the hypervisor, what would this capability be in?

Well, they don't trust the hypervisor to not attack the guest somehow,
except through the data read.  I never really understood the concept,
as it leaves too many holes.

But the point is that these schemes want to force bounce buffering
because they think it is more secure.  And if that is what you want
you better have protocol build around the fact that each I/O needs
to use bounce buffers, so you make those buffers the actual shared
memory use for communication, and build the protocol around it.
E.g. you don't force the ridiculous NVMe PRP offset rules on the block
layer, just to make a complicated swiotlb allocation that needs to
preserve the alignment just do I/O.  But instead you have a trivial
ring buffer or whatever because you know I/O will be copied anyway
and none of all the hard work higher layers do to make the I/O suitable
for a normal device apply.