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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=unavailable 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 CEA73C04EBF for ; Thu, 15 Nov 2018 19:10:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9FD6920815 for ; Thu, 15 Nov 2018 19:10:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9FD6920815 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388911AbeKPFTh (ORCPT ); Fri, 16 Nov 2018 00:19:37 -0500 Received: from mga09.intel.com ([134.134.136.24]:23686 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725742AbeKPFTg (ORCPT ); Fri, 16 Nov 2018 00:19:36 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2018 11:10:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,237,1539673200"; d="scan'208";a="108431466" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.157]) by fmsmga001.fm.intel.com with SMTP; 15 Nov 2018 11:10:27 -0800 Received: by lahna (sSMTP sendmail emulation); Thu, 15 Nov 2018 21:10:26 +0200 Date: Thu, 15 Nov 2018 21:10:26 +0200 From: Mika Westerberg To: Yehezkel Bernat Cc: lorenzo.pieralisi@arm.com, lukas@wunner.de, iommu@lists.linux-foundation.org, joro@8bytes.org, David Woodhouse , baolu.lu@linux.intel.com, ashok.raj@intel.com, Bjorn Helgaas , rjw@rjwysocki.net, jacob.jun.pan@intel.com, Andreas Noever , michael.jamet@intel.com, Christian Kellner , Mario Limonciello , Anthony Wong , linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, LKML Subject: Re: [PATCH 1/4] PCI / ACPI: Identify external PCI devices Message-ID: <20181115191026.GE4179@lahna.fi.intel.com> References: <20181113105636.GB11202@e107981-ln.cambridge.arm.com> <20181113112700.GT2500@lahna.fi.intel.com> <20181113114527.GA12821@e107981-ln.cambridge.arm.com> <20181115102239.GU2500@lahna.fi.intel.com> <20181115111356.GA599@e107981-ln.cambridge.arm.com> <20181115113737.GW2500@lahna.fi.intel.com> <20181115120736.pscly6zwd3k2tvd2@wunner.de> <20181115121627.GA2500@lahna.fi.intel.com> <20181115174608.GA17691@e107981-ln.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 15, 2018 at 07:58:13PM +0200, Yehezkel Bernat wrote: > From what I know, there are more devices that suffer from similar security > issues like Thunderbolt, e.g. FireWire [1]. > My assumption is that the same protection may be applied to such devices too, > even if currently it sounds like vendors care mostly about Thunderbolt (probably > because it removes the need for user approval for device connection; it becames > a simple plug-and-play experience). FireWire is kind of different but there are connectors such as ExpressCard and NVMe (over U.2 connector) which carry PCIe and are relatively easy to access without need for a screwdriver. AFAIK some eGPUs are also using some other proprietary (non-TBT) connector that carries PCIe. I was thinking we could cover all these with is_external filling them based on the _DSD or some other means in the kernel. We would then deal all such devices as "untrusted" by default. > Thus, I don't think binding it with dev->is_thunderbolt is the correct > thing to do. One option that I suggested already is that we keep both and mark all is_thunderbolt devices as is_external as well. But I guess this is up to Bjorn and Rafael to decide :-)