From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757908AbcCUUcG (ORCPT ); Mon, 21 Mar 2016 16:32:06 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:36142 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757485AbcCUUcD (ORCPT ); Mon, 21 Mar 2016 16:32:03 -0400 Date: Mon, 21 Mar 2016 20:31:59 +0000 From: Matt Fleming To: Ard Biesheuvel Cc: "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , joeyli , Kweh Hock Leong , Borislav Petkov , Mark Salter , Peter Jones , "Bryan O'Donoghue" Subject: Re: [PATCH 2/4] efi: Capsule update support Message-ID: <20160321203159.GF11676@codeblueprint.co.uk> References: <1458219431-24741-1-git-send-email-matt@codeblueprint.co.uk> <1458219431-24741-3-git-send-email-matt@codeblueprint.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.