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 4E406C433FE for ; Sun, 10 Oct 2021 22:22:48 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EA56360E05 for ; Sun, 10 Oct 2021 22:22:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org EA56360E05 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id A4389400E1; Sun, 10 Oct 2021 22:22:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuleoAuW7BoL; Sun, 10 Oct 2021 22:22:46 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp2.osuosl.org (Postfix) with ESMTPS id 69D9E401CE; Sun, 10 Oct 2021 22:22:45 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4CF90C000F; Sun, 10 Oct 2021 22:22:45 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7EE9DC000D for ; Sun, 10 Oct 2021 22:22:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 4D7DE4039D for ; Sun, 10 Oct 2021 22:22:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wACqmKBKSjYc for ; Sun, 10 Oct 2021 22:22:42 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by smtp4.osuosl.org (Postfix) with ESMTPS id 3AB474037E for ; Sun, 10 Oct 2021 22:22:42 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10133"; a="226667269" X-IronPort-AV: E=Sophos;i="5.85,363,1624345200"; d="scan'208";a="226667269" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Oct 2021 15:22:41 -0700 X-IronPort-AV: E=Sophos;i="5.85,363,1624345200"; d="scan'208";a="459751289" Received: from akleen-mobl1.amr.corp.intel.com (HELO [10.209.83.75]) ([10.209.83.75]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Oct 2021 15:22:40 -0700 Message-ID: Date: Sun, 10 Oct 2021 15:22:39 -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" , Kuppuswamy Sathyanarayanan References: <20211009003711.1390019-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20211009003711.1390019-13-sathyanarayanan.kuppuswamy@linux.intel.com> <20211009053103-mutt-send-email-mst@kernel.org> From: Andi Kleen In-Reply-To: <20211009053103-mutt-send-email-mst@kernel.org> Cc: Kuppuswamy Sathyanarayanan , Peter Zijlstra , linux-pci@vger.kernel.org, linux-mips@vger.kernel.org, James E J Bottomley , Dave Hansen , Peter H Anvin , sparclinux@vger.kernel.org, Thomas Gleixner , Andrea Arcangeli , Jonathan Corbet , Helge Deller , x86@kernel.org, Ingo Molnar , linux-arch@vger.kernel.org, Arnd Bergmann , Tony Luck , Borislav Petkov , Andy Lutomirski , Josh Poimboeuf , Bjorn Helgaas , Dan Williams , virtualization@lists.linux-foundation.org, Richard Henderson , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, Sean Christopherson , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, Paolo Bonzini , "David S . Miller" , Kirill Shutemov X-BeenThere: virtualization@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux virtualization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" > To which Andi replied > One problem with removing the ioremap opt-in is that > it's still possible for drivers to get at devices without going through probe. > > To which Greg replied: > https://lore.kernel.org/all/YVXBNJ431YIWwZdQ@kroah.com/ > If there are in-kernel PCI drivers that do not do this, they need to be > fixed today. > > Can you guys resolve the differences here? I addressed this in my other mail, but we may need more discussion. > > And once they are resolved, mention this in the commit log so > I don't get to re-read the series just to find out nothing > changed in this respect? > > I frankly do not believe we are anywhere near being able to harden > an arbitrary kernel config against attack. Why not? Device filter and the opt-ins together are a fairly strong mechanism. And it's not that they're a lot of code or super complicated either. You're essentially objecting to a single line change in your subsystem here. > 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, > Anyone deviating from that better know what they are doing, > this API tweaking is just putting policy into the kernel ... Hardening drivers is kernel policy. It cannot be done anywhere else. -Andi _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization