Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 22 Jan 2017 17:30:11 +0100
From: Mathias Krause <>
To: Solar Designer <>
Subject: Re: Disable and lock Silicon Debug feature on
 modern Intel CPUs

On 22 January 2017 at 00:41, Solar Designer <> wrote:
> OpenBSD just got this a week ago:
> "Disable and lock Silicon Debug feature on modern Intel CPUs
> This implements one of the countermeasures against using Direct
> Connect Interface (DCI) to debug CPUs via USB3 mentioned in the
> "Tapping into the core" talk at the 33c3: identify and disable
> the Silicon Debug feature found in Haswell and newer CPUs."

This patch makes no sense whatsoever as the precondition -- the lock
bit still being 0 -- cannot be true on any effected system. That's
because *every* firmware theses days (EFI/UEFI/coreboot/...) installs
a SMI handler and tries to protect the SMRAM from long know attacks by
relocating it from its default location to ASEG/TSEG/you-name-it (see,
e.g., SDM chapter 34.11 SMBASE Relocation). That, however, requires
generating a SMI as the registers for relocation (SMBASE resp.
MSR_SMM_FEATURE_CONTROL,...) are only accessible/writable while in
SMM. So, getting back to the patch, that early "relocation SMI" will,
as documented, implicitly set the lock bit of the IA32_DEBUG_INTERFACE
MSR which makes any attempt to disable SDBG later on useless. So, for
me, this patch is just snake oil.

The only thing that MSR can be made use of is reporting; to tell the
user if SBDG was used by testing the "Debug Occurred" bit. That's the
reason why I just added the CPUID flag in and no follow-up
patch to disable SDBG.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.