You are on page 1of 5

NATIVE OS SECURITY FOR THUNDERBOLT™ 3

INTRODUCTION

Some bus types (e.g. PCI, Thunderbolt™3, ExpressCard, 1394, …) support Direct Memory Access (DMA). DMA-
enabled buses can directly read and write to arbitrary physical memory addresses (i.e. all of RAM). While this
facilitates performance, it introduces security concerns as it can provide maliciously-constructed or compromised
devices with the ability to read system secrets or modify system code & data. So-called “DMA attacks” were
popularized in 2004 but faded in recent times as DMA-capable external ports disappeared from laptops with the
rise of USB. With the increasing popularity of Thunderbolt™ 3 hosts and peripherals, industry experts are exploring

l
new possible physical DMA attack vectors via these ports.

M 18 D s ia
8 6- r N er nt
Beginning in 2013, Intel added incremental capabilities to Thunderbolt technology to reduce DMA exposure. When
the host is properly configured with these capabilities, an end user would have to first approve the Thunderbolt

01 2-0 nde artn fide


peripheral when initially attached to the port, approved as either “Connect Only Once” or “Connect Always”.
Although this methodology mitigates most Physical DMA attacks from un-authorized Thunderbolt devices, if a

A
© 2 0 u P on
Thunderbolt device with a PCIe slot is approved as “Connect Always”, a physical “DMA attack” might still be
possible given the correct hardware and physical access to a previously approved Thunderbolt device with PCIe
ed P C

expandability (e.g. PCIe slot, ExpressCard). Although the “Connect Only Once” does provide additional mitigation
from such attacks, it places an unwelcome burden on the end user who would be required to approve the device

t
ar EA oft

of
every time it’s connected.
os
Sh r E os

In the Windows 10 RS4 release, Microsoft will introduce a native OS solution for protecting PCs against drive-by
icr
DMA attacks via Thunderbolt™ 3 enabled ports. “Drive-by” DMA attacks are attacks that can be performed in less
Fo icr

the 10 minutes, with off-the-shelf equipment costing less than $1,000, that do not require disassembly of the PC
chassis. Without protection, a drive-by DMA attacker could dump or overwrite the entire memory of the system,
M

inject malware, or even short-circuit the login algorithm to gain full access to the PC being attacked.
I:

This native OS security solution will only be available for new systems that ship with RS4 or later, as it requires
HB

changes in the system firmware/BIOS, described in the Platform and BIOS Requirements section below.

Please submit feedback for this document using Microsoft Collaborate/SysDev.

THREAT MODEL

The threat model for DMA attacks currently focuses on readily-available, externally accessible ports on systems
that are not physically secured. The attacker is expected to have a malicious device – it could spoof any hardware
ID, generate arbitrary bus cycles, ignores its own control registers (e.g. PCI BusMasterEnable, 1394
PhysicalRequestFilters, etc.).

Internal ports that require opening the case, revealing other hardware such as RAM, flash, or storage media, are
not in scope. Access to these components by a persistent, motivated attacker with physical access exposes a
sophisticated attack surface whose protection is not addressed here. Future OS releases may expand the scope of
DMA protection.

THUNDERBOLT™ 3 OS SECURITY OVERVIEW

MICROSOFT CONFIDENTIAL
The native OS security for Thunderbolt™ 3 hosts/PCs will rely on the system IOMMU to prevent drive-by DMA
attacks. Using the system IOMMU will help the OS:

1. Block all newly attached Thunderbolt™ 3 devices from starting and performing DMA, until an authorized
user is logged in and the screen is unlocked.
2. Sandbox memory allocated to DMA remapping (DMAr) compatible device drivers, thus allowing the OS to
enumerate and start DMAr compatible devices regardless of the lock screen state (i.e. Plug and use
immediately), which significantly improves user experience and enhances the overall system security.

This feature will only be available for Intel x64 platforms in RS4. Future OS releases will support additional
platforms.

l
M 18 D s ia
EXPERIENCE

