Repository :
http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git
On branch : master
---------------------------------------------------------------
commit e223e06ed3b7ee2ac3d93ab7ab9d919985e301c8
Author: Peter Jones <pjones(a)redhat.com>
Date: Wed Feb 27 16:47:24 2013 -0500
Provide a specific, itemized list of functionality we've disabled.
Don't be vague about what's disabled and what might happen in some
distopic future. Provide a list of what's disabled, and a note about
systemtap to go with it (since it's not disabled, but does require some
workflow changes at this time.)
This needs complementary documentation of the tools it references,
including: mokutil, shim, MokManager, efikeygen.
Signed-off-by: Peter Jones <pjones(a)redhat.com>
Signed-off-by: Eric Christensen <sparks(a)redhat.com>
---------------------------------------------------------------
en-US/What_is_Secure_Boot.xml | 67 ++++++++++++++++++++++++++++++++++++-----
1 files changed, 59 insertions(+), 8 deletions(-)
diff --git a/en-US/What_is_Secure_Boot.xml b/en-US/What_is_Secure_Boot.xml
index 0a65ad3..76d1a40 100644
--- a/en-US/What_is_Secure_Boot.xml
+++ b/en-US/What_is_Secure_Boot.xml
@@ -515,14 +515,65 @@ boot is not signed and could contain malicious code. The kernel
<section
id="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Risks-Forced_Removal_of_Features">
<title>Forced removal of features in Secure Boot mode</title>
<para>
- We currently use a blacklist approach to disable known-unsafe
-kernel functionality. If additional kernel functionality which is
-equivalent to arbitrary code execution in kernel mode becomes known, we
-will be forced to disable it. Customers relying on this functionality will
-be left with non-working hardware after a system upgrade, and perhaps with
-unbootable systems. Recovery would require manual steps per system, and
-physical presence may be required.
- </para>
+We currently use a blacklist approach to disable known-unsafe kernel
+functionality. In some cases, specific funcionality has been disabled. In
+most cases such functionality is obscure and seldom used. Currently, the
+list of restricted functionality includes:
+</para>
+<itemizedlist>
+<listitem>
+<para>
+modification of device memory address maps through "setpci", and writes to
that
+memory from user space via sysfs
+</para>
+</listitem>
+<listitem>
+<para>
+hibernate (also known as <firstterm>suspend to disk</firstterm>)
+</para>
+</listitem>
+<listitem>
+<para>
+kexec and kdump (addressing this is a work in progress)
+</para>
+</listitem>
+<listitem>
+<para>
+writes to <firstterm>Machine Specific Registers</firstterm> writes via the
+"msr" kernel module.
+</para>
+</listitem>
+<listitem>
+<para>
+the acpi_rspd command line option, which is used to specify custom ACPI data
+</para>
+</listitem>
+<listitem>
+<para>
+io operations on /dev/kmem
+</para>
+</listitem>
+</itemizedlist>
+<para>
+In addition, use of systemtap modules is restricted to those modules which
+have been signed with an appropriate certificate. It is recommended that such
+a certificate be generated on-site, taking care to follow appropriate security
+practices for storage and use of a signing certificate. When using a site-local
+certificate, it can be enrolled in the machine's local database using the
+<firstterm>mokutil</firstterm> utility, which will then require a reboot
before
+taking effect. Upon rebooting, <firstterm>shim</firstterm> will start
+<firstterm>MokManager</firstterm> to present you with an interface to enroll
+the certificate.
+</para>
+<warning>
+<para>
+It is critically important that proper precautions be employed when using
+site-local certificates, so that they cannot be found and used by an attacker
+to subvert module security. Treat such certificates as you would any critical
+secrets, and follow industry best practices for cryptographic keys and
+certificates.
+</para>
+</warning>
</section>
<section
id="sect-UEFI_Secure_Boot_Guide-What_is_Secure_Boot-Risks-System_Transition">
<title>System Transitions out of Secure Boot</title>