Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp3140198pxb; Sat, 9 Oct 2021 02:54:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzI4DReTw+C9BEbZgPRTNeh1ubH9fu9tu2qV53zfSWadzNWHeVkRrbgzi3HehEAvgAPaqp/ X-Received: by 2002:a62:d11e:0:b0:446:d705:7175 with SMTP id z30-20020a62d11e000000b00446d7057175mr14976647pfg.74.1633773287668; Sat, 09 Oct 2021 02:54:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633773287; cv=none; d=google.com; s=arc-20160816; b=l1p6XUvPuUlIwBSfMG39RiPcQazxdcXe4RbHP6vVY0EUJ+sCs65AZj6nqNMP5MhTbG 0ZwzoF/ryGPnTvoW01copZU7I2SdVhGYQ/mTDKJW48GOQwDBo01cQUIq0SPF2JPurNMu gr5OguTxWd12PYGKXt/fTwy+C8Sx1HP97L2tOgQHhi8KZCdPZasxHQl9w0n23v2wRh/d mCoQ8Zd9yvyAycMmfscBokUFqm4pkiLLPIMt4Nd21rdMfNNaJMG3X0SLEt66Ijfqqdpt whVMJg+BPh/6W8iC8g+IoK8EgedyKEGeyyEGV8vL0j9WVyUvo3SwyzdiFPIk2NBUmsQg yfrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=TC+ficJjTyhwmBtLURsKztDpUSSEvDlSazI7HDdGRfI=; b=W5oV9sVsHxlquTUIdrZKZgPNM1QgxqzvIarhIbsstXYXdDUvM5J0MiAE6vDYhracns bJw6tFs7TuSniyU+MvErg1H6RBWdys2DMa4PtT+lh1kPi4ZBNxeu7bFPtvVf7jk0RU5x lC1J+TT8/Pi6qrt+LNzDOqomwfQG170obEXj6q73KyRzIz1zgb3TIKWOFUQ1zSR9fz4d 8gjL46+heEzvLUwaPA07VLIQg4Sav8OHaXv5JV4KHw4LKhzwWHnpRjiYIfIEZ7/lXaY+ 67sMP9raaVqi91LSXUgvb9hDEJ0VW2NcOn6MmnaxMUp89dYRj+ERHvKp9d8GgxOOV+6S 0aNw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=iv8+UKaW; 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 m19si3768895pgu.266.2021.10.09.02.54.32; Sat, 09 Oct 2021 02:54:47 -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=iv8+UKaW; 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 S232465AbhJIJzo (ORCPT + 99 others); Sat, 9 Oct 2021 05:55:44 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:22072 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230022AbhJIJzm (ORCPT ); Sat, 9 Oct 2021 05:55:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1633773224; 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=TC+ficJjTyhwmBtLURsKztDpUSSEvDlSazI7HDdGRfI=; b=iv8+UKaW5ZFKDxKpica4XBuUmvck8qlYAIrjm7lG4HxAB/ozRSC3DPPJCCvG+cWgkRDCPu ppJJr3o3MlIylnCUctnTafRpJgujaHvlHyO13QUkytLC2RJGIzY6oYrgUcvbtCHJ6Fozfy 8t5YrtTN/CE0hnUx7uLoFBz00VNj0qs= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-456-7GtOUO_7P8mQSJ61vAfQGA-1; Sat, 09 Oct 2021 05:53:41 -0400 X-MC-Unique: 7GtOUO_7P8mQSJ61vAfQGA-1 Received: by mail-ed1-f70.google.com with SMTP id h19-20020aa7de13000000b003db6ad5245bso2789791edv.9 for ; Sat, 09 Oct 2021 02:53:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=TC+ficJjTyhwmBtLURsKztDpUSSEvDlSazI7HDdGRfI=; b=mWfur6QZp7zxBMxAorbO10QbTYmYwPPYEy71qLoLFy+sc6N/G2tfKr8RtD7/21M6lo wx0ADnnUyq2/rRKhDlvkVZAOV4M5lm4kqAG/0mJagM4/SAkqz0khUaZrGJ2b3v+JcXTF ZDoVM6WB/fpOOgZ6jV7PgeWJcEYFmA4dcTNVOji0qpPQ5GCHaSmRen3RuHD5LaO0C8vX WajQaMjfA7K35I4JECkKpAsF1U1VPDx1jDnSftosLk/x5dJhEXzhY/QKkuWjR6hV69a0 LC0lfp3oUD9F9HA8NVoWvEGf7+ywwObOh2wmCDejO7UxHll610ONN6frxZEzKyGyTnsA ZKRg== X-Gm-Message-State: AOAM532JsOPUDYSU4zbGzzHcKLlY7FKmb3YY9jm+cb+ZIoLsu26nOw/d RVqUJFCh30LEB3AudnjUQ+Y12PN8EeNEAalJrK3aoh5RAmzV+Zx6T2EYfAugCS62Ccs6jxlfOrW VpRKqq1HKuA8coLOrmxuFIpyu X-Received: by 2002:a17:906:2bc7:: with SMTP id n7mr10404150ejg.238.1633773220395; Sat, 09 Oct 2021 02:53:40 -0700 (PDT) X-Received: by 2002:a17:906:2bc7:: with SMTP id n7mr10404118ejg.238.1633773220163; Sat, 09 Oct 2021 02:53:40 -0700 (PDT) Received: from redhat.com ([2.55.132.170]) by smtp.gmail.com with ESMTPSA id rv25sm776493ejb.21.2021.10.09.02.53.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Oct 2021 02:53:39 -0700 (PDT) Date: Sat, 9 Oct 2021 05:53:32 -0400 From: "Michael S. Tsirkin" To: Kuppuswamy Sathyanarayanan Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Peter Zijlstra , Andy Lutomirski , Bjorn Helgaas , Richard Henderson , Thomas Bogendoerfer , James E J Bottomley , Helge Deller , "David S . Miller" , Arnd Bergmann , Jonathan Corbet , Paolo Bonzini , David Hildenbrand , Andrea Arcangeli , Josh Poimboeuf , Peter H Anvin , Dave Hansen , Tony Luck , Dan Williams , Andi Kleen , Kirill Shutemov , Sean Christopherson , Kuppuswamy Sathyanarayanan , x86@kernel.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-alpha@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, sparclinux@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: Re: [PATCH v5 12/16] PCI: Add pci_iomap_host_shared(), pci_iomap_host_shared_range() Message-ID: <20211009053103-mutt-send-email-mst@kernel.org> References: <20211009003711.1390019-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20211009003711.1390019-13-sathyanarayanan.kuppuswamy@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211009003711.1390019-13-sathyanarayanan.kuppuswamy@linux.intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 08, 2021 at 05:37:07PM -0700, Kuppuswamy Sathyanarayanan wrote: > From: Andi Kleen > > For Confidential VM guests like TDX, the host is untrusted and hence > the devices emulated by the host or any data coming from the host > cannot be trusted. So the drivers that interact with the outside world > have to be hardened by sharing memory with host on need basis > with proper hardening fixes. > > For the PCI driver case, to share the memory with the host add > pci_iomap_host_shared() and pci_iomap_host_shared_range() APIs. > > Signed-off-by: Andi Kleen > Signed-off-by: Kuppuswamy Sathyanarayanan So I proposed to make all pci mappings shared, eliminating the need to patch drivers. To which Andi replied One problem with removing the ioremap opt-in is that it's still possible for drivers to get at devices without going through probe. To which Greg replied: https://lore.kernel.org/all/YVXBNJ431YIWwZdQ@kroah.com/ If there are in-kernel PCI drivers that do not do this, they need to be fixed today. Can you guys resolve the differences here? And once they are resolved, mention this in the commit log so I don't get to re-read the series just to find out nothing changed in this respect? I frankly do not believe we are anywhere near being able to harden an arbitrary kernel config against attack. How about creating a defconfig that makes sense for TDX then? Anyone deviating from that better know what they are doing, this API tweaking is just putting policy into the kernel ... > --- > Changes since v4: > * Replaced "_shared" with "_host_shared" in pci_iomap* APIs > * Fixed commit log as per review comments. > > include/asm-generic/pci_iomap.h | 6 +++++ > lib/pci_iomap.c | 47 +++++++++++++++++++++++++++++++++ > 2 files changed, 53 insertions(+) > > diff --git a/include/asm-generic/pci_iomap.h b/include/asm-generic/pci_iomap.h > index df636c6d8e6c..a4a83c8ab3cf 100644 > --- a/include/asm-generic/pci_iomap.h > +++ b/include/asm-generic/pci_iomap.h > @@ -18,6 +18,12 @@ extern void __iomem *pci_iomap_range(struct pci_dev *dev, int bar, > extern void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar, > unsigned long offset, > unsigned long maxlen); > +extern void __iomem *pci_iomap_host_shared(struct pci_dev *dev, int bar, > + unsigned long max); > +extern void __iomem *pci_iomap_host_shared_range(struct pci_dev *dev, int bar, > + unsigned long offset, > + unsigned long maxlen); > + > /* Create a virtual mapping cookie for a port on a given PCI device. > * Do not call this directly, it exists to make it easier for architectures > * to override */ > diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c > index 57bd92f599ee..2816dc8715da 100644 > --- a/lib/pci_iomap.c > +++ b/lib/pci_iomap.c > @@ -25,6 +25,11 @@ static void __iomem *map_ioremap_wc(phys_addr_t addr, size_t size) > return ioremap_wc(addr, size); > } > > +static void __iomem *map_ioremap_host_shared(phys_addr_t addr, size_t size) > +{ > + return ioremap_host_shared(addr, size); > +} > + > static void __iomem *pci_iomap_range_map(struct pci_dev *dev, > int bar, > unsigned long offset, > @@ -106,6 +111,48 @@ void __iomem *pci_iomap_wc_range(struct pci_dev *dev, > } > EXPORT_SYMBOL_GPL(pci_iomap_wc_range); > > +/** > + * pci_iomap_host_shared_range - create a virtual shared mapping cookie > + * for a PCI BAR > + * @dev: PCI device that owns the BAR > + * @bar: BAR number > + * @offset: map memory at the given offset in BAR > + * @maxlen: max length of the memory to map > + * > + * Remap a pci device's resources shared in a confidential guest. > + * For more details see pci_iomap_range's documentation. So how does a driver author know when to use this function, and when to use the regular pci_iomap_range? Drivers have no idea whether they are used in a confidential guest, and which ranges are shared, it's a TDX thing ... This documentation should really address it. > + * > + * @maxlen specifies the maximum length to map. To get access to > + * the complete BAR from offset to the end, pass %0 here. > + */ > +void __iomem *pci_iomap_host_shared_range(struct pci_dev *dev, int bar, > + unsigned long offset, > + unsigned long maxlen) > +{ > + return pci_iomap_range_map(dev, bar, offset, maxlen, > + map_ioremap_host_shared, true); > +} > +EXPORT_SYMBOL_GPL(pci_iomap_host_shared_range); > + > +/** > + * pci_iomap_host_shared - create a virtual shared mapping cookie for a PCI BAR > + * @dev: PCI device that owns the BAR > + * @bar: BAR number > + * @maxlen: length of the memory to map > + * > + * See pci_iomap for details. This function creates a shared mapping > + * with the host for confidential hosts. > + * > + * @maxlen specifies the maximum length to map. To get access to the > + * complete BAR without checking for its length first, pass %0 here. > + */ > +void __iomem *pci_iomap_host_shared(struct pci_dev *dev, int bar, > + unsigned long maxlen) > +{ > + return pci_iomap_host_shared_range(dev, bar, 0, maxlen); > +} > +EXPORT_SYMBOL_GPL(pci_iomap_host_shared); > + > /** > * pci_iomap - create a virtual mapping cookie for a PCI BAR > * @dev: PCI device that owns the BAR > -- > 2.25.1