From: "Michael S. Tsirkin" <mst@redhat.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
"Kuppuswamy,
Sathyanarayanan" <sathyanarayanan.kuppuswamy@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Peter Zijlstra <peterz@infradead.org>,
Andy Lutomirski <luto@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Richard Henderson <rth@twiddle.net>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
James E J Bottomley <James.Bottomley@hansenpartnership.com>,
Helge Deller <deller@gmx.de>,
"David S . Miller" <davem@davemloft.net>,
Arnd Bergmann <arnd@arndb.de>, Jonathan Corbet <corbet@lwn.net>,
Peter H Anvin <hpa@zytor.com>,
Dave Hansen <dave.hansen@intel.com>,
Tony Luck <tony.luck@intel.com>,
Kirill Shutemov <kirill.shutemov@lin>
Subject: Re: [PATCH v4 11/15] pci: Add pci_iomap_shared{,_range}
Date: Tue, 24 Aug 2021 05:47:03 -0400 [thread overview]
Message-ID: <20210824053830-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <d992b5af-8d57-6aa6-bd49-8e2b8d832b19@linux.intel.com>
On Mon, Aug 23, 2021 at 07:14:18PM -0700, Andi Kleen wrote:
>
> On 8/23/2021 6:04 PM, Dan Williams wrote:
> > On Mon, Aug 23, 2021 at 5:31 PM Kuppuswamy, Sathyanarayanan
> > <sathyanarayanan.kuppuswamy@linux.intel.com> 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<ak@linux.intel.com>
> > > > > Signed-off-by: Kuppuswamy Sathyanarayanan<sathyanarayanan.kuppuswamy@linux.intel.com>
> > > > 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
I see. Hmm. It's a bit of a random thing to do it at the map time
though. E.g. DMA is all handled transparently behind the DMA API.
Hardening is much more than just replacing map with map_shared
and I suspect what you will end up with is basically
vendors replacing map with map shared to make things work
for their users and washing their hands.
I would say an explicit flag in the driver that says "hardened"
and refusing to init a non hardened one would be better.
--
MST
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
"Kuppuswamy,
Sathyanarayanan" <sathyanarayanan.kuppuswamy@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Peter Zijlstra <peterz@infradead.org>,
Andy Lutomirski <luto@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Richard Henderson <rth@twiddle.net>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
James E J Bottomley <James.Bottomley@hansenpartnership.com>,
Helge Deller <deller@gmx.de>,
"David S . Miller" <davem@davemloft.net>,
Arnd Bergmann <arnd@arndb.de>, Jonathan Corbet <corbet@lwn.net>,
Peter H Anvin <hpa@zytor.com>,
Dave Hansen <dave.hansen@intel.com>,
Tony Luck <tony.luck@intel.com>,
Kirill Shutemov <kirill.shutemov@linux.intel.com>,
Sean Christopherson <seanjc@google.com>,
Kuppuswamy Sathyanarayanan <knsathya@kernel.org>,
X86 ML <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux PCI <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 <linux-arch@vger.kernel.org>,
Linux Doc Mailing List <linux-doc@vger.kernel.org>,
virtualization@lists.linux-foundation.org
Subject: Re: [PATCH v4 11/15] pci: Add pci_iomap_shared{,_range}
Date: Tue, 24 Aug 2021 05:47:03 -0400 [thread overview]
Message-ID: <20210824053830-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <d992b5af-8d57-6aa6-bd49-8e2b8d832b19@linux.intel.com>
On Mon, Aug 23, 2021 at 07:14:18PM -0700, Andi Kleen wrote:
>
> On 8/23/2021 6:04 PM, Dan Williams wrote:
> > On Mon, Aug 23, 2021 at 5:31 PM Kuppuswamy, Sathyanarayanan
> > <sathyanarayanan.kuppuswamy@linux.intel.com> 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<ak@linux.intel.com>
> > > > > Signed-off-by: Kuppuswamy Sathyanarayanan<sathyanarayanan.kuppuswamy@linux.intel.com>
> > > > 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
I see. Hmm. It's a bit of a random thing to do it at the map time
though. E.g. DMA is all handled transparently behind the DMA API.
Hardening is much more than just replacing map with map_shared
and I suspect what you will end up with is basically
vendors replacing map with map shared to make things work
for their users and washing their hands.
I would say an explicit flag in the driver that says "hardened"
and refusing to init a non hardened one would be better.
--
MST
WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: "Kuppuswamy,
Sathyanarayanan" <sathyanarayanan.kuppuswamy@linux.intel.com>,
Kuppuswamy Sathyanarayanan <knsathya@kernel.org>,
Linux Doc Mailing List <linux-doc@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Linux PCI <linux-pci@vger.kernel.org>,
linux-mips@vger.kernel.org,
James E J Bottomley <James.Bottomley@hansenpartnership.com>,
Dave Hansen <dave.hansen@intel.com>,
Peter H Anvin <hpa@zytor.com>,
sparclinux@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
linux-arch <linux-arch@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>, Helge Deller <deller@gmx.de>,
X86 ML <x86@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Arnd Bergmann <arnd@arndb.de>, Tony Luck <tony.luck@intel.com>,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Dan Williams <dan.j.williams@intel.com>,
virtualization@lists.linux-foundation.org,
Richard Henderson <rth@twiddle.net>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
linux-parisc@vger.kernel.org,
Sean Christopherson <seanjc@google.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-alpha@vger.kernel.org,
"David S . Miller" <davem@davemloft.net>,
Kirill Shutemov <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH v4 11/15] pci: Add pci_iomap_shared{,_range}
Date: Tue, 24 Aug 2021 05:47:03 -0400 [thread overview]
Message-ID: <20210824053830-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <d992b5af-8d57-6aa6-bd49-8e2b8d832b19@linux.intel.com>
On Mon, Aug 23, 2021 at 07:14:18PM -0700, Andi Kleen wrote:
>
> On 8/23/2021 6:04 PM, Dan Williams wrote:
> > On Mon, Aug 23, 2021 at 5:31 PM Kuppuswamy, Sathyanarayanan
> > <sathyanarayanan.kuppuswamy@linux.intel.com> 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<ak@linux.intel.com>
> > > > > Signed-off-by: Kuppuswamy Sathyanarayanan<sathyanarayanan.kuppuswamy@linux.intel.com>
> > > > 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
I see. Hmm. It's a bit of a random thing to do it at the map time
though. E.g. DMA is all handled transparently behind the DMA API.
Hardening is much more than just replacing map with map_shared
and I suspect what you will end up with is basically
vendors replacing map with map shared to make things work
for their users and washing their hands.
I would say an explicit flag in the driver that says "hardened"
and refusing to init a non hardened one would be better.
--
MST
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2021-08-24 9:47 UTC|newest]
Thread overview: 129+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-05 0:52 [PATCH v4 00/15] Add TDX Guest Support (shared-mm support) Kuppuswamy Sathyanarayanan
2021-08-05 0:52 ` [PATCH v4 01/15] x86/mm: Move force_dma_unencrypted() to common code Kuppuswamy Sathyanarayanan
2021-08-05 0:52 ` [PATCH v4 02/15] x86/tdx: Exclude Shared bit from physical_mask Kuppuswamy Sathyanarayanan
2021-08-05 0:52 ` [PATCH v4 03/15] x86/tdx: Make pages shared in ioremap() Kuppuswamy Sathyanarayanan
2021-08-05 0:52 ` [PATCH v4 04/15] x86/tdx: Add helper to do MapGPA hypercall Kuppuswamy Sathyanarayanan
2021-08-05 0:52 ` [PATCH v4 05/15] x86/tdx: Make DMA pages shared Kuppuswamy Sathyanarayanan
2021-08-05 0:52 ` [PATCH v4 06/15] x86/kvm: Use bounce buffers for TD guest Kuppuswamy Sathyanarayanan
2021-08-05 0:52 ` [PATCH v4 07/15] x86/tdx: ioapic: Add shared bit for IOAPIC base address Kuppuswamy Sathyanarayanan
2021-08-05 0:52 ` [PATCH v4 08/15] x86/tdx: Enable shared memory protected guest flags for TDX guest Kuppuswamy Sathyanarayanan
2021-08-05 0:52 ` [PATCH v4 09/15] pci: Consolidate pci_iomap* and pci_iomap*wc Kuppuswamy Sathyanarayanan
2021-08-12 19:43 ` Bjorn Helgaas
2021-08-12 19:43 ` Bjorn Helgaas
2021-08-12 19:43 ` Bjorn Helgaas
2021-08-12 22:11 ` Andi Kleen
2021-08-12 22:11 ` Andi Kleen
2021-08-12 22:11 ` Andi Kleen
2021-08-12 22:29 ` Kuppuswamy, Sathyanarayanan
2021-08-12 22:29 ` Kuppuswamy, Sathyanarayanan
2021-08-05 0:52 ` [PATCH v4 10/15] asm/io.h: Add ioremap_shared fallback Kuppuswamy Sathyanarayanan
2021-08-12 19:46 ` Bjorn Helgaas
2021-08-12 19:46 ` Bjorn Helgaas
2021-08-12 19:46 ` Bjorn Helgaas
2021-08-13 7:58 ` Christoph Hellwig
2021-08-13 7:58 ` Christoph Hellwig
2021-08-13 7:58 ` Christoph Hellwig
2021-08-05 0:52 ` [PATCH v4 11/15] pci: Add pci_iomap_shared{,_range} Kuppuswamy Sathyanarayanan
2021-08-13 8:02 ` Christoph Hellwig
2021-08-13 8:02 ` Christoph Hellwig
2021-08-13 8:02 ` Christoph Hellwig
2021-08-23 23:56 ` Michael S. Tsirkin
2021-08-23 23:56 ` Michael S. Tsirkin
2021-08-23 23:56 ` Michael S. Tsirkin
2021-08-24 0:30 ` Kuppuswamy, Sathyanarayanan
2021-08-24 0:30 ` Kuppuswamy, Sathyanarayanan
2021-08-24 1:04 ` Dan Williams
2021-08-24 1:04 ` Dan Williams
2021-08-24 1:04 ` Dan Williams
2021-08-24 2:14 ` Andi Kleen
2021-08-24 2:14 ` Andi Kleen
2021-08-24 2:14 ` Andi Kleen
2021-08-24 9:47 ` Michael S. Tsirkin [this message]
2021-08-24 9:47 ` Michael S. Tsirkin
2021-08-24 9:47 ` Michael S. Tsirkin
2021-08-24 17:20 ` Andi Kleen
2021-08-24 17:20 ` Andi Kleen
2021-08-24 17:20 ` Andi Kleen
2021-08-24 18:55 ` Bjorn Helgaas
2021-08-24 18:55 ` Bjorn Helgaas
2021-08-24 18:55 ` Bjorn Helgaas
2021-08-24 20:14 ` Andi Kleen
2021-08-24 20:14 ` Andi Kleen
2021-08-24 20:14 ` Andi Kleen
2021-08-24 20:31 ` Bjorn Helgaas
2021-08-24 20:31 ` Bjorn Helgaas
2021-08-24 20:31 ` Bjorn Helgaas
2021-08-24 20:50 ` Andi Kleen
2021-08-24 20:50 ` Andi Kleen
2021-08-24 20:50 ` Andi Kleen
2021-08-24 21:05 ` Dan Williams
2021-08-24 21:05 ` Dan Williams
2021-08-24 21:05 ` Dan Williams
2021-08-25 14:52 ` Bjorn Helgaas
2021-08-25 14:52 ` Bjorn Helgaas
2021-08-25 14:52 ` Bjorn Helgaas
2021-08-24 21:55 ` Rajat Jain
2021-08-24 21:55 ` Rajat Jain
2021-08-29 15:27 ` Michael S. Tsirkin
2021-08-29 15:27 ` Michael S. Tsirkin
2021-08-29 15:27 ` Michael S. Tsirkin
2021-08-29 16:17 ` Andi Kleen
2021-08-29 16:17 ` Andi Kleen
2021-08-29 16:17 ` Andi Kleen
2021-08-29 22:26 ` Michael S. Tsirkin
2021-08-29 22:26 ` Michael S. Tsirkin
2021-08-29 22:26 ` Michael S. Tsirkin
2021-08-30 5:11 ` Andi Kleen
2021-08-30 5:11 ` Andi Kleen
2021-08-30 5:11 ` Andi Kleen
2021-08-30 20:59 ` Michael S. Tsirkin
2021-08-30 20:59 ` Michael S. Tsirkin
2021-08-30 20:59 ` Michael S. Tsirkin
2021-08-31 0:23 ` Andi Kleen
2021-08-31 0:23 ` Andi Kleen
2021-08-31 0:23 ` Andi Kleen
2021-09-10 9:54 ` Michael S. Tsirkin
2021-09-10 9:54 ` Michael S. Tsirkin
2021-09-10 9:54 ` Michael S. Tsirkin
2021-09-10 16:34 ` Andi Kleen
2021-09-10 16:34 ` Andi Kleen
2021-09-10 16:34 ` Andi Kleen
2021-09-11 23:54 ` Michael S. Tsirkin
2021-09-11 23:54 ` Michael S. Tsirkin
2021-09-11 23:54 ` Michael S. Tsirkin
2021-09-13 5:53 ` Michael S. Tsirkin
2021-09-13 5:53 ` Michael S. Tsirkin
2021-09-13 5:53 ` Michael S. Tsirkin
2021-09-24 22:43 ` Andi Kleen
2021-09-24 22:43 ` Andi Kleen
2021-09-24 22:43 ` Andi Kleen
2021-09-27 9:07 ` Michael S. Tsirkin
2021-09-27 9:07 ` Michael S. Tsirkin
2021-09-27 9:07 ` Michael S. Tsirkin
2021-08-24 21:56 ` Rajat Jain
2021-08-24 21:56 ` Rajat Jain
2021-08-24 21:59 ` Dan Williams
2021-08-24 21:59 ` Dan Williams
2021-08-24 21:59 ` Dan Williams
2021-08-24 7:07 ` Christoph Hellwig
2021-08-24 7:07 ` Christoph Hellwig
2021-08-24 7:07 ` Christoph Hellwig
2021-08-24 17:04 ` Andi Kleen
2021-08-24 17:04 ` Andi Kleen
2021-08-24 17:04 ` Andi Kleen
2021-08-29 15:34 ` Michael S. Tsirkin
2021-08-29 15:34 ` Michael S. Tsirkin
2021-08-29 15:34 ` Michael S. Tsirkin
2021-08-29 16:43 ` Andi Kleen
2021-08-29 16:43 ` Andi Kleen
2021-08-29 16:43 ` Andi Kleen
2021-08-24 9:12 ` Michael S. Tsirkin
2021-08-24 9:12 ` Michael S. Tsirkin
2021-08-24 9:12 ` Michael S. Tsirkin
2021-08-05 0:52 ` [PATCH v4 12/15] pci: Mark MSI data shared Kuppuswamy Sathyanarayanan
2021-08-13 8:07 ` Christoph Hellwig
2021-08-13 8:07 ` Christoph Hellwig
2021-08-13 8:07 ` Christoph Hellwig
2021-08-05 0:52 ` [PATCH v4 13/15] virtio: Use shared mappings for virtio PCI devices Kuppuswamy Sathyanarayanan
2021-08-05 0:52 ` [PATCH v4 14/15] x86/tdx: Implement ioremap_shared for x86 Kuppuswamy Sathyanarayanan
2021-08-05 0:52 ` [PATCH v4 15/15] x86/tdx: Add cmdline option to force use of ioremap_shared Kuppuswamy Sathyanarayanan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210824053830-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=ak@linux.intel.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=hpa@zytor.com \
--cc=kirill.shutemov@lin \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rth@twiddle.net \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=tsbogend@alpha.franken.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.