From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751253AbdFEQLt (ORCPT ); Mon, 5 Jun 2017 12:11:49 -0400 Received: from mail-wr0-f179.google.com ([209.85.128.179]:34817 "EHLO mail-wr0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751077AbdFEQLr (ORCPT ); Mon, 5 Jun 2017 12:11:47 -0400 Date: Mon, 5 Jun 2017 18:11:43 +0200 From: Ingo Molnar To: Ard Biesheuvel Cc: "linux-efi@vger.kernel.org" , Thomas Gleixner , "H . Peter Anvin" , Jan Kiszka , "linux-kernel@vger.kernel.org" , Matt Fleming Subject: Re: [PATCH 10/13] efi/capsule: Add support for Quark security header Message-ID: <20170605161143.3ftptomo6ynh7wau@gmail.com> References: <20170602135207.21708-1-ard.biesheuvel@linaro.org> <20170602135207.21708-11-ard.biesheuvel@linaro.org> <20170605155050.fuhwcjkmmdqc67d2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Ard Biesheuvel wrote: > >> +config EFI_CAPSULE_QUIRK_QUARK_CSH > >> + boolean "Add support for Quark capsules with non-standard headers" > >> + depends on X86 && !64BIT > >> + select EFI_CAPSULE_LOADER > >> + default y > >> + help > >> + Add support for processing Quark X1000 EFI capsules, whose header > >> + layout deviates from the layout mandated by the UEFI specification. > > > > BTW., there's no need to further put this behind a Kconfig option: the quirk seems > > targeted enough, and the whole point of runtime quirks is so that can be applied > > safely within generic kernels. Turning them off via Kconfig seems wrong. > > > > Not entirely: enabling this quirk will remove the ability to select > EFI_CAPSULE_LOADER as a module. So making it unconditional makes > EFI_CAPSULE_LOADER builtin-only for 32-bit x86. This is necessary for > the override of __weak symbols in the generic capsule code to work as > expected. > > This was a compromise between allowing no capsule loader quirks at > all, and having an elaborate framework with hooks in various places > (which invariably ends up parameterizing the wrong things if you have > only one real world quirk to design your framework around). Ok, I see - fair enough! Thanks, Ingo