All of lore.kernel.org
 help / color / mirror / Atom feed
From: Solar Designer <solar@openwall.com>
To: kernel-hardening@lists.openwall.com
Subject: [kernel-hardening] Disable and lock Silicon Debug feature on modern Intel CPUs
Date: Sun, 22 Jan 2017 00:41:05 +0100	[thread overview]
Message-ID: <20170121234105.GA22967@openwall.com> (raw)

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

             reply	other threads:[~2017-01-21 23:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-21 23:41 Solar Designer [this message]
2017-01-22 15:10 ` [kernel-hardening] Disable and lock Silicon Debug feature on modern Intel CPUs Yves-Alexis Perez
2017-01-22 16:30 ` Mathias Krause
2017-01-22 20:31   ` Solar Designer
     [not found]     ` <20170122221847.GA97816@yamori.belopuhov.com>
2017-01-23 10:47       ` Mathias Krause

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170121234105.GA22967@openwall.com \
    --to=solar@openwall.com \
    --cc=kernel-hardening@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.