Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5204047imu; Tue, 13 Nov 2018 02:56:41 -0800 (PST) X-Google-Smtp-Source: AJdET5cMWn5JlHmMwAvTs+izTaPHF1QsRWSQhyvBe3pRH6x8kUSFkQh1B//2HqEToKXt5AgyHRmJ X-Received: by 2002:a65:434d:: with SMTP id k13mr4305640pgq.269.1542106601120; Tue, 13 Nov 2018 02:56:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542106601; cv=none; d=google.com; s=arc-20160816; b=ZBTxIGLgqb2jiQXHaanNLBSzBUuDXfrPDMpD86y0wcuO+xGTCuIaU/SbFUUblkDAnu GJfDpFJiQy56TNFsGKyblo/xcPc8ShBlfyywIDHltJKl3c53pq/QVBdy3/Fnxi4v7WoG ISBsWEziM6RafkQnzKwuGqglqNj0AVuNmTmDvnytoM5cuGy1naQVZ4YAByMO9IAKxUzR CnPMqp0dvFeuatvwYYy295K6oMaxg1fZ3snMzf/U4Z3a4H74ifAl+UVIx02qCMbKgfiE WNMyiABnNugkjVi0QpNJ8624UJlrk3eYJbtdjqyzMOuayPaiH9BLWOH5FptEY3nbNrSF qVbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:organization:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=vBhoZbku+Dg88hjRQi2g5pwvJGIczQvT7e5ZN37sgmI=; b=TPF7A/c7vI8ZGz86ASGjcOQcZXjAJO/2UFpQvTVbbuc1HQn+HG0ySnwzh68hRWxiQG Yv2e/8GehWZPqklcCzqd4dfMqdoC3BS7Ty1mCZZnRQDwYHIwzFsmk/UpEGrW8D+iSiMT dgHUwlFOXrcY5VGu/gPRvZy7QRBy2820llDK64FmqcxpeBtnW3xzaec1dcyV2VOKWSUa 1gaHPQ8OWhFYf4/+egJmij/RRTk+2v4tRx41KVj8wtYNkn4GMnuntktgvwYmul52PcLn R1a2H+lnZSxl4q98p/gZNXKq77+pAfRuxkDbJPTPSyAuq326YhoV/ZHUlGPQ00pxmfsE tWww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id a61-v6si22860785pla.430.2018.11.13.02.56.26; Tue, 13 Nov 2018 02:56:41 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1732390AbeKMUxi (ORCPT + 99 others); Tue, 13 Nov 2018 15:53:38 -0500 Received: from mga07.intel.com ([134.134.136.100]:58837 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726581AbeKMUxi (ORCPT ); Tue, 13 Nov 2018 15:53:38 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Nov 2018 02:56:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,498,1534834800"; d="scan'208";a="85450005" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.157]) by fmsmga007.fm.intel.com with SMTP; 13 Nov 2018 02:55:59 -0800 Received: by lahna (sSMTP sendmail emulation); Tue, 13 Nov 2018 12:55:58 +0200 Date: Tue, 13 Nov 2018 12:55:58 +0200 From: Mika Westerberg To: Yehezkel Bernat Cc: iommu@lists.linux-foundation.org, joro@8bytes.org, dwmw2@infradead.org, baolu.lu@linux.intel.com, ashok.raj@intel.com, bhelgaas@google.com, rjw@rjwysocki.net, jacob.jun.pan@intel.com, Andreas Noever , michael.jamet@intel.com, lukas@wunner.de, Christian Kellner , Mario Limonciello , Anthony Wong , linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, LKML Subject: Re: [PATCH 4/4] thunderbolt: Export IOMMU based DMA protection support to userspace Message-ID: <20181113105558.GR2500@lahna.fi.intel.com> References: <20181112160628.86620-1-mika.westerberg@linux.intel.com> <20181112160628.86620-5-mika.westerberg@linux.intel.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 Mon, Nov 12, 2018 at 06:59:02PM +0200, Yehezkel Bernat wrote: > On Mon, Nov 12, 2018 at 6:06 PM Mika Westerberg > wrote: > > > > Recent systems shipping with Windows 10 version 1803 or later may > > support a feature called Kernel DMA protection [1]. In practice this > > means that Thunderbolt connected devices are placed behind an IOMMU > > during the whole time it is connected (including during boot) making > > Thunderbolt security levels redundant. Some of these systems still have > > Thunderbolt security level set to "user" in order to support OS > > downgrade (the older version of the OS might not support IOMMU based DMA > > protection so connecting a device still relies on user approval then). > > > > Export this information to userspace by introducing a new sysfs > > attribute (iommu_dma_protection). Based on it userspace tools can make > > more accurate decision whether or not authorize the connected device. > > > > In addition update Thunderbolt documentation regarding IOMMU based DMA > > protection. > > > > [1] https://docs.microsoft.com/en-us/windows/security/information-protection/kernel-dma-protection-for-thunderbolt > > > > Signed-off-by: Mika Westerberg > > --- > > I can't comment on the IOMMU side, but the Thunderbolt side looks good to me. Thanks! > Just one point: > Have you considered the option to add this property per (TBT?) device? No. ;-) You mean that one device uses security levels and another IOMMU? I don't think it is possible without having some sort of table in the IOMMU driver telling which devices it needs identity map and which not. Also not sure what would be the benefit? > If the kernel may decide to enable/disable the IOMMU or AST per device, maybe > it should be on this level. > Or maybe the IOMMU decision isn't going to change (it's system-wide) and the AST > decision will be communicated per device by a new sysfs attribute anyway, if > needed? Not sure what you mean by "AST"? The IOMMU decision is pretty much system-wide.