Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1007781pxb; Sun, 10 Oct 2021 17:53:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzxB9txDZMXGvBTqU8fIcMPMqZjFTOmlxLoW9UXCtoDDWpFFsSl28BxX7zTRjJ7PA18LuqV X-Received: by 2002:a50:e044:: with SMTP id g4mr36457822edl.46.1633913602451; Sun, 10 Oct 2021 17:53:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633913602; cv=none; d=google.com; s=arc-20160816; b=nOxIuPYLaq2PdWG7EcjcTIh4dXkXvA9SAq+XkIzrJm/K/2qZSJ65uc4SEzaKDXV4uZ lESYv82zgLGyGiZKVQ8RIO3/f9cLVEeT015m1YzEgNbX0wKK/9Hqsn95kp5xgokdRc0X j+1wf86iIrjJjp2WmEPnOwoRWMN2jDak8pxmQzgQ/duq7DaxonwKd+AQalcz11iIc6Kk SCCmc34gDm5XiDNm++Yfoj5Od21wkm0JNFXGClsjv6pfRpkRtF0GAmHIanPrFie/D/1J qxdOd8n2Dpu5sILJXjd2ohlWin029Is8CNdfyWXpwH9RIulrXeuOZCGAVIm7l98fZ1zW ALKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=eJETdAPcYmuNP13QZgmR5AW7SkdOOzgCzC2lySQjHxc=; b=OemIXay3U93iMsS4P+xsSqHv8LTjwlngragvla2pzyxOPh6/dLzy7x6f024dUxj56d XvfrOsBjK31M5n8qXIeL2GkpH90qjgSO3lAWH3ZX3lyuFUxsVYb7wAp7ujneiN64DvHs GYI0COS0QX9UVbx9McIVD857/9daAvRJn5aLse6JPg3/Eli40Wm29fME35LSun2e3SBJ gmyWXiEIBo4A5FSfy3TPdpKIAK6QQvMAjwhx715xl3kcOaAZBaxxOip8OjKnDGRTP5xe QIspdq4JCcP0wj26OWSFudCHkTPbRobb5L00phSCInMrHHP0GHBvaspRJm2i00vtfU2a T12A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id au8si8674833ejc.494.2021.10.10.17.52.59; Sun, 10 Oct 2021 17:53:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232955AbhJJWYn (ORCPT + 99 others); Sun, 10 Oct 2021 18:24:43 -0400 Received: from mga03.intel.com ([134.134.136.65]:64334 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231136AbhJJWYk (ORCPT ); Sun, 10 Oct 2021 18:24:40 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10133"; a="226725291" X-IronPort-AV: E=Sophos;i="5.85,363,1624345200"; d="scan'208";a="226725291" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.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 Cc: 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> From: Andi Kleen In-Reply-To: <20211009053103-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-kernel@vger.kernel.org > 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