public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matt Fleming <matt@codeblueprint.co.uk>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	joeyli <jlee@suse.com>,
	Kweh Hock Leong <hock.leong.kweh@intel.com>,
	Borislav Petkov <bp@alien8.de>, Mark Salter <msalter@redhat.com>,
	Peter Jones <pjones@redhat.com>,
	"Bryan O'Donoghue" <pure.logic@nexus-software.ie>
Subject: Re: [PATCH 2/4] efi: Capsule update support
Date: Tue, 5 Apr 2016 11:09:29 +0100	[thread overview]
Message-ID: <20160405100929.GB2701@codeblueprint.co.uk> (raw)
In-Reply-To: <CAKv+Gu_S-BBo8yinQmbEcag43krKBZGxf-0OC=WkZASgS5_Cdg@mail.gmail.com>

On Tue, 29 Mar, at 03:50:39PM, Ard Biesheuvel wrote:
> 
> Should we perhaps whitelist rather than blacklist these flags? If a
> 'EFI_CAPSULE_INITIATE_RESET_TOO' surfaces at some point, or flags that
> do other nasty things, at least we won't be caught off guard.
 
I spent a while thinking about this and was originally going to go
with the blacklist. The idea being that we wouldn't need to update the
kernel to allow new capsule flags to be passed through to the
firmware, even when the kernel doesn't care about them.

But then the thought of having to apply patches to stable to disallow
new capsule flags that don't work correctly with the current patches
left me feeling a cold chill.

So yes, it's a good suggestion Ard. Let's go with the whitelist, which
gives us the power to opt-in to any new capsule flags, whatever they
may be.

---

diff --git a/drivers/firmware/efi/capsule.c b/drivers/firmware/efi/capsule.c
index dac25208ad5e..0de55944ac0b 100644
--- a/drivers/firmware/efi/capsule.c
+++ b/drivers/firmware/efi/capsule.c
@@ -64,6 +64,17 @@ out:
 	return rv;
 }
 
+/*
+ * Whitelist of EFI capsule flags that we support.
+ *
+ * We do not handle EFI_CAPSULE_INITIATE_RESET because that would
+ * require us to prepare the kernel for reboot. Refuse to load any
+ * capsules with that flag and any other flags that we do not know how
+ * to handle.
+ */
+#define EFI_CAPSULE_SUPPORTED_FLAG_MASK			\
+	(EFI_CAPSULE_PERSIST_ACROSS_RESET | EFI_CAPSULE_POPULATE_SYSTEM_TABLE)
+
 /**
  * efi_capsule_supported - does the firmware support the capsule?
  * @guid: vendor guid of capsule
@@ -84,6 +95,9 @@ int efi_capsule_supported(efi_guid_t guid, u32 flags, size_t size, int *reset)
 	u64 max_size;
 	int rv = 0;
 
+	if (flags & ~EFI_CAPSULE_SUPPORTED_FLAG_MASK)
+		return -EINVAL;
+
 	capsule = kmalloc(sizeof(*capsule), GFP_KERNEL);
 	if (!capsule)
 		return -ENOMEM;

  reply	other threads:[~2016-04-05 10:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-17 12:57 [PATCH 0/4] EFI capsule update support Matt Fleming
2016-03-17 12:57 ` [PATCH 1/4] efi: Move efi_status_to_err() to drivers/firmware/efi/ Matt Fleming
2016-03-21  9:43   ` Ard Biesheuvel
2016-03-17 12:57 ` [PATCH 2/4] efi: Capsule update support Matt Fleming
2016-03-21 10:19   ` Ard Biesheuvel
2016-03-21 20:31     ` Matt Fleming
2016-03-29 12:26       ` Matt Fleming
2016-03-29 13:50         ` Ard Biesheuvel
2016-04-05 10:09           ` Matt Fleming [this message]
2016-03-17 12:57 ` [PATCH 3/4] x86/efi: Force EFI reboot to process pending capsules Matt Fleming
2016-03-17 12:57 ` [PATCH 4/4] efi: A misc char interface to update EFI firmware Matt Fleming
2016-04-01  2:48   ` deckard
2016-04-05  9:48     ` Matt Fleming

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=20160405100929.GB2701@codeblueprint.co.uk \
    --to=matt@codeblueprint.co.uk \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bp@alien8.de \
    --cc=hock.leong.kweh@intel.com \
    --cc=jlee@suse.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=msalter@redhat.com \
    --cc=pjones@redhat.com \
    --cc=pure.logic@nexus-software.ie \
    /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