Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 3 Feb 2021 13:49:22 +0100
From:   Christoph Hellwig <hch@lst.de>
To:     Martin Radev <martin.b.radev@gmail.com>
Cc:     Christoph Hellwig <hch@lst.de>, konrad.wilk@oracle.com,
        m.szyprowski@samsung.com, robin.murphy@arm.com,
        iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
        joro@8bytes.org, kirill.shutemov@linux.intel.com,
        thomas.lendacky@amd.com, robert.buhren@sect.tu-berlin.de,
        file@sect.tu-berlin.de, mathias.morbitzer@aisec.fraunhofer.de,
        virtualization@lists.linux-foundation.org, kvm@vger.kernel.org
Subject: Re: [PATCH] swiotlb: Validate bounce size in the sync/unmap path
Message-ID: <20210203124922.GB16923@lst.de>
References: <X/27MSbfDGCY9WZu@martin> <20210113113017.GA28106@lst.de> <YAV0uhfkimXn1izW@martin>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YAV0uhfkimXn1izW@martin>
User-Agent: Mutt/1.5.17 (2007-11-01)
Precedence: bulk

On Mon, Jan 18, 2021 at 12:44:58PM +0100, Martin Radev wrote:
> Your comment makes sense but then that would require the cooperation
> of these vendors and the cloud providers to agree on something meaningful.
> I am also not sure whether the end result would be better than hardening
> this interface to catch corruption. There is already some validation in
> unmap path anyway.

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.