linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <ak@linux.intel.com>
To: "Michael S. Tsirkin" <mst@redhat.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: Fri, 10 Sep 2021 09:34:45 -0700	[thread overview]
Message-ID: <f672dc1c-5280-7bbc-7a56-7c7aab31725c@linux.intel.com> (raw)
In-Reply-To: <20210910054044-mutt-send-email-mst@kernel.org>


>>>> And we've been avoiding that drivers can self declare auditing, we've been
>>>> trying to have a separate centralized list so that it's easier to enforce
>>>> and avoids any cut'n'paste mistakes.
>>>>
>>>> -Andi
>>> Now I'm confused. What is proposed here seems to be basically that,
>>> drivers need to declare auditing by replacing ioremap with
>>> ioremap_shared.
>> Auditing is declared on the device model level using a central allow list.
> Can we not have an init call allow list instead of, or in addition to, a
> device allow list?


That would be quite complicated and intrusive. In fact I'm not even sure 
how to do maintain something like this. There are a lot of needed 
initcalls, they would all need to be marked. How can we distinguish 
them? It would be a giant auditing project. And of course how would you 
prevent it from bitrotting?


Basically it would be hundreds of changes all over the tree, just to 
avoid two changes in virtio and MSI. Approach of just stopping the 
initcalls from doing bad things is much less intrusive.

>
>> But this cannot do anything to initcalls that run before probe,
> Can't we extend module_init so init calls are validated against the
> allow list?

See above.


Also the problem isn't really with modules (we rely on udev not loading 
them), but with builtin initcalls


>
>> that's why
>> an extra level of defense of ioremap opt-in is useful.
> OK even assuming this, why is pci_iomap opt-in useful?
> That never happens before probe - there's simply no pci_device then.


Hmm, yes that's true. I guess we can make it default to opt-in for 
pci_iomap.

It only really matters for device less ioremaps.

>
> It looks suspiciously like drivers self-declaring auditing to me which
> we both seem to agree is undesirable. What exactly is the difference?


Just allow listing the ioremaps is not self declaration because the 
device will still not initialize due to the central device filter. If 
you want to use it that has to be changed.

It's just an additional safety net to contain code running before probe.


>
> Or are you just trying to disable anything that runs before probe?


Well anything that could do dangerous host interactions (like processing 
ioremap data) A lot of things are harmless and can be allowed, or 
already blocked elsewhere (e.g. we have a IO port filter). This just 
handles the ioremap/MMIO case.

> In that case I don't see a reason to touch pci drivers though.
> These should be fine with just the device model list.


That won't stop initcalls.


-Andi


>

  reply	other threads:[~2021-09-10 16:34 UTC|newest]

Thread overview: 55+ 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 22:11     ` Andi Kleen
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-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-23 23:56   ` Michael S. Tsirkin
2021-08-24  0:30     ` Kuppuswamy, Sathyanarayanan
2021-08-24  1:04       ` Dan Williams
2021-08-24  2:14         ` Andi Kleen
2021-08-24  9:47           ` Michael S. Tsirkin
2021-08-24 17:20             ` Andi Kleen
2021-08-24 18:55               ` Bjorn Helgaas
2021-08-24 20:14                 ` Andi Kleen
2021-08-24 20:31                   ` Bjorn Helgaas
2021-08-24 20:50                     ` Andi Kleen
2021-08-24 21:05                       ` Dan Williams
2021-08-25 14:52                       ` Bjorn Helgaas
2021-08-24 21:55                 ` Rajat Jain
2021-08-29 15:27               ` Michael S. Tsirkin
2021-08-29 16:17                 ` Andi Kleen
2021-08-29 22:26                   ` Michael S. Tsirkin
2021-08-30  5:11                     ` Andi Kleen
2021-08-30 20:59                       ` Michael S. Tsirkin
2021-08-31  0:23                         ` Andi Kleen
2021-09-10  9:54                           ` Michael S. Tsirkin
2021-09-10 16:34                             ` Andi Kleen [this message]
2021-09-11 23:54                               ` Michael S. Tsirkin
2021-09-13  5:53                                 ` Michael S. Tsirkin
2021-09-24 22:43                                 ` Andi Kleen
2021-09-27  9:07                                   ` Michael S. Tsirkin
2021-08-24 21:56         ` Rajat Jain
2021-08-24 21:59           ` Dan Williams
2021-08-24  7:07       ` Christoph Hellwig
2021-08-24 17:04         ` Andi Kleen
2021-08-29 15:34           ` Michael S. Tsirkin
2021-08-29 16:43             ` Andi Kleen
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-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=f672dc1c-5280-7bbc-7a56-7c7aab31725c@linux.intel.com \
    --to=ak@linux.intel.com \
    --cc=James.Bottomley@hansenpartnership.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@linux.intel.com \
    --cc=knsathya@kernel.org \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mst@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rth@twiddle.net \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=seanjc@google.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=tsbogend@alpha.franken.de \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).