From patchwork Wed Jul 4 15:49:17 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 141073 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp951273ljj; Wed, 4 Jul 2018 08:49:25 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeTh58oAxnZnIUZuLUCue/Kmb2UwBXhmtgH084TNgfgyPiH6vV4k/hwXThDwz5u0yrY5Fkh X-Received: by 2002:a63:6383:: with SMTP id x125-v6mr2385795pgb.127.1530719365779; Wed, 04 Jul 2018 08:49:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530719365; cv=none; d=google.com; s=arc-20160816; b=Z/5lfTVcYRonr+45VrgGhWFes/GmUx4rXurvQ+R+Kh+8Ll1xzLDFFAWskNcGwcyPgj ve0n/PJMOtBZ74ZJD/2wlMOYEzAm3LljvfXxbTMkTCEQAnrZE7afC7raiLjiR0QPi/Yo m0he4+kPUrjDkcpfnbCtSR7uh5CdWjjJmmMr/+V8GK3McTVjjLaseMW5L9SjrOMgo/Lb mgKZPIwm542fomCh6MKj+0P+iKP7/rOUb6tW4DRX7JOXRFEo9g+lqSKoACycGmW5XpDc /PrquKhEz9Fdz0N0vPHs6Yz//PKhb/UpMjyc+HGCCHTo5oq3R3jciUYr0IAt3YERYdWz 0j8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=9p6L2LIxcF+AaZ/JBMDxnNQ234pfI0CXGS4efMQstVM=; b=DoXpc0zoxaMZRrvOUv8cysHKOs6Nv1rzSqjABx5xMEKgZmpRR06NBOISWP1j1ci6K2 9/M8UfGB8XOOUZxynI23twV9VPNYJvK21KTVRpak0vD7DCihr7FVYmm965hlgs5Rm1Sn NW5U1ebQL4skiNV4IhgeX536/DFp5u6zW8lB5Kd7dxOjQzTRx09bl41on7jbM++THYZ0 MOEkiQmm4PpD/7+MQE8jSPB1MI69vXQfiuf5sZxFDJpD0cLNAZquFmxjSjnr8Llu02/s DOAxXRk17sxOXKYcxMlPyREHUSz4yuah5EjnakMe+3G2YrUC/4bdFAtpgEFRijKze6dl BtuQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.s=google header.b=fftyW0kg; spf=pass (google.com: best guess record for domain of linux-efi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-efi-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bj7-v6si3619371plb.119.2018.07.04.08.49.25; Wed, 04 Jul 2018 08:49:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-efi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org header.s=google header.b=fftyW0kg; spf=pass (google.com: best guess record for domain of linux-efi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-efi-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752567AbeGDPtZ (ORCPT + 3 others); Wed, 4 Jul 2018 11:49:25 -0400 Received: from mail-ed1-f68.google.com ([209.85.208.68]:37398 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752381AbeGDPtY (ORCPT ); Wed, 4 Jul 2018 11:49:24 -0400 Received: by mail-ed1-f68.google.com with SMTP id v22-v6so4355667edq.4 for ; Wed, 04 Jul 2018 08:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=sFG+PLVIALG7ezY8ZOn8xiKpfMXdS6nOJLmJhqmvWWI=; b=fftyW0kgy5ljUMoxsKk8IVrIoLr+U/OBN5BPlpgWxphjpFmZjhwlu0rUABXJSBqayu nmZKnM40489OdE/SW0Zx5PjYrOjiN6u701r3OUiY3jhwkFnDSDzezWZj2SkhqmG1R8Ic U3gNINjfb2HC8YuUQTA7+uD4REywixplCxyqE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=sFG+PLVIALG7ezY8ZOn8xiKpfMXdS6nOJLmJhqmvWWI=; b=URaWW+6R/Min7jMMGwVd6Qy3nEE4vvx7f+xtNHAyd/Ky6P/qJfYqXlwljhGuKeWrTD /GJeI580Jpb7Z2Ohzu9ysTmJiak9tGJ8X9G7fSw0IQ7NXLNWy+PsUr2VdRzBzFba/Thu +hHD85If/JEr5ifj2MrJofItjZfE8MdYQuzXbvExykoheS2jrLzB/3wzymZhIapwnaY7 Mor1ICFG2a5u8BQG0zhCEZGTh3nyr/MPksw/idhsM8dEh2EQCTVWFaApyVyCsumgX8p0 27cfFBtYa1RAAJTt9/8L57FKuzLqhAEPgBej9ySw62Z2yf74tcT1pauB0zcPVtG5WNWq 4bsA== X-Gm-Message-State: APt69E2Mvj8BqhNWTFiv3/5ew+ctTEueMSev9ueB5PmJQLSpfx3fvikR oCxXWpl/4rFp/qTk2WEdA2JlIwtoU3U= X-Received: by 2002:a50:944f:: with SMTP id q15-v6mr3372612eda.70.1530719362844; Wed, 04 Jul 2018 08:49:22 -0700 (PDT) Received: from ards-mac-mini.arnhem.chello.nl (dhcp-077-251-017-237.chello.nl. [77.251.17.237]) by smtp.gmail.com with ESMTPSA id l61-v6sm1966954edl.96.2018.07.04.08.49.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 08:49:21 -0700 (PDT) From: Ard Biesheuvel To: linux-efi@vger.kernel.org Cc: linux-acpi@vger.kernel.org, leif.lindholm@linaro.org, mark.rutland@arm.com, will.deacon@arm.com, catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, Ard Biesheuvel , Mark Salter , Geoff Levand , Lorenzo Pieralisi , Hanjun Guo , Sudeep Holla , Riku Voipio , James Morse , Ian Campbell Subject: [RFC PATCH 0/2] efi: add contents of LinuxExtraArgs EFI var to command line Date: Wed, 4 Jul 2018 17:49:17 +0200 Message-Id: <20180704154919.18564-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.17.1 Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org As noted by Ian, many DMI based quirks for x86 ACPI machines disable features that can also be disabled via the kernel command line. Similarly, a quirk is under discussion for a arm64 ACPI machine [0] that explodes when enabling support for hardware error reporting via the ACPI HEST table. When support for DMI tables was introduced to arm64 and ARM, the agreement was that they are informational only, i.e., provided to userland to describe the platform, not for keying off of to enable quirks in the kernel. There are a couple of reasons for this: - Unlike the x86 architecture, where virtually all platforms are PC variants, and the presence of ACPI and DMI tables may be assumed, the arm64 architecture is much more heterogeneous, and none of UEFI, ACPI or DMI or actually mandated or especially common across arm64 platforms; using DMI only makes sense for working around a limited subset of platform issues that have to do with firmware running on platforms that bother to implement it in the first place. - DMI is not initialized as early as it is on x86, and doing so is not trivial. This means that even on ACPI/DMI machines, some issues may require quirks that are enabled in a different way, or we need to refactor the DMI support so that we can enable it as early as x86 does. - Using DMI tables fundamentally means quirking *after* the fact, which makes it a moving target. Some quirks may require the DMI match table to be updated if someone happens to change a string in the DMI tables when shipping a mostly identical platform. So instead, let's provide these platforms with the facilities required to enable such quirks at the platform level. Especially for UEFI systems, if upgrading firmware is a reasonable prerequisite for being able to upgrade to the latest kernel, having to run a script that sets a UEFI variable (either via the Linux command line of from the UEFI shell) should not be an unreasonable requirement either, and so we can solve part of this issue by configuring extra command line arguments persistenly from the firmware environment. This solves all the above issues in an unintrusive manner, given that the kernel command line is already made available extremely early in the boot, and the fact that it already permits a wide range of configuration options and overrides to be set, including the 'hest_disable=1' option that works around the issue addressed by [0]. Note that this deviates from the current common practice on x86. I am aware that the distros want everything to be the same in this regard, but I don't think the x86 maintainers will refer to the DMI quirks infrastructure as a shining example of functionality that should be ported across architectures. ACPI on arm64 is intended to support a narrowly defined class of server systems, as opposed to the wide range of Windows-logo hardware that arch/x86 aims to support, and a lot of time and effort has been going into validation against Linux itself. This means the likelihood that we will need a quirks infrastructure as elaborate as the x86 one is low, and so it would be my preference to defer introducing it until the moment where we have exhausted all other options. [0] https://marc.info/?l=linux-acpi&m=153018042727125&w=2 Cc: Mark Salter Cc: Geoff Levand Cc: Lorenzo Pieralisi Cc: Hanjun Guo Cc: Sudeep Holla Cc: Riku Voipio Cc: James Morse Cc: Ian Campbell Ard Biesheuvel (2): efi/libstub: refactor load option command line processing for reuse efi/libstub: taken contents of LinuxExtraArgs UEFI variable into account .../firmware/efi/libstub/efi-stub-helper.c | 94 +++++++++++++++---- include/linux/efi.h | 1 + 2 files changed, 77 insertions(+), 18 deletions(-) -- 2.17.1 -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html