[kernel-hardening] Disable and lock Silicon Debug feature on modern Intel CPUs

[kernel-hardening] Disable and lock Silicon Debug feature on modern Intel CPUs

[Solar Designer]

Hi,

If anyone is looking for a tiny kernel hardening task, this may be one.

OpenBSD just got this a week ago:

https://freshbsd.org/commit/openbsd/f16aad7b540921691f7841ef8ccbb7e7ca22dfd1

"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."

(and I stole the first line of the commit message for this message's
Subject - well, at least I do it with this attribution).

Silicon Debug should probably be disabled and locked by default, but
there should be a kernel parameter to avoid this.

The rationale to do this is to provide a tiny bit of protection against
some physical attacks on booted up and decrypted yet locked laptops,
while also allowing the system owner's intentional use of Silicon Debug.

As far as I can tell, so far Linux only got the CPUID feature bit:

http://lists.openwall.net/linux-kernel/2015/07/19/228

and presumably reporting due to arch/x86/kernel/cpu/mkcapflags.sh.

FreeBSD and NetBSD also seem to have just a check for the bit and
its reporting, also since 2015.

Alexander

Re: [kernel-hardening] Disable and lock Silicon Debug feature on modern Intel CPUs

[Yves-Alexis Perez]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

On Sun, 2017-01-22 at 00:41 +0100, Solar Designer wrote:
> Silicon Debug should probably be disabled and locked by default, but
> there should be a kernel parameter to avoid this.

Hi, I intended to take a look but (un)fortunately it seems that my laptop
(ThinkPad X250) has it locked disabled (I guess by Lenovo BIOS).

I can still work on a patch but it'll be untested. Does one know of unlocked
platforms?

For reference, here's how to determine your situation:

cpuid tools (version20161201) doesn't support the SDBG bit but you can display
the raw value:

cpuid -r -1 -l 1  | awk '/ecx=/ { print $5 }'
ecx=0x7ffafbbf

SDBG is bit 11, set here (Broadwell).

Looking at the IA32_DEBUG_INTERFACE (0xc80) MSR reveals its status:

rdmsr 0xc80
40000000

with:

IA32_DEBUG_INTERFACE_ENABLE	0x00000001
IA32_DEBUG_INTERFACE_LOCK	0x40000000
IA32_DEBUG_INTERFACE_MASK	0x80000000

So in my case it's not enabled, and it's locked.

Regards,
-- 
Yves-Alexis

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [kernel-hardening] Disable and lock Silicon Debug feature on modern Intel CPUs

[Mathias Krause]

On 22 January 2017 at 00:41, Solar Designer <solar@openwall.com> wrote:
> OpenBSD just got this a week ago:
>
> https://freshbsd.org/commit/openbsd/f16aad7b540921691f7841ef8ccbb7e7ca22dfd1
>
> "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.
IA32_SMRR_PHYSBASE and IA32_SMRR_PHYSMASK,
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
http://lists.openwall.net/linux-kernel/2015/07/19/228 and no follow-up
patch to disable SDBG.


Cheers,
Mathias

Re: [kernel-hardening] Disable and lock Silicon Debug feature on modern Intel CPUs

[Solar Designer]

On Sun, Jan 22, 2017 at 05:30:11PM +0100, Mathias Krause wrote:
> On 22 January 2017 at 00:41, Solar Designer <solar@openwall.com> wrote:
> > OpenBSD just got this a week ago:
> >
> > https://freshbsd.org/commit/openbsd/f16aad7b540921691f7841ef8ccbb7e7ca22dfd1
> >
> > "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.
> IA32_SMRR_PHYSBASE and IA32_SMRR_PHYSMASK,
> 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
> http://lists.openwall.net/linux-kernel/2015/07/19/228 and no follow-up
> patch to disable SDBG.

Thanks for explaining this, Mathias.  When I saw your name on the 2015
LKML posting above, I thought there could be a reason behind not doing
anything else about this; I should have worded my posting accordingly.

I am now CC'ing Mike who made the OpenBSD commit, just to make sure he's
aware of this reasoning and so that he can possibly weigh in, if he has
anything to add - e.g., was OpenBSD's change tested on any laptop and
shown to make a difference?  Meanwhile, I withdraw my earlier suggestion
for Linux to do anything else about this issue.

Alexander

Re: [kernel-hardening] Disable and lock Silicon Debug feature on modern Intel CPUs

[Mathias Krause]

[Re-adding kernel-hardening mailing list to Cc -- nothing to hide]

On 22 January 2017 at 23:18, Mike Belopuhov <mike@belopuhov.com> wrote:
> Thanks for bringing this to my attention, it's a pity this kind of
> discussion doesn't happen on the openbsd tech mailing list where I've
> posted the diff and asked for reviews, but no matter.

I'm not on that list, nor am I an OpenBSD user.

> I'll have to double check this information regarding whether or not
> it's possible to manipulate the Silicon Debug Enabled bit in the MSR
> after the OS is booted.  If my memory serves, there were no provisions
> in the description of the MSR itself.

The description of the IA32_DEBUG_INTERFACE MSR, bit 30 reads as follows:

"""
Lock (R/W): If 1, locks any further change
to the MSR. The lock bit is set automatically
on the first SMI assertion even if not
explicitly set by BIOS. Default is 0.
"""

Please notice the "set automatically on the first SMI" part.

> I would also like to know what
> the statement regarding "*every* firmware" is based on?  If such
> mechanism is optional we should not (IMO) make any strong assumptions
> regarding availability of broken firmware images.

The problem is, the reset state of the SMBASE register is 0x30000 --
not only on the BSP but on every AP as well. This creates a problem
for systems with more than a single core as SMIs may be served
simultaneously by multiple cores. The SMI specific register safe and
restore mechanism (see SDM chapter 34.4.1 SMRAM State Save Map) would
trash each others CPU register state if the SMBASE would be the same
on each of the cores. Therefore the firmware needs to reserve a
core-specific dedicated memory location for the SMI register save
state area. This, OTOH, requires writing to registers only available /
accessible in SMM on that specific core, thereby fulfilling the "on
the first SMI" condition of the lock bit of MSR
IA32_DEBUG_INTERFACE... So if that lock bit isn't set on a system,
it's messed up in so many ways, no need to care about SDBG ;)  Oh, and
no, the MSR doesn't get reset on #INIT (see SDM chapter 9.1.1
Processor State After Reset).

> The important part of the diff (which doesn't really cost us anything
> btw) is reporting the hardware that has Silicon Debug enabled and
> locked.

The reporting part is nice, actually.

> This would deter me from purchasing it and it should deter
> users as well.  Currently we're not aware of any hardware vendor who
> have released such hardware, but it's something the time will tell

IIRC the value depends on a PCH boot strap setting, so a firmware
update (or malicious user messing with the flash) may enable SDBG on a
system where it was disabled before. I might remember that one wrong,
though, so take it with a grain of salt... :/

> (CCC talk mentions that Skylake is the first platform that can make
> use of this anyways).

It was introduced with Haswell, actually.

> Unfortunately the OpenBSD dmesg collection [that would be the source
> of such information] is private and is accessible by active OpenBSD
> developers only, so there won't be any public release of such data
> unless it would be specifically organised.

For that to be slightly more useful (and to prove your point, that the
code can, in fact, make some systems More Secure(TM)), it would be
nice to have an additional message when the code succeeded in
disabling SDBG. However, as explained above, I don't think this code
path will ever be executed so...

Cheers,
Mathias

>
> With kind regards,
> Mike