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: Tue, 24 Aug 2021 10:20:44 -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> <20210824053830-mutt-send-email-mst@kernel.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20210824053830-mutt-send-email-mst@kernel.org> Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" Content-Type: text/plain; charset="us-ascii"; format="flowed" To: "Michael S. Tsirkin" Cc: "Kuppuswamy, Sathyanarayanan" , Kuppuswamy Sathyanarayanan , Linux Doc Mailing List , Peter Zijlstra , Linux PCI , linux-mips@vger.kernel.org, James E J Bottomley , Dave Hansen , Peter H Anvin , sparclinux@vger.kernel.org, Thomas Gleixner , linux-arch , Jonathan Corbet , Helge Deller , X86 ML , Ingo Molnar , Arnd Bergmann , Tony Luck , Borislav Petkov , Andy Lutomirski , Bjorn Helgaas , Dan Williams , virtualization@lists.linux-found > 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. That concept exists too. There is a separate allow list for the drivers. So just adding shared to a driver is not enough, until it's also added to the allowlist Users can of course chose to disable the allowlist, but they need to understand the security implications. > > I would say an explicit flag in the driver that says "hardened" > and refusing to init a non hardened one would be better. We have that too (that's the device filtering) But the problem is that device filtering just stops the probe functions, not the initcalls, and lot of legacy drivers do MMIO interactions before going into probe. In some cases it's unavoidable because of the device doesn't have a separate enumeration mechanism it needs some kind of probing to even check for its existence And since we don't want to change all of them it's far safer to make the ioremap opt-in. -Andi