From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 252D5C433E0 for ; Fri, 5 Feb 2021 18:02:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E1DE164E44 for ; Fri, 5 Feb 2021 18:02:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233564AbhBEQUA (ORCPT ); Fri, 5 Feb 2021 11:20:00 -0500 Received: from verein.lst.de ([213.95.11.211]:32946 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233524AbhBEQRR (ORCPT ); Fri, 5 Feb 2021 11:17:17 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id 1A3F667373; Fri, 5 Feb 2021 18:58:53 +0100 (CET) Date: Fri, 5 Feb 2021 18:58:52 +0100 From: Christoph Hellwig To: Konrad Rzeszutek Wilk Cc: Christoph Hellwig , Martin Radev , 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: <20210205175852.GA1021@lst.de> References: <20210113113017.GA28106@lst.de> <20210203124922.GB16923@lst.de> <20210203193638.GA325136@fedora> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210203193638.GA325136@fedora> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4BA09C433DB for ; Fri, 5 Feb 2021 17:59:05 +0000 (UTC) Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2E83E64E2E for ; Fri, 5 Feb 2021 17:59:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2E83E64E2E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id DDDE086B5E; Fri, 5 Feb 2021 17:59:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ua7Wzk_kmsr; Fri, 5 Feb 2021 17:59:02 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by fraxinus.osuosl.org (Postfix) with ESMTP id B58F586B9D; Fri, 5 Feb 2021 17:59:02 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 44BE4C1E70; Fri, 5 Feb 2021 17:59:02 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8B66CC013A; Fri, 5 Feb 2021 17:59:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 76D738737E; Fri, 5 Feb 2021 17:59:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxVd0ztsHAmM; Fri, 5 Feb 2021 17:58:57 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by hemlock.osuosl.org (Postfix) with ESMTPS id 9B22287349; Fri, 5 Feb 2021 17:58:57 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id 1A3F667373; Fri, 5 Feb 2021 18:58:53 +0100 (CET) Date: Fri, 5 Feb 2021 18:58:52 +0100 From: Christoph Hellwig To: Konrad Rzeszutek Wilk Subject: Re: [PATCH] swiotlb: Validate bounce size in the sync/unmap path Message-ID: <20210205175852.GA1021@lst.de> References: <20210113113017.GA28106@lst.de> <20210203124922.GB16923@lst.de> <20210203193638.GA325136@fedora> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210203193638.GA325136@fedora> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Martin Radev , thomas.lendacky@amd.com, file@sect.tu-berlin.de, robert.buhren@sect.tu-berlin.de, kvm@vger.kernel.org, mathias.morbitzer@aisec.fraunhofer.de, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, iommu@lists.linux-foundation.org, robin.murphy@arm.com, Christoph Hellwig , kirill.shutemov@linux.intel.com X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" 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. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70687C433DB for ; Fri, 5 Feb 2021 17:59:08 +0000 (UTC) Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A4B4A64E2E for ; Fri, 5 Feb 2021 17:59:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A4B4A64E2E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=virtualization-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id DAC9F870D9; Fri, 5 Feb 2021 17:59:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7J5HASj6KPm; Fri, 5 Feb 2021 17:59:02 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by whitealder.osuosl.org (Postfix) with ESMTP id F3E9386E55; Fri, 5 Feb 2021 17:59:01 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id C1410C013A; Fri, 5 Feb 2021 17:59:01 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8B66CC013A; Fri, 5 Feb 2021 17:59:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 76D738737E; Fri, 5 Feb 2021 17:59:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxVd0ztsHAmM; Fri, 5 Feb 2021 17:58:57 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by hemlock.osuosl.org (Postfix) with ESMTPS id 9B22287349; Fri, 5 Feb 2021 17:58:57 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id 1A3F667373; Fri, 5 Feb 2021 18:58:53 +0100 (CET) Date: Fri, 5 Feb 2021 18:58:52 +0100 From: Christoph Hellwig To: Konrad Rzeszutek Wilk Subject: Re: [PATCH] swiotlb: Validate bounce size in the sync/unmap path Message-ID: <20210205175852.GA1021@lst.de> References: <20210113113017.GA28106@lst.de> <20210203124922.GB16923@lst.de> <20210203193638.GA325136@fedora> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210203193638.GA325136@fedora> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Martin Radev , thomas.lendacky@amd.com, file@sect.tu-berlin.de, robert.buhren@sect.tu-berlin.de, kvm@vger.kernel.org, mathias.morbitzer@aisec.fraunhofer.de, joro@8bytes.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, iommu@lists.linux-foundation.org, robin.murphy@arm.com, Christoph Hellwig , kirill.shutemov@linux.intel.com, m.szyprowski@samsung.com X-BeenThere: virtualization@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux virtualization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" 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. _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization