linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: linux-integrity@vger.kernel.org
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	"Luis R . Rodriguez" <mcgrof@kernel.org>,
	Eric Biederman <ebiederm@xmission.com>,
	kexec@lists.infradead.org, Andres Rodriguez <andresx7@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Luis R . Rodriguez" <mcgrof@suse.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: [PATCH v6 8/8] ima: based on policy warn about loading firmware (pre-allocated buffer)
Date: Fri, 13 Jul 2018 14:06:03 -0400	[thread overview]
Message-ID: <1531505163-20227-9-git-send-email-zohar@linux.vnet.ibm.com> (raw)
In-Reply-To: <1531505163-20227-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.

Do devices using pre-allocated memory run the risk of the firmware being
accessible to the device prior to the completion of IMA's signature
verification any more than when using two buffers? (Refer to mailing list
discussion[1]).

Only on systems with an IOMMU can the access be prevented.  As long as
the signature verification completes prior to the DMA map is performed,
the device can not access the buffer.  This implies that the same buffer
can not be re-used.  Can we ensure the buffer has not been DMA mapped
before using the pre-allocated buffer?

[1] https://lkml.org/lkml/2018/7/10/56

Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>

---
Changelog v6:
- Change warning to comment.

Changelog v5:
- Instead of preventing loading firmware from a pre-allocate buffer,
emit a warning.

 security/integrity/ima/ima_main.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index ef349a761609..b82500cd6fbd 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -429,6 +429,14 @@ void ima_post_path_mknod(struct dentry *dentry)
  */
 int ima_read_file(struct file *file, enum kernel_read_file_id read_id)
 {
+	/*
+	 * READING_FIRMWARE_PREALLOC_BUFFER
+	 *
+	 * Do devices using pre-allocated memory run the risk of the
+	 * firmware being accessible to the device prior to the completion
+	 * of IMA's signature verification any more than when using two
+	 * buffers?
+	 */
 	return 0;
 }
 
-- 
2.7.5


  parent reply	other threads:[~2018-07-13 18:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-13 18:05 [PATCH v6 0/8] kexec/firmware: support system wide policy requiring signatures Mimi Zohar
2018-07-13 18:05 ` [PATCH v6 1/8] security: define new LSM hook named security_kernel_load_data Mimi Zohar
2018-07-15  2:13   ` Kees Cook
2018-07-13 18:05 ` [PATCH v6 2/8] kexec: add call to LSM hook in original kexec_load syscall Mimi Zohar
2018-07-15  2:14   ` Kees Cook
2018-07-13 18:05 ` [PATCH v6 3/8] ima: based on policy require signed kexec kernel images Mimi Zohar
2018-07-15  2:21   ` Kees Cook
2018-07-13 18:05 ` [PATCH v6 4/8] firmware: add call to LSM hook before firmware sysfs fallback Mimi Zohar
2018-07-15  2:24   ` Kees Cook
2018-07-13 18:06 ` [PATCH v6 5/8] ima: based on policy require signed firmware (sysfs fallback) Mimi Zohar
2018-07-15  2:27   ` Kees Cook
2018-07-13 18:06 ` [PATCH v6 6/8] ima: add build time policy Mimi Zohar
2018-07-15  2:28   ` Kees Cook
2018-07-13 18:06 ` [PATCH v6 7/8] module: replace the existing LSM hook in init_module Mimi Zohar
2018-07-15  2:30   ` Kees Cook
2018-07-16 13:52     ` Mimi Zohar
2018-07-13 18:06 ` Mimi Zohar [this message]
2018-07-15  2:34   ` [PATCH v6 8/8] ima: based on policy warn about loading firmware (pre-allocated buffer) Kees Cook
2018-07-16 19:59 ` [PATCH v6 0/8] kexec/firmware: support system wide policy requiring signatures James Morris

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=1531505163-20227-9-git-send-email-zohar@linux.vnet.ibm.com \
    --to=zohar@linux.vnet.ibm.com \
    --cc=andresx7@gmail.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mcgrof@suse.com \
    --cc=sboyd@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).