8 6- r N er nt
The native OS security solution for Thunderbolt™ 3 hosts/PCs will reduce the user required interaction to

01 2-0 nde artn fide


enumerate newly connected Thunderbolt™ 3 devices, thus bringing the overall experience one step closer to the
USB experience. This OS native support will replace the existing Intel Thunderbolt™ 3 Security mechanism, which

A
requires users to approve newly attached devices via UI popups, starting Windows 10 RS4.
© 2 0 u P on
The following diagram illustrates the flow of enumerating and starting of an attached Thunderbolt™ 3 peripheral:
ed P C

t
ar EA oft

of
Wait for user
Peripheral User logged in
to login/
Connect peripheral Drivers opted- No AND Screen No
os in DMAr? unlocked?
unlock
Sh r E os

screen
icr
Fo icr

Yes

Yes
M

Enable DMAr for


the peripherals
I:
HB

New devices are


enumerated and
functioning

User OS

PLATFORM AND BIOS REQUIREMENTS

The Platform/BIOS MUST do the following to allow the OS secure against drive-by attacks via Thunderbolt™ 3
ports:

1. By default, System firmware must enable OS control of PCI Express & DMA Protection for Thunderbolt™ 3
technology:
a. Enable Native PCI Express Support for Thunderbolt™ 3 technology (See the appropriate
Thunderbolt BIOS Implementation Guide for the targeted platform*).
b. Enable Intel Virtualization technology for Direct I/O (VT-d).
c. Set Intel legacy Thunderbolt™ 3 Security Level to SL0 (No Security Mode).

MICROSOFT CONFIDENTIAL
2. System firmware must protect against pre-boot DMA attacks by either:
a. Clearing Bus Master Enable (BME) bit for all PCI root ports above Thunderbolt™ 3 hierarchies
from system power on through ExitBootServices().
b. Implementing DMA isolation of all Thunderbolt™ 3 IO buffers pre-ExitBootServices() (See the
appropriate Thunderbolt BIOS Implementation Guide for the targeted platform).
3. At ExitBootServices(), clear the BME bit for all PCIe root ports above a Thunderbolt™ 3 hierarchy, if
already enabled due to implementing item 2.b above.
4. At ExitBootServices(), restore IOMMU to power ON state (See the appropriate Thunderbolt BIOS
Implementation Guide for the targeted platform).
5. No device may perform DMA outside of RMRR regions after ExitBootServices() until the devices’
respective OS drivers are loaded and started by PnP, and Set DMA_CTRL_PLATFORM_OPT_IN_FLAG in

l
M 18 D s ia
DMAR table flags field (Intel Virtualization Technology for Direct I/O Spec, Rev 2.5 Section 8.1).

8 6- r N er nt
6. DMAR tables must not include ACPI Namespace Device Descriptors (ANDD) structures.
7. Implement _DSD for Thunderbolt™ 3 PCIe root ports (Appendix A).

01 2-0 nde artn fide


8. Make TPM measurements as described in Appendix B below.

*For access to the appropriate Thunderbolt BIOS Implementation Guide for the targeted platform, please contact

A
© 2 0 u P on
your Intel Representative.
ed P C

DRIVER REQUIREMENTS

t
ar EA oft

of
For PCI Thunderbolt™ 3 devices that are required to function pre-user login or screen unlock, the device driver
os
MUST be DMAr compatible and MUST opt-into DMAr*.
Sh r E os

To be DMAr compatible and to opt-into DMAr, the device driver MUST:


icr
Fo icr

1. Only perform DMA using the Microsoft standard DMA interfaces:


M

a. WDF Drivers: https://msdn.microsoft.com/en-us/library/windows/hardware/dn265634(v=vs.85).aspx


b. NDIS Drivers: https://msdn.microsoft.com/en-us/library/windows/hardware/ff565431(v=vs.85).aspx
I:

c. WDM Drivers (excluding Graphics): https://msdn.microsoft.com/en-


HB

us/library/windows/hardware/ff544058(v=vs.85).aspx
2. Opt-into DMAr using the following INF directive:

[MyServiceInstall_AddReg]
HKR,Parameters,DmaRemappingCompatible,0x00010001,1

;1 = opt-in, 2 = opt-in only for external devices

3. Enable driver verifier with all standard settings when testing the driver
a. Under driver verifier (for testing purposes), the INF directive #2, opt-in for external devices, is
promoted to INF directive #1, opt-in.
4. Fully test driver functionality on an Intel x64 system, with VT-d enabled, using the latest Windows 10 RS4
build

*DMA remapping is not supported for Graphics devices and drivers in Windows 10 RS4.

FREQUENTLY ASKED QUESTIONS

MICROSOFT CONFIDENTIAL
 What is the expected behavior of DMAr incompatible devices?
DMAr incompatible devices will be blocked from starting if the device(s) was plugged in before an
authorized user logs in, or while the screen is locked. Once the system is unlocked, the device driver will
be started by the OS, and the device will continue to function normally until the system is rebooted, or
the device is unplugged. The devices will continue to function normally, if the user locks the screen or logs
out of the system.

 Do in-market systems support the Native OS Security for Thunderbolt™ 3?


In market systems, released with Windows 10 1709 or earlier will not support Native OS Security for

l
M 18 D s ia
Thunderbolt™ 3 after upgrading to RS4, as this feature require the BIOS/platform firmware changes and

8 6- r N er nt
guarantees, as described above in the Platform and BIOS Requirements section.

01 2-0 nde artn fide


 Would I be able to boot from Thunderbolt™ 3 devices with the Native OS
Security?

A
© 2 0 u P on
Yes, booting for Thunderbolt™ 3 devices is supported (e.g. PXE Boot), if item 2.b in the Platform and BIOS
ed P C

Requirements is implemented. Installing Windows 10 on the external media and using that as the system

t
drive is not supported.
ar EA oft

of
os
Sh r E os

icr
Fo icr
M
I:
HB

MICROSOFT CONFIDENTIAL
APPENDIX A (_DSD BIOS IMPLEMENTATION)

Method(_DSD, 0)
{
Return (Package () {
ToUUID("6211E2C0-58A3-4AF3-90E1-927A4E0C55A4"),
Package () {

l
M 18 D s ia
Package (2) {"HotPlugSupportInD3", 1},

8 6- r N er nt
}, //Advertise that hierarchy below root port supports D3Cold

01 2-0 nde artn fide


ToUUID("EFCC06CC-73AC-4BC3-BFF0-76143807C389"),
Package () {

A
© 2 0 u P on
Package (2) {"ExternalFacingPort", 1}, // Property 1: This is a
Thunderbolt™3 port
ed P C

Package (2) {"UID", 0}, // Property 2: UID of the TBT RP on platform,

t
ar EA oft

of
range is: 0, 1, …, NumOfTBTRP – 1
} //Advertise that the port is an externally exposed port (e.g.
os
Sh r E os

Thunderbolt™3)
icr
})
Fo icr

}
M

Implementation notes:


I:

For systems with a single Thunderbolt™ 3 PCIe Root Port, “UID” should be set to 0

HB

For systems with multiple Thunderbolt™ 3 PCIe Root Ports, duplicate the _DSD method for each Root Port
and increment the “UID” by 1, starting from 0.

APPENDIX B (TPM MEASUREMENTS)


If the firmware/BIOS has an option to enable and disable DMA protections via a VT-d switch in BIOS options, then
the shipping configuration must be with VT-d protection enabled. On every boot where VT-d/DMA protection is
disabled, or will be disabled, or configured to a lower security state, and a platform has a TPM enabled, then the
platform SHALL extend an EV_EFI_ACTION event into PCR[7] before enabling external DMA. The event string SHALL
be “DMA Protection Disabled”. The platform firmware MUST log this measurement in the event log using the
string “DMA Protection Disabled” for the Event Data.

MICROSOFT CONFIDENTIAL

You might also like