[uefi-secure-boot-guide] master: Provide a specific, itemized list of functionality we've disabled. (e223e06)

[sparks at fedoraproject.org]

Repository : http://git.fedorahosted.org/git/?p=docs/uefi-secure-boot-guide.git

On branch  : master

>---------------------------------------------------------------

commit e223e06ed3b7ee2ac3d93ab7ab9d919985e301c8
Author: Peter Jones <pjones at 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 at redhat.com>
    Signed-off-by: Eric Christensen <sparks at 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>