From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A324BC4320A for ; Sun, 29 Aug 2021 16:43:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8F26460F23 for ; Sun, 29 Aug 2021 16:43:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235642AbhH2QoP (ORCPT ); Sun, 29 Aug 2021 12:44:15 -0400 Received: from mga03.intel.com ([134.134.136.65]:32683 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229687AbhH2QoJ (ORCPT ); Sun, 29 Aug 2021 12:44:09 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10091"; a="218207569" X-IronPort-AV: E=Sophos;i="5.84,361,1620716400"; d="scan'208";a="218207569" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Aug 2021 09:43:16 -0700 X-IronPort-AV: E=Sophos;i="5.84,361,1620716400"; d="scan'208";a="509322544" Received: from akleen-mobl1.amr.corp.intel.com (HELO [10.212.238.58]) ([10.212.238.58]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Aug 2021 09:43:15 -0700 Subject: Re: [PATCH v4 11/15] pci: Add pci_iomap_shared{,_range} To: "Michael S. Tsirkin" Cc: Christoph Hellwig , "Kuppuswamy, Sathyanarayanan" , 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 , Dan Williams , 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 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> <2747d96f-5063-7c63-5a47-16ea299fa195@linux.intel.com> <20210829113023-mutt-send-email-mst@kernel.org> From: Andi Kleen Message-ID: <82e133af-6ad4-6910-8b1a-3f9e1a42a0fa@linux.intel.com> Date: Sun, 29 Aug 2021 09:43:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20210829113023-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > All this makes sense but ioremap is such a random place to declare > driver has been audited, and it's baked into the binary with no way for > userspace to set policy. > > Again all we will end up with is gradual replacement of all ioremap > calls with ioremap_shared as people discover a given driver does not > work in a VM. No the device filter will prevent that. They would need to submit patches to the central list. Or they can override it at the command line, but there is already an option to force all ioremaps to be shared. So if you just want some driver to run without caring about security you can already do that without modifying it. Besides the shared concept only makes sense for virtual devices, so if you don't have a device model for a device this will never happen either. So I don't think your scenario of all ioremaps becoming shared will ever happen. > How are you going to know driver has actually been > audited? what the quality of the audit was? did the people doing the > auditing understand what they are auditing for? No way, right? First the primary purpose of the ioremap policy is to avoid messing with all the legacy drivers (which is 99+% of the code base) How to handle someone maliciously submitting a driver to the kernel is a completely different problem. To some degree there is trust of course. If someone says they audited and a maintainer trusts them with their statement, but they actually didn't there is a problem, but it's larger than just TDX. But in such a case the community code audit will also focus on such areas, and people interested in confidential computing security will also start taking a look. And we're also working on fuzzing, so these drivers will be fuzzed at some point, so mistakes will be eventually found. But in any case the ioremap policy is mainly to prevent having to handle this for all legacy drivers. I would rather change the few drivers that are actually needed, than all the other drivers. That's really the fundamental problem this is addressing: how to get reasonable security with all the legacy drivers out of the box without touching them. -Andi