Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp992794pxp; Wed, 16 Mar 2022 23:45:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxNxu9eLNk3MhlXiDTLbDjIi6JukGxS73nliubiAWGkHcYpdT8NpYOZBlK+aBhwpztlyvUs X-Received: by 2002:a17:902:6b06:b0:14d:8b58:5432 with SMTP id o6-20020a1709026b0600b0014d8b585432mr3200780plk.75.1647499556249; Wed, 16 Mar 2022 23:45:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647499556; cv=none; d=google.com; s=arc-20160816; b=HDvRDWWQIs4f2KbUa93edAT7S5xy8TcbKm/9WiWQKWNIhq6QIs71aaGuUbGY35gq4f gD1UtTvGw1w1HUmRDB318ehp31YGf0aj6Big+QLfbfmjuYUDai1dYCOyj00g/87pk1RD CtG0seVeo0cdibGGnYK+1HsubEQU0crkybD+VK2HjhSZUz7Z0OXJWmH6XaZuQ2cAB3ZS V0OhogWgR73UNa2P6Ggoxsr9/LZOe/6W70G1qKiw1BtWDERIF5ydvtF1fVe1w/k9P3tP otAFtxsSdNZYSvxc1BcqjWs2SbyRwrwsNdYg68PfTCKU+mgSzruOvfMFKqFnD3yYjFN8 PDzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=hT7yDgMV8wImkt7pCins+j62p5gQNNyUJTWZIaj5EY8=; b=SGEyADw8WTIiPtzSQvWGZDvvlI/7Mo55aDVSbl9eGAAoieVBXlRkt4XcbZoPipQ7P/ 5JN1HayfDV4FmC9nbuA3CBF+D/9YRf8xBMpQSyNNOiIvaGHddwla8RLFBGivpdap7L+o zhkFvjxKiiJFytHiiSJbHYtBAAPIoUzGDgThTKe0powTZzx7EHWMd7n+8ki3KAtObFmr mB+3PoHNQ/LeRESOip0Lht/64p813WgYWRl8BFtuU/lUiNY1a5xlnstB4OhgRoswCyuu KBQqcRJunBXNRlOQDYxHT/A1yBqkYbfYyaC4uTnCAnaBB+Iu8NBIqgWTYocmrD7ONkQQ riUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=a+j6wr6Q; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id z10-20020a63b04a000000b003816043ee9bsi1174605pgo.144.2022.03.16.23.45.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Mar 2022 23:45:56 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=a+j6wr6Q; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4AB982DD9A9; Wed, 16 Mar 2022 22:30:49 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353894AbiCPGb0 (ORCPT + 99 others); Wed, 16 Mar 2022 02:31:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50074 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351336AbiCPGbY (ORCPT ); Wed, 16 Mar 2022 02:31:24 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 55D3D5A0AC; Tue, 15 Mar 2022 23:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1647412210; x=1678948210; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=s+JdLeo9XMuVFw/gFxTEj/scZqStb/MDbqCMBDStDII=; b=a+j6wr6QR8M+R46PVv2etzKd0pmjbyP8SFer1xBr+plXvuB59DLxxupt Nd77DNG0FZQ7PnlrHScLRoFr8b1k6bs+P2Cbhoy+BgPySJ8abEKUX7dXq q5IODDtye97MF2BXrPTd2DWTYCzbtVgQNsfxLAOBMnLH5nILDU8SG8Kqe DuJL+Z379kQWV517yic8BAiZjjjKmDMW7rtUhgZKqHX5lYXuNeAtSvhPP +3TNMhqTyvxT3FFxeeq0Vrz/npS1/5jLxfcyq0GKA8HX/BhH8NYKugRO6 cdnQTV03MEgg76BEW1PczHsS1JvVA3Awjq/AAVRD3NSZPTpQIoeS0WhF0 A==; X-IronPort-AV: E=McAfee;i="6200,9189,10286"; a="256456919" X-IronPort-AV: E=Sophos;i="5.90,185,1643702400"; d="scan'208";a="256456919" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2022 23:30:10 -0700 X-IronPort-AV: E=Sophos;i="5.90,185,1643702400"; d="scan'208";a="646526563" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.162]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2022 23:30:07 -0700 Received: by lahna (sSMTP sendmail emulation); Wed, 16 Mar 2022 08:30:04 +0200 Date: Wed, 16 Mar 2022 08:30:04 +0200 From: Mika Westerberg To: Mario Limonciello Cc: Andreas Noever , Michael Jamet , Yehezkel Bernat , "open list:THUNDERBOLT DRIVER" , open list Subject: Re: [RFC] thunderbolt: Automatically authorize PCIe tunnels when IOMMU is active Message-ID: References: <20220315213008.5357-1-mario.limonciello@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220315213008.5357-1-mario.limonciello@amd.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mario, On Tue, Mar 15, 2022 at 04:30:08PM -0500, Mario Limonciello wrote: > Historically TBT3 in Linux used "Thunderbolt security levels" as a primary > means of "security" against DMA attacks. This mean that users would need to > ack any device plugged in via userspace. In ~2018 machines started to use > the IOMMU for protection, but instead of dropping security levels a > convoluted flow was introduced: > * User hotplugs device > * Driver discovers supported tunnels > * Driver emits a uevent to userspace that a PCIe tunnel is present > * Userspace reads 'iommu_dma_protection' attribute (which currently > indicates an Intel IOMMU is present and was enabled pre-boot not that > it's active "now") > * Based on that value userspace then authorizes automatically or prompts > the user like how security level based support worked. There are legitimate reasons to disable PCIe tunneling even if the IOMMU bits are in place. The ACPI _OSC allows the boot firmware to do so and our "security levels" allows the userspace policy to do the same. I would not like to change that unless absolutely necessary.