[uefi-secure-boot-guide] master: Adding additional text to Implementation and What is... (60a7cc1)

sparks at fedoraproject.org sparks at fedoraproject.org
Fri Feb 1 21:46:27 UTC 2013


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

On branch  : master

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

commit 60a7cc1b80d4c785d5b394acac74dc8d20d2d4a5
Merge: ca5d73c 437ecf9
Author: Eric Christensen <sparks at fedoraproject.org>
Date:   Fri Feb 1 16:45:04 2013 -0500

    Adding additional text to Implementation and What is...



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

 en-US/Implementation_of_Secure_Boot.xml |    4 ++++
 en-US/What_is_Secure_Boot.xml           |   11 +----------
 2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/en-US/Implementation_of_Secure_Boot.xml b/en-US/Implementation_of_Secure_Boot.xml
index 06e2463..1ca8378 100644
--- a/en-US/Implementation_of_Secure_Boot.xml
+++ b/en-US/Implementation_of_Secure_Boot.xml
@@ -37,7 +37,11 @@ contains the public key used to sign kerenl modules.
 		</para>
 		<para>
 		Kernel Modules: These are signed with a private key generated
+<<<<<<< HEAD
 during build. This key is not saved, a new key is used with each Kernel
+=======
+during build. This key is not saved, a new key is used with each kernel
+>>>>>>> bressers
 build.
 		</para>
 		<para>
diff --git a/en-US/What_is_Secure_Boot.xml b/en-US/What_is_Secure_Boot.xml
index f04666a..95de533 100644
--- a/en-US/What_is_Secure_Boot.xml
+++ b/en-US/What_is_Secure_Boot.xml
@@ -25,7 +25,7 @@ extend this chain of trust down into user binaries, but that moves us
 outside of the concept of Secure Boot and into another topic.
 		</para>
 		<para>
-		&PRODUCT; has expanded the chain of trust into the Kernel.
+		&PRODUCT; has expanded the chain of trust into the kernel.
 Verification happens as far as only loading signed kernel modules, but it
 does not extend to user space applications. We can be certain that no
 unsigned executable code is present until the initial ramdisk (initrd) is loaded. Since
@@ -42,15 +42,6 @@ restricted, but user space malware cannot. This of course doesn't mean
 Secure Boot isn't useful, just that it currently only serves a single
 purpose, which is protecting the boot loader.
                 </para>
-				<note>
-					<title>Do not disable secure boot</title>
-					<para>
-						It is important you do not disable Secure Boot if
-your system fails to boot. A plausible attack would be replacing the shim
-with something dangerous and hoping a user will disable Secure Boot to
-solve their problem.
-					</para>
-				</note>
         </section>
 </chapter>
 



More information about the docs-commits mailing list