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: Mon, 21 Mar 2016 20:31:59 +0000	[thread overview]
Message-ID: <20160321203159.GF11676@codeblueprint.co.uk> (raw)
In-Reply-To: <CAKv+Gu8fX7x1x3Od5ThxyFxux_NKDx59PNedkgSfn_V0yg_NQQ@mail.gmail.com>

On Mon, 21 Mar, at 11:19:50AM, Ard Biesheuvel wrote:
> 
> How are capsules with the CAPSULE_FLAGS_INITIATE_RESET flag handled?
> The runtime service will never return in that case, so I suppose we
> need some explicit handling somewhere?

Good question. They're not handled in any special way with this patch
series, so the firmware will just initiate its own reset inside of
UpdateCapsule().

That's probably not what we want, because things like on-disk
consistency are not guaranteed if the machine spontaneously reboots
without assistance from the kernel.

The simplest thing to do is to refuse to pass such capsules to the
firmware, since it's likely not going to be a common use case. But
maybe that's overly restrictive.

Let me have a think about that one.

  reply	other threads:[~2016-03-21 20:32 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 [this message]
2016-03-29 12:26       ` Matt Fleming
2016-03-29 13:50         ` Ard Biesheuvel
2016-04-05 10:09           ` Matt Fleming
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=20160321203159.GF11676@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