From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: [PATCH v4 11/15] pci: Add pci_iomap_shared{,_range} Date: Mon, 23 Aug 2021 19:14:18 -0700 Message-ID: References: <20210805005218.2912076-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20210805005218.2912076-12-sathyanarayanan.kuppuswamy@linux.intel.com> <20210823195409-mutt-send-email-mst@kernel.org> <26a3cce5-ddf7-cbe6-a41e-58a2aea48f78@linux.intel.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Dan Williams , "Kuppuswamy, Sathyanarayanan" Cc: "Michael S. Tsirkin" , 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 , Peter H Anvin , Dave Hansen , Tony Luck , Kirill Shutemov , Sean Christopherson , Kuppuswamy On 8/23/2021 6:04 PM, Dan Williams wrote: > On Mon, Aug 23, 2021 at 5:31 PM Kuppuswamy, Sathyanarayanan > wrote: >> >> >> On 8/23/21 4:56 PM, Michael S. Tsirkin wrote: >>>> Add a new variant of pci_iomap for mapping all PCI resources >>>> of a devices as shared memory with a hypervisor in a confidential >>>> guest. >>>> >>>> Signed-off-by: Andi Kleen >>>> Signed-off-by: Kuppuswamy Sathyanarayanan >>> I'm a bit puzzled by this part. So why should the guest*not* map >>> pci memory as shared? And if the answer is never (as it seems to be) >>> then why not just make regular pci_iomap DTRT? >> It is in the context of confidential guest (where VMM is un-trusted). So >> we don't want to make all PCI resource as shared. It should be allowed >> only for hardened drivers/devices. > That's confusing, isn't device authorization what keeps unaudited > drivers from loading against untrusted devices? I'm feeling like > Michael that this should be a detail that drivers need not care about > explicitly, in which case it does not need to be exported because the > detail can be buried in lower levels. We originally made it default (similar to AMD), but it during code audit we found a lot of drivers who do ioremap early outside the probe function. Since it would be difficult to change them all we made it opt-in, which ensures that only drivers that have been enabled can talk with the host at all and can't be attacked. That made the problem of hardening all these drivers a lot more practical. Currently we only really need virtio and MSI-X shared, so for changing two places in the tree you avoid a lot of headache elsewhere. Note there is still a command line option to override if you want to allow and load other drivers. -Andi