From patchwork Mon Nov 12 16:06:24 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mika Westerberg X-Patchwork-Id: 10678929 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 7C860139B for ; Mon, 12 Nov 2018 16:06:35 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6CED82913D for ; Mon, 12 Nov 2018 16:06:35 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5E39629C24; Mon, 12 Nov 2018 16:06:35 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 05AE82913D for ; Mon, 12 Nov 2018 16:06:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729633AbeKMCAZ (ORCPT ); Mon, 12 Nov 2018 21:00:25 -0500 Received: from mga11.intel.com ([192.55.52.93]:52069 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728103AbeKMCAZ (ORCPT ); Mon, 12 Nov 2018 21:00:25 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2018 08:06:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,495,1534834800"; d="scan'208";a="105580985" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga004.fm.intel.com with ESMTP; 12 Nov 2018 08:06:29 -0800 Received: by black.fi.intel.com (Postfix, from userid 1001) id 59EFA3EA; Mon, 12 Nov 2018 18:06:28 +0200 (EET) From: Mika Westerberg To: iommu@lists.linux-foundation.org Cc: Joerg Roedel , David Woodhouse , Lu Baolu , Ashok Raj , Bjorn Helgaas , "Rafael J. Wysocki" , Jacob jun Pan , Andreas Noever , Michael Jamet , Yehezkel Bernat , Lukas Wunner , Christian Kellner , Mario.Limonciello@dell.com, Anthony Wong , Mika Westerberg , linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/4] PCI / iommu / thunderbolt: IOMMU based DMA protection Date: Mon, 12 Nov 2018 19:06:24 +0300 Message-Id: <20181112160628.86620-1-mika.westerberg@linux.intel.com> X-Mailer: git-send-email 2.19.1 MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi all, Recent systems shipping with Windows 10 version 1803 or newer may be utilizing IOMMU to prevent DMA attacks via Thunderbolt ports. This is different from the previous security level based scheme because the connected device cannot access system memory outside of the regions allocated for it by the driver. When enabled the BIOS makes sure no device can do DMA outside of RMRR (Reserved Memory Region Record) regions. This means that during OS boot, before it enables IOMMU, none of the connected devices can bypass DMA protection for instance by overwriting the data structures used by the IOMMU. The BIOS communicates support for this to the OS by setting a new bit in ACPI DMAR table [1]. Because these systems utilize an IOMMU to block possible DMA attacks, typically (but not always) the Thunderbolt security level is set to "none" which means that all PCIe devices are immediately usable. This also means that Linux needs to follow Windows 10 and enable IOMMU automatically when running on such system otherwise connected devices can read/write system memory pretty much without any restrictions. Since there is a way to identify PCIe root ports that are "external facing" we can put all internal devices to pass through (identity mapping) mode and only external devices need to go through full IOMMU mappings. We also make sure PCIe ATS (Address Translation Service) is not enabled for external devices because it could be used to bypass IOMMU completely as explained in the changelog of patch 3/4. Finally we expose this information to userspace so tools such as bolt can do more accurate decision whether or not authorize the connected device. [1] https://software.intel.com/sites/default/files/managed/c5/15/vt-directed-io-spec.pdf Lu Baolu (1): iommu/vt-d: Force IOMMU on for platform opt in hint Mika Westerberg (3): PCI / ACPI: Identify external PCI devices iommu/vt-d: Do not enable ATS for external devices thunderbolt: Export IOMMU based DMA protection support to userspace .../ABI/testing/sysfs-bus-thunderbolt | 9 +++ Documentation/admin-guide/thunderbolt.rst | 23 ++++++++ drivers/acpi/property.c | 3 + drivers/iommu/dmar.c | 25 ++++++++ drivers/iommu/intel-iommu.c | 58 ++++++++++++++++++- drivers/pci/pci-acpi.c | 13 +++++ drivers/pci/probe.c | 23 ++++++++ drivers/thunderbolt/domain.c | 17 ++++++ include/linux/dmar.h | 8 +++ include/linux/pci.h | 1 + 10 files changed, 177 insertions(+), 3 deletions(-)