Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2567292ybt; Tue, 16 Jun 2020 09:11:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz89kDrUZY5vdJAT7JmV7+UmxMfHmcNBDt/a9Xts1TmKaFO3flParZ8Vr9O6pDOspV3KDl0 X-Received: by 2002:a17:906:7c5a:: with SMTP id g26mr3520749ejp.200.1592323898957; Tue, 16 Jun 2020 09:11:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592323898; cv=none; d=google.com; s=arc-20160816; b=PnB9PuXhT0QOS3PXDiL1TZ0n1F4DN1b9EA7z/UfIesJ2DaNrFUMKTaNvjibAGmR+96 yFnT1JXnXRk0G2SzwGJBcs4LFEyFR+vnERYDHUFuO1THCx4V50B0OqSMOgoNassb3XcL N3iWXsArHD9668z4SqmMRak0SSyKvBDyFhEsmk7eZRTFZ+aiK0X0aIutp/qo927iabOZ REkjYLPre4r/l7PumstMwFBujGkZGAJOPCHdwfM1KelSl32u58zdECoISgd5yKnhF8wf lHWQoBzEQ/khi8ETO08WbdbMGfdAqkTMVo9T/NOmbbEJBwKr7u1yL8ffWQBEgUKDbk+u 6YxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=2y8KD7xWbYjXU/cEL7LgtQkBTECAhlAA76XR+Aplj6k=; b=eY5FAh1aXVZrbQ8ApdD+nSJsA7ayoha3OWyKZ2EWDP1AncjFYIzs1/qRmOVH2jPGIm agetSA0N0Rn3xTAXv0FhFjKq6nnfz0J42DErn8z2Tf5LqVgShNntxs4GA/8JbqkHCkW/ 5y2EzC32/cH7eCnhlCeRZpp0oAvadOpTAecqTeFro+OjPQ90q/K1DCeuhe3lZqRVk16G UXFlBmL0JAEW6ryFTAwjUlU1TMO2dB7vuBFFVN76ynI6r5LSMolldZqgYsdxyBe3fbpE S4Lic1LznUbo5baqhr9v3sbeJw95LEEAU0ev4sydr6UyMctUA8MsJ3P2WfQAoejPf3rP hlew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="XT/uDfKZ"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j1si11071611edy.413.2020.06.16.09.11.16; Tue, 16 Jun 2020 09:11:38 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="XT/uDfKZ"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732614AbgFPQJd (ORCPT + 99 others); Tue, 16 Jun 2020 12:09:33 -0400 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:29807 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1732628AbgFPQJW (ORCPT ); Tue, 16 Jun 2020 12:09:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592323761; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2y8KD7xWbYjXU/cEL7LgtQkBTECAhlAA76XR+Aplj6k=; b=XT/uDfKZ+Nz+aKowO4BAdx/H5jwyTOnD34TZbFaDITYa3rC14T/bPWPFfbjAviz+qNEVP3 /9Ud2KhGIkL69nuh+nUNSnQr461W94Pmov/gsP9vJJWr2UfsgNpBXI/AHKi02EPH75JhTd bXS6KQdqzryLGWRMALwusGgaUlBg/dQ= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-505-o0V_QEgzMSuTzbl1AfG3Xg-1; Tue, 16 Jun 2020 12:09:19 -0400 X-MC-Unique: o0V_QEgzMSuTzbl1AfG3Xg-1 Received: by mail-qt1-f198.google.com with SMTP id y5so17126531qtd.0 for ; Tue, 16 Jun 2020 09:09:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=2y8KD7xWbYjXU/cEL7LgtQkBTECAhlAA76XR+Aplj6k=; b=FS9Hxt+KDw7hhFODPY+dGkFqXIq5AsJ0R3U7vv6oVFopigQCkmczx9TE1cAr/+KGJJ mmrmEV28ucDM4m1CKKajRTeZGa5i/jccIrbaaZVN4i4If/FavDv3NIDginETH30gSM8G T9CYnhp6zsJ7C06XfGenp05w4OTUTPwqYvlY1jVf8hv+dSXxxCJ/J6RFCZktQwb+eOZW 1az74paapKlyV1WMrzPLVorlxWWqMi8EvnIvRaXtKMfo0SvHjtQIMbSxJ8zHHNkPAxIp XsCgPek6i5LjozXq3dAyS4I6zZYV2SLvaqdEtWvTS636wMxNYkt+iw02nO92HP6Tdm2Q nGSA== X-Gm-Message-State: AOAM531L2mi9inYeZLaaUZGX+aiR9t9T2kGAIdwhhj4b85NMlNce87PE wJJN0Ge9z4D+ET9kVm4A4gZ3+K1Fxm42SdCjYxNHry0gjTNB9ycee9f9bgJBITsaEEt5U/KGcyb XZpKGpMtDAC56DsO9ICQXO0eL X-Received: by 2002:ad4:54ea:: with SMTP id k10mr3112698qvx.66.1592323758931; Tue, 16 Jun 2020 09:09:18 -0700 (PDT) X-Received: by 2002:ad4:54ea:: with SMTP id k10mr3112676qvx.66.1592323758723; Tue, 16 Jun 2020 09:09:18 -0700 (PDT) Received: from xz-x1 ([2607:9880:19c0:32::2]) by smtp.gmail.com with ESMTPSA id y1sm15552040qta.82.2020.06.16.09.09.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2020 09:09:17 -0700 (PDT) Date: Tue, 16 Jun 2020 12:09:16 -0400 From: Peter Xu To: Stefan Hajnoczi Cc: "Tian, Kevin" , "Liu, Yi L" , "alex.williamson@redhat.com" , "eric.auger@redhat.com" , "baolu.lu@linux.intel.com" , "joro@8bytes.org" , "jacob.jun.pan@linux.intel.com" , "Raj, Ashok" , "Tian, Jun J" , "Sun, Yi Y" , "jean-philippe@linaro.org" , "Wu, Hao" , "iommu@lists.linux-foundation.org" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2 00/15] vfio: expose virtual Shared Virtual Addressing to VMs Message-ID: <20200616160916.GC11838@xz-x1> References: <1591877734-66527-1-git-send-email-yi.l.liu@intel.com> <20200615100214.GC1491454@stefanha-x1.localdomain> <20200616154928.GF1491454@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200616154928.GF1491454@stefanha-x1.localdomain> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 16, 2020 at 04:49:28PM +0100, Stefan Hajnoczi wrote: > Isolation between applications is preserved but there is no isolation > between the device and the application itself. The application needs to > trust the device. > > Examples: > > 1. The device can snoop secret data from readable pages in the > application's virtual memory space. > > 2. The device can gain arbitrary execution on the CPU by overwriting > control flow addresses (e.g. function pointers, stack return > addresses) in writable pages. To me, SVA seems to be that "middle layer" of secure where it's not as safe as VFIO_IOMMU_MAP_DMA which has buffer level granularity of control (but of course we pay overhead on buffer setups and on-the-fly translations), however it's far better than DMA with no IOMMU which can ruin the whole host/guest, because after all we do a lot of isolations as process based. IMHO it's the same as when we see a VM (or the QEMU process) as a whole along with the guest code. In some cases we don't care if the guest did some bad things to mess up with its own QEMU process. It is still ideal if we can even stop the guest from doing so, but when it's not easy to do it the ideal way, we just lower the requirement to not spread the influence to the host and other VMs. Thanks, -- Peter Xu