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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BBAB8C4332F for ; Mon, 11 Oct 2021 17:32:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A532460EBB for ; Mon, 11 Oct 2021 17:32:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231649AbhJKRe0 (ORCPT ); Mon, 11 Oct 2021 13:34:26 -0400 Received: from mga09.intel.com ([134.134.136.24]:18841 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229816AbhJKReZ (ORCPT ); Mon, 11 Oct 2021 13:34:25 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10134"; a="226828714" X-IronPort-AV: E=Sophos;i="5.85,365,1624345200"; d="scan'208";a="226828714" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Oct 2021 10:32:24 -0700 X-IronPort-AV: E=Sophos;i="5.85,365,1624345200"; d="scan'208";a="440884638" Received: from akleen-mobl1.amr.corp.intel.com (HELO [10.255.229.69]) ([10.255.229.69]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Oct 2021 10:32:23 -0700 Message-ID: <78766e28-8353-acc8-19e2-033d4bbf3472@linux.intel.com> Date: Mon, 11 Oct 2021 10:32:23 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH v5 12/16] PCI: Add pci_iomap_host_shared(), pci_iomap_host_shared_range() Content-Language: en-US To: "Michael S. Tsirkin" Cc: 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 , Paolo Bonzini , David Hildenbrand , Andrea Arcangeli , Josh Poimboeuf , 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: <20211009003711.1390019-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20211009003711.1390019-13-sathyanarayanan.kuppuswamy@linux.intel.com> <20211009053103-mutt-send-email-mst@kernel.org> <20211011073614-mutt-send-email-mst@kernel.org> From: Andi Kleen In-Reply-To: <20211011073614-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org > Because it does not end with I/O operations, that's a trivial example. > module unloading is famous for being racy: I just re-read that part of > virtio drivers and sure enough we have bugs there, this is after > they have presumably been audited, so a TDX guest is better off > just disabling hot-unplug completely, and hotplug isn't far behind. These all shouldn't matter for a confidential guest. The only way it can be attacked is through IO, everything else is protected by hardware. Also it would all require doing something at the guest level, which we assume is not malicious. > Malicious filesystems can exploit many linux systems unless > you take pains to limit what is mounted and how. That's expected to be handled by authenticated dmcrypt and similar. Hardening at this level has been done for many years. > Networking devices tend to get into the default namespaces and can > do more or less whatever CAP_NET_ADMIN can. > Etc. Networking should be already hardened, otherwise you would have much worse problems today. > hange in your subsystem here. > Well I commented on the API patch, not the virtio patch. > If it's a way for a driver to say "I am hardened > and audited" then I guess it should at least say so. This is handled by the central allow list. We intentionally didn't want each driver to declare itself, but have a central list where changes will get more scrutiny than random driver code. But then there are the additional opt-ins for the low level firewall. These are in the API. I don't see how it could be done at the driver level, unless you want to pass in a struct device everywhere? >>> How about creating a defconfig that makes sense for TDX then? >> TDX can be used in many different ways, I don't think a defconfig is >> practical. >> >> In theory you could do some Kconfig dependency (at the pain point of having >> separate kernel binariees), but why not just do it at run time then if you >> maintain the list anyways. That's much easier and saner for everyone. In the >> past we usually always ended up with runtime mechanism for similar things >> anyways. >> >> Also it turns out that the filter mechanisms are needed for some arch >> drivers which are not even configurable, so alone it's probably not enough, > > I guess they aren't really needed though right, or you won't try to > filter them? We're addressing most of them with the device filter for platform drivers. But since we cannot stop them doing ioremap IO in their init code they also need the low level firewall. Some others that cannot be addressed have explicit disables. > So make them configurable? Why not just fix the runtime? It's much saner for everyone. Proposing to do things at build time sounds like we're in Linux 0.99 days. -Andi