rpms
/
kernel
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Fix infinite loop in efi signature parser 

- Don't error out if db doesn't exist
This commit is contained in:
Josh Boyer 2012-12-12 15:17:34 -05:00
parent 9461efbced
commit e1b90cc25d
2 changed files with 106 additions and 71 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
kernel.spec
View File

@ -62,7 +62,7 @@ Summary: The Linux kernel
# For non-released -rc kernels, this will be appended after the rcX and
# gitX tags, so a 3 here would become part of release "0.rcX.gitX.3"
#
%global baserelease 4
%global baserelease 5
%global fedora_build %{baserelease}
# base_sublevel is the kernel version we're starting with and patching
@ -685,7 +685,7 @@ Patch800: linux-2.6-crash-driver.patch
Patch900: modsign-post-KS-jwb.patch
# secure boot
Patch1000: secure-boot-20121210.patch
Patch1000: secure-boot-20121212.patch
Patch1001: efivarfs-3.7.patch
# Improve PCI support on UEFI
@ -1413,7 +1413,7 @@ ApplyPatch modsign-post-KS-jwb.patch
# secure boot
ApplyPatch efivarfs-3.7.patch
ApplyPatch secure-boot-20121210.patch
ApplyPatch secure-boot-20121212.patch
# Improved PCI support for UEFI
ApplyPatch handle-efi-roms.patch
@ -2344,6 +2344,10 @@ fi
# ||----w |
# || ||
%changelog
* Wed Dec 12 2012 Josh Boyer <jwboyer@redhat.com>
- Fix infinite loop in efi signature parser
- Don't error out if db doesn't exist
* Tue Dec 11 2012 Peter Robinson <pbrobinson@fedoraproject.org>
- Update ARM configs for latest 3.7
- Drop highbank kernel build variant as its in unified kernel

167
secure-boot-20121210.patch → secure-boot-20121212.patch
View File

@ -1,7 +1,7 @@
From 200186e8567f6ee91cc1a72496a47ba992d6a820 Mon Sep 17 00:00:00 2001
From d510ea864f470d96aafb75d0de7f09450407095e Mon Sep 17 00:00:00 2001
From: Matthew Garrett <mjg@redhat.com>
Date: Thu, 20 Sep 2012 10:40:56 -0400
Subject: [PATCH 01/19] Secure boot: Add new capability
Subject: [PATCH 01/20] Secure boot: Add new capability
Secure boot adds certain policy requirements, including that root must not
be able to do anything that could cause the kernel to execute arbitrary code.
@ -35,10 +35,10 @@ index ba478fa..7109e65 100644
1.8.0.1
From 3e49bf943b4fe0cc7e543e90f7f4a46e9f1927d8 Mon Sep 17 00:00:00 2001
From a07ae01ac4b304ac7f0e2b5d4193519f1a9eee8d Mon Sep 17 00:00:00 2001
From: Matthew Garrett <mjg@redhat.com>
Date: Thu, 20 Sep 2012 10:40:57 -0400
Subject: [PATCH 02/19] PCI: Lock down BAR access in secure boot environments
Subject: [PATCH 02/20] PCI: Lock down BAR access in secure boot environments
Any hardware that can potentially generate DMA has to be locked down from
userspace in order to avoid it being possible for an attacker to cause
@ -136,10 +136,10 @@ index e1c1ec5..97e785f 100644
1.8.0.1
From 981648fc5ed3b1681d33b508541cb6f749ad49fa Mon Sep 17 00:00:00 2001
From 1b5a1b53577992b32a3f51b18aa07cb9b300a3b1 Mon Sep 17 00:00:00 2001
From: Matthew Garrett <mjg@redhat.com>
Date: Thu, 20 Sep 2012 10:40:58 -0400
Subject: [PATCH 03/19] x86: Lock down IO port access in secure boot
Subject: [PATCH 03/20] x86: Lock down IO port access in secure boot
environments
IO port access would permit users to gain access to PCI configuration
@ -193,10 +193,10 @@ index 0537903..47501fc 100644
1.8.0.1
From 6148856150e49b14758011637e85d14c24e3edac Mon Sep 17 00:00:00 2001
From 09c266136915eb1f4a9b36423b7ba65e3d024de4 Mon Sep 17 00:00:00 2001
From: Matthew Garrett <mjg@redhat.com>
Date: Thu, 20 Sep 2012 10:40:59 -0400
Subject: [PATCH 04/19] ACPI: Limit access to custom_method
Subject: [PATCH 04/20] ACPI: Limit access to custom_method
It must be impossible for even root to get code executed in kernel context
under a secure boot environment. custom_method effectively allows arbitrary
@ -225,10 +225,10 @@ index 5d42c24..247d58b 100644
1.8.0.1
From 63800055d3fe3666bd429d39fee5be83a99e6606 Mon Sep 17 00:00:00 2001
From f3e9cb16e5ab3e680ec3ef464682c52371bbbbe3 Mon Sep 17 00:00:00 2001
From: Matthew Garrett <mjg@redhat.com>
Date: Thu, 20 Sep 2012 10:41:00 -0400
Subject: [PATCH 05/19] asus-wmi: Restrict debugfs interface
Subject: [PATCH 05/20] asus-wmi: Restrict debugfs interface
We have no way of validating what all of the Asus WMI methods do on a
given machine, and there's a risk that some will allow hardware state to
@ -278,10 +278,10 @@ index c0e9ff4..3c10167 100644
1.8.0.1
From cacfc9a562c89f0f9c2d9fa8c7ad2b4d90abb0ee Mon Sep 17 00:00:00 2001
From 23372d2a40135aca7a6d73511bd88790b598b489 Mon Sep 17 00:00:00 2001
From: Matthew Garrett <mjg@redhat.com>
Date: Thu, 20 Sep 2012 10:41:01 -0400
Subject: [PATCH 06/19] Restrict /dev/mem and /dev/kmem in secure boot setups
Subject: [PATCH 06/20] Restrict /dev/mem and /dev/kmem in secure boot setups
Allowing users to write to address space makes it possible for the kernel
to be subverted. Restrict this when we need to protect the kernel.
@ -319,10 +319,10 @@ index 47501fc..8817cdc 100644
1.8.0.1
From 87912773b97ee7970b0532ddc9a53cf5f7d98d69 Mon Sep 17 00:00:00 2001
From a0c80b01e80a1f6484a2a2811b4a212322494614 Mon Sep 17 00:00:00 2001
From: Josh Boyer <jwboyer@redhat.com>
Date: Thu, 20 Sep 2012 10:41:02 -0400
Subject: [PATCH 07/19] Secure boot: Add a dummy kernel parameter that will
Subject: [PATCH 07/20] Secure boot: Add a dummy kernel parameter that will
switch on Secure Boot mode
This forcibly drops CAP_COMPROMISE_KERNEL from both cap_permitted and cap_bset
@ -385,10 +385,10 @@ index 48cea3d..3f5be65 100644
1.8.0.1
From e8ed63dea7cc735fc25dfbfbff680b5ff6dd5df3 Mon Sep 17 00:00:00 2001
From 640f088c49da87a344417f58d3faa72d63a4f6ed Mon Sep 17 00:00:00 2001
From: Matthew Garrett <mjg@redhat.com>
Date: Thu, 20 Sep 2012 10:41:03 -0400
Subject: [PATCH 08/19] efi: Enable secure boot lockdown automatically when
Subject: [PATCH 08/20] efi: Enable secure boot lockdown automatically when
enabled in firmware
The firmware has a set of flags that indicate whether secure boot is enabled
@ -512,10 +512,10 @@ index ebbed2c..a24faf1 100644
1.8.0.1
From 139ac33cb367b928546bc04a37ad481dff23b745 Mon Sep 17 00:00:00 2001
From 994d895b5b684fc53c3b43dda9aee460c1f526f2 Mon Sep 17 00:00:00 2001
From: Josh Boyer <jwboyer@redhat.com>
Date: Thu, 20 Sep 2012 10:41:04 -0400
Subject: [PATCH 09/19] acpi: Ignore acpi_rsdp kernel parameter in a secure
Subject: [PATCH 09/20] acpi: Ignore acpi_rsdp kernel parameter in a secure
boot environment
This option allows userspace to pass the RSDP address to the kernel. This
@ -544,10 +544,10 @@ index 9eaf708..f94341b 100644
1.8.0.1
From 62401cc2543e14d4b71a51c98d69a771e2e1ed54 Mon Sep 17 00:00:00 2001
From c80aaf3eee3cb6b0d1a051e418ee99cd238c868c Mon Sep 17 00:00:00 2001
From: Josh Boyer <jwboyer@redhat.com>
Date: Thu, 20 Sep 2012 10:41:05 -0400
Subject: [PATCH 10/19] SELinux: define mapping for new Secure Boot capability
Subject: [PATCH 10/20] SELinux: define mapping for new Secure Boot capability
Add the name of the new Secure Boot capability. This allows SELinux
policies to properly map CAP_COMPROMISE_KERNEL to the appropriate
@ -577,10 +577,10 @@ index df2de54..70e2834 100644
1.8.0.1
From 1a8c4b9afd863e82f6b2f4f5fdaa1d2fa54270e7 Mon Sep 17 00:00:00 2001
From 26352bcb92468233dd960b5d02ba1db344df72b9 Mon Sep 17 00:00:00 2001
From: Matthew Garrett <mjg@redhat.com>
Date: Tue, 4 Sep 2012 11:55:13 -0400
Subject: [PATCH 11/19] kexec: Disable in a secure boot environment
Subject: [PATCH 11/20] kexec: Disable in a secure boot environment
kexec could be used as a vector for a malicious user to use a signed kernel
to circumvent the secure boot trust model. In the long run we'll want to
@ -609,10 +609,10 @@ index 5e4bd78..dd464e0 100644
1.8.0.1
From afd6b432a80c87536d35bca1b7e58b0117f9bdc0 Mon Sep 17 00:00:00 2001
From c03c68adceaec9656c55c47190fb4243bf903b40 Mon Sep 17 00:00:00 2001
From: Josh Boyer <jwboyer@redhat.com>
Date: Mon, 25 Jun 2012 21:29:46 -0400
Subject: [PATCH 12/19] Documentation: kernel-parameters.txt remove
Subject: [PATCH 12/20] Documentation: kernel-parameters.txt remove
capability.disable
Remove the documentation for capability.disable. The code supporting this
@ -650,10 +650,10 @@ index 0d6c28d..d9af501 100644
1.8.0.1
From c2bff8ab14c5cb31e356649de36440c9fc2612ec Mon Sep 17 00:00:00 2001
From 3f1bda64d2c7b369e2833bd32cd1f3ba6c90348f Mon Sep 17 00:00:00 2001
From: Josh Boyer <jwboyer@redhat.com>
Date: Fri, 5 Oct 2012 10:12:48 -0400
Subject: [PATCH 13/19] modsign: Always enforce module signing in a Secure Boot
Subject: [PATCH 13/20] modsign: Always enforce module signing in a Secure Boot
environment
If a machine is booted into a Secure Boot environment, we need to
@ -712,10 +712,10 @@ index 6e48c3a..6d5d2aa 100644
1.8.0.1
From 4f4a721fd5ac763dabbf028f9529549e4202603f Mon Sep 17 00:00:00 2001
From e6e3ec77b2fa037b32829e7f5ee468ad8a62dd05 Mon Sep 17 00:00:00 2001
From: Dave Howells <dhowells@redhat.com>
Date: Tue, 23 Oct 2012 09:30:54 -0400
Subject: [PATCH 14/19] Add EFI signature data types, such as are used for
Subject: [PATCH 14/20] Add EFI signature data types, such as are used for
containing hashes, keys and certificates for cryptographic verification.
Signed-off-by: David Howells <dhowells@redhat.com>
@ -765,10 +765,10 @@ index 337aefb..a01f8a7 100644
1.8.0.1
From e23cf2e227ea4090d98a06e5c0bd6a89e3414be0 Mon Sep 17 00:00:00 2001
From c2542256f632a22232cf02d5fd64568a5afa4516 Mon Sep 17 00:00:00 2001
From: Dave Howells <dhowells@redhat.com>
Date: Tue, 23 Oct 2012 09:36:28 -0400
Subject: [PATCH 15/19] Add an EFI signature blob parser and key loader. X.509
Subject: [PATCH 15/20] Add an EFI signature blob parser and key loader. X.509
certificates are loaded into the specified keyring as asymmetric type keys.
Signed-off-by: David Howells <dhowells@redhat.com>
@ -940,10 +940,10 @@ index a01f8a7..44a7faa 100644
1.8.0.1
From 766f1838a0151f2367a83720a94a06e3c8fb04f9 Mon Sep 17 00:00:00 2001
From a418e6fdd2aa946a30cf1bee5c9540d03d626981 Mon Sep 17 00:00:00 2001
From: Josh Boyer <jwboyer@redhat.com>
Date: Fri, 26 Oct 2012 12:29:49 -0400
Subject: [PATCH 16/19] EFI: Add in-kernel variable to determine if Secure Boot
Subject: [PATCH 16/20] EFI: Add in-kernel variable to determine if Secure Boot
is enabled
There are a few cases where in-kernel functions may need to know if
@ -1012,10 +1012,10 @@ index 44a7faa..b5403ae 100644
1.8.0.1
From b50f77a04b997699771c4f4ee1f55dac0cf5dc2c Mon Sep 17 00:00:00 2001
From f6d05f0974f6a7667ebbbf91624678bcf32169ae Mon Sep 17 00:00:00 2001
From: Josh Boyer <jwboyer@redhat.com>
Date: Fri, 26 Oct 2012 12:36:24 -0400
Subject: [PATCH 17/19] MODSIGN: Add module certificate blacklist keyring
Subject: [PATCH 17/20] MODSIGN: Add module certificate blacklist keyring
This adds an additional keyring that is used to store certificates that
are blacklisted. This keyring is searched first when loading signed modules
@ -1133,17 +1133,18 @@ index f2970bd..8ab83a6 100644
1.8.0.1
From f588bd4beb0fd6993dfc07167df1c904e00f7af6 Mon Sep 17 00:00:00 2001
From ff0ed221fe8d5a46a9bc36323ca8fb6f75c22a83 Mon Sep 17 00:00:00 2001
From: Josh Boyer <jwboyer@redhat.com>
Date: Fri, 26 Oct 2012 12:42:16 -0400
Subject: [PATCH 18/19] MODSIGN: Import certificates from UEFI Secure Boot
Subject: [PATCH 18/20] MODSIGN: Import certificates from UEFI Secure Boot
Secure Boot stores a list of allowed certificates in the 'db' variable.
This imports those certificates into the module signing keyring. This
allows for a third party signing certificate to be used in conjunction
with signed modules. By importing the public certificate into the 'db'
variable, a user can allow a module signed with that certificate to
load.
load. The shim UEFI bootloader has a similar certificate list stored
in the 'MokListRT' variable. We import those as well.
In the opposite case, Secure Boot maintains a list of disallowed
certificates in the 'dbx' variable. We load those certificates into
@ -1153,10 +1154,10 @@ signed with those from loading.
Signed-off-by: Josh Boyer <jwboyer@redhat.com>
---
include/linux/efi.h | 6 ++++
init/Kconfig | 9 +++++
init/Kconfig | 9 ++++++
kernel/Makefile | 3 ++
kernel/modsign_uefi.c | 97 +++++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 115 insertions(+)
kernel/modsign_uefi.c | 90 +++++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 108 insertions(+)
create mode 100644 kernel/modsign_uefi.c
diff --git a/include/linux/efi.h b/include/linux/efi.h
@ -1219,10 +1220,10 @@ index 86e3285..12e17ab 100644
targets += config_data.gz
diff --git a/kernel/modsign_uefi.c b/kernel/modsign_uefi.c
new file mode 100644
index 0000000..8c30978
index 0000000..76a5a34
--- /dev/null
+++ b/kernel/modsign_uefi.c
@@ -0,0 +1,97 @@
@@ -0,0 +1,90 @@
+#include <linux/kernel.h>
+#include <linux/sched.h>
+#include <linux/cred.h>
@ -1276,47 +1277,40 @@ index 0000000..8c30978
+ if (!secure_boot_enabled)
+ return 0;
+
+ /* Get db, MokListRT, and dbx. They might not exist, so it isn't
+ * an error if we can't get them.
+ */
+ db = get_cert_list(L"db", &secure_var, &dbsize);
+ if (!db) {
+ pr_err("Couldn't get db list\n");
+ rc = -1;
+ goto err;
+ pr_err("MODSIGN: Couldn't get UEFI db list\n");
+ } else {
+ rc = parse_efi_signature_list(db, dbsize, modsign_keyring);
+ if (rc)
+ pr_err("Couldn't parse db signatures: %d\n", rc);
+ kfree(db);
+ }
+
+ mok = get_cert_list(L"MokListRT", &mok_var, &moksize);
+ if (!mok) {
+ pr_info("Couldn't get MokListRT\n");
+ }
+
+ /* Get dbx. It might not exist, so it isn't an error if we can't
+ * get it.
+ */
+ dbx = get_cert_list(L"dbx", &secure_var, &dbxsize);
+ if (!dbx) {
+ pr_info("Couldn't get dbx list\n");
+ }
+
+ rc = parse_efi_signature_list(db, dbsize, modsign_keyring);
+ if (rc)
+ pr_err("Couldn't parse db signatures: %d\n", rc);
+
+ if (mok) {
+ pr_info("MODSIGN: Couldn't get UEFI MokListRT\n");
+ } else {
+ rc = parse_efi_signature_list(mok, moksize, modsign_keyring);
+ if (rc)
+ pr_err("Couldn't parse MokListRT signatures: %d\n", rc);
+ kfree(mok);
+ }
+
+ if (dbx) {
+ dbx = get_cert_list(L"dbx", &secure_var, &dbxsize);
+ if (!dbx) {
+ pr_info("MODSIGN: Couldn't get UEFI dbx list\n");
+ } else {
+ rc = parse_efi_signature_list(dbx, dbxsize,
+ modsign_blacklist);
+ if (rc)
+ pr_err("Couldn't parse dbx signatures: %d\n", rc);
+ kfree(dbx);
+ }
+
+err:
+ kfree(db);
+ kfree(mok);
+ kfree(dbx);
+ return rc;
+}
+late_initcall(load_uefi_certs);
@ -1324,10 +1318,10 @@ index 0000000..8c30978
1.8.0.1
From f910a06d820b4dad2ccd0acdfbc878fff73a3b28 Mon Sep 17 00:00:00 2001
From 7d5629a2000d9dc92da91d2f1258af748e89cfd7 Mon Sep 17 00:00:00 2001
From: Josh Boyer <jwboyer@redhat.com>
Date: Fri, 26 Oct 2012 14:02:09 -0400
Subject: [PATCH 19/19] hibernate: Disable in a Secure Boot environment
Subject: [PATCH 19/20] hibernate: Disable in a Secure Boot environment
There is currently no way to verify the resume image when returning
from hibernate. This might compromise the secure boot trust model,
@ -1419,3 +1413,40 @@ index 4ed81e7..b11a0f4 100644
--
1.8.0.1
From 81adc779dba0f45f10b5ff307bd55832305f1112 Mon Sep 17 00:00:00 2001
From: Josh Boyer <jwboyer@redhat.com>
Date: Wed, 12 Dec 2012 11:48:49 -0500
Subject: [PATCH 20/20] Don't soft lockup on bad EFI signature lists
If a signature list is read from an UEFI variable and that contains bogus
data, we can go into an infinite loop in efi_parse_signature_list. Notably,
if one of the entries in the list has a signature_size that is larger than
the actual signature size, it will fail the elsize < esize test. Simply
continuing in the loop without modifying the data or size variables just
leads to the same list entry being parsed repeatedly.
Since the data is bogus, but we can't tell which value is actually
incorrect, we need to stop parsing the list. Just return -EBADMSG instead.
Signed-off-by: Josh Boyer <jwboyer@redhat.com>
---
crypto/asymmetric_keys/efi_parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/asymmetric_keys/efi_parser.c b/crypto/asymmetric_keys/efi_parser.c
index 59b859a..a0b8a3a 100644
--- a/crypto/asymmetric_keys/efi_parser.c
+++ b/crypto/asymmetric_keys/efi_parser.c
@@ -61,7 +61,7 @@ int __init parse_efi_signature_list(const void *data, size_t size, struct key *k
elsize < esize ||
elsize % esize != 0) {
pr_devel("- bad size combo @%x\n", offs);
- continue;
+ return -EBADMSG;
}
if (efi_guidcmp(list.signature_type, efi_cert_x509_guid) != 0) {
--
1.8.0.1