From: zohar@linux.vnet.ibm.com (Mimi Zohar)
To: linux-security-module@vger.kernel.org
Subject: [RFC PATCH v4 7/8] ima: based on policy prevent loading firmware (pre-allocated buffer)
Date: Tue, 29 May 2018 14:01:59 -0400 [thread overview]
Message-ID: <1527616920-5415-8-git-send-email-zohar@linux.vnet.ibm.com> (raw)
In-Reply-To: <1527616920-5415-1-git-send-email-zohar@linux.vnet.ibm.com>
Some systems are memory constrained but they need to load very large
firmwares. The firmware subsystem allows drivers to request this
firmware be loaded from the filesystem, but this requires that the
entire firmware be loaded into kernel memory first before it's provided
to the driver. This can lead to a situation where we map the firmware
twice, once to load the firmware into kernel memory and once to copy the
firmware into the final resting place.
To resolve this problem, commit a098ecd2fa7d ("firmware: support loading
into a pre-allocated buffer") introduced request_firmware_into_buf() API
that allows drivers to request firmware be loaded directly into a
pre-allocated buffer. The QCOM_MDT_LOADER calls dma_alloc_coherent() to
allocate this buffer. According to Documentation/DMA-API.txt,
Consistent memory is memory for which a write by either the
device or the processor can immediately be read by the processor
or device without having to worry about caching effects. (You
may however need to make sure to flush the processor's write
buffers before telling devices to read that memory.)
Devices using pre-allocated DMA memory run the risk of the firmware
being accessible by the device prior to the kernel's firmware signature
verification has completed.
Loading firmware already calls the security_kernel_read_file LSM hook.
With an IMA policy requiring signed firmware, this patch prevents
loading firmware into a pre-allocated buffer.
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Serge E. Hallyn <serge@hallyn.com>
Cc: Stephen Boyd <sboyd@kernel.org>
---
security/integrity/ima/ima_main.c | 26 +++++++++++++++++---------
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 4a87f78098c8..3dae605a1604 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -419,6 +419,15 @@ void ima_post_path_mknod(struct dentry *dentry)
iint->flags |= IMA_NEW_FILE;
}
+static int read_idmap[READING_MAX_ID] = {
+ [READING_FIRMWARE] = FIRMWARE_CHECK,
+ [READING_FIRMWARE_PREALLOC_BUFFER] = FIRMWARE_CHECK,
+ [READING_MODULE] = MODULE_CHECK,
+ [READING_KEXEC_IMAGE] = KEXEC_KERNEL_CHECK,
+ [READING_KEXEC_INITRAMFS] = KEXEC_INITRAMFS_CHECK,
+ [READING_POLICY] = POLICY_CHECK
+};
+
/**
* ima_read_file - pre-measure/appraise hook decision based on policy
* @file: pointer to the file to be measured/appraised/audit
@@ -442,18 +451,17 @@ int ima_read_file(struct file *file, enum kernel_read_file_id read_id)
}
return 0; /* We rely on module signature checking */
}
+
+ if (read_id == READING_FIRMWARE_PREALLOC_BUFFER) {
+ if ((ima_appraise & IMA_APPRAISE_FIRMWARE) &&
+ (ima_appraise & IMA_APPRAISE_ENFORCE)) {
+ pr_err("Prevent device from accessing firmware prior to verifying the firmware signature.\n");
+ return -EACCES;
+ }
+ }
return 0;
}
-static int read_idmap[READING_MAX_ID] = {
- [READING_FIRMWARE] = FIRMWARE_CHECK,
- [READING_FIRMWARE_PREALLOC_BUFFER] = FIRMWARE_CHECK,
- [READING_MODULE] = MODULE_CHECK,
- [READING_KEXEC_IMAGE] = KEXEC_KERNEL_CHECK,
- [READING_KEXEC_INITRAMFS] = KEXEC_INITRAMFS_CHECK,
- [READING_POLICY] = POLICY_CHECK
-};
-
/**
* ima_post_read_file - in memory collect/appraise/audit measurement
* @file: pointer to the file to be measured/appraised/audit
--
2.7.5
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-05-29 18:01 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-29 18:01 [PATCH v4 0/8] kexec/firmware: support system wide policy requiring signatures Mimi Zohar
2018-05-29 18:01 ` [PATCH v4 1/8] security: define new LSM hook named security_kernel_load_data Mimi Zohar
2018-06-04 19:59 ` Serge E. Hallyn
2018-05-29 18:01 ` [PATCH v4 2/8] kexec: add call to LSM hook in original kexec_load syscall Mimi Zohar
2018-06-04 20:00 ` Serge E. Hallyn
2018-05-29 18:01 ` [PATCH v4 3/8] ima: based on policy require signed kexec kernel images Mimi Zohar
2018-05-29 18:01 ` [PATCH v4 4/8] firmware: add call to LSM hook before firmware sysfs fallback Mimi Zohar
2018-06-01 18:19 ` Luis R. Rodriguez
2018-05-29 18:01 ` [PATCH v4 5/8] ima: based on policy require signed firmware (sysfs fallback) Mimi Zohar
2018-06-01 18:21 ` Luis R. Rodriguez
2018-06-01 22:39 ` Mimi Zohar
2018-06-01 22:46 ` Luis R. Rodriguez
2018-06-01 23:04 ` Mimi Zohar
2018-05-29 18:01 ` [PATCH v4 6/8] ima: add build time policy Mimi Zohar
2018-05-29 18:01 ` Mimi Zohar [this message]
2018-06-01 19:15 ` [RFC PATCH v4 7/8] ima: based on policy prevent loading firmware (pre-allocated buffer) Luis R. Rodriguez
2018-06-01 19:25 ` Luis R. Rodriguez
2018-06-05 22:37 ` Kees Cook
2018-06-06 6:20 ` Ard Biesheuvel
2018-06-06 22:06 ` Luis R. Rodriguez
2018-05-29 18:02 ` [PATCH v4 8/8] module: replace the existing LSM hook in init_module Mimi Zohar
2018-05-29 22:39 ` Paul Moore
2018-05-29 23:14 ` Mimi Zohar
2018-05-30 21:00 ` Paul Moore
2018-05-31 15:23 ` [PATCH v4a " Mimi Zohar
2018-06-01 22:28 ` Paul Moore
2018-06-04 9:19 ` Jessica Yu
2018-06-05 19:45 ` Kees Cook
2018-06-05 21:35 ` Mimi Zohar
2018-06-05 22:26 ` Kees Cook
2018-06-05 22:40 ` Mimi Zohar
2018-05-29 23:25 ` [PATCH v4 " Mimi Zohar
2018-05-30 2:25 ` Eric W. Biederman
2018-05-30 21:09 ` Paul Moore
2018-06-04 14:03 ` [PATCH v4 0/8] kexec/firmware: support system wide policy requiring signatures Mimi Zohar
2018-06-04 19:32 ` Serge E. Hallyn
2018-06-04 19:53 ` Mimi Zohar
2018-06-04 22:03 ` Kees Cook
2018-06-05 4:09 ` Serge E. Hallyn
2018-06-05 12:19 ` Kees Cook
2018-06-05 13:25 ` Serge E. Hallyn
2018-06-05 13:43 ` Kees Cook
2018-06-05 14:05 ` Mimi Zohar
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=1527616920-5415-8-git-send-email-zohar@linux.vnet.ibm.com \
--to=zohar@linux.vnet.ibm.com \
--cc=linux-security-module@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).