From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C97C6C433E6 for ; Tue, 16 Mar 2021 08:27:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9EE0F65006 for ; Tue, 16 Mar 2021 08:27:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234794AbhCPI11 (ORCPT ); Tue, 16 Mar 2021 04:27:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58096 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234769AbhCPI1J (ORCPT ); Tue, 16 Mar 2021 04:27:09 -0400 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37749C06174A for ; Tue, 16 Mar 2021 01:27:09 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id w18so20440861edc.0 for ; Tue, 16 Mar 2021 01:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=3CLf59KGSjWUQb8ryREHzVKvbUGjsmxFO7bkVEZRsGc=; b=VTDQBGqkCkUmUjwq0Mnb618wkTUj6+3rVA/WFIqw+sR0+INRhP0urmFGxfIkcF7hjI 8ra7BPp6vxY0FJoy8DP0VNlqhQ3cBkmwk8TG6yw1vvy9HMJbgV8YdrK3DXlFp/mcfv5p jyWLzz0oElNnjut7DcROb/H6bU6lRfjIqlygJI8xoQ3TmopL+ZGriOhSba2GIuMZSvyY 6UOmk8MjR4dZ4AnaeGcuCrC8i9kl3FB6Qz1ptJ3T/o+/n8ahYNUwmuj7Q63rgln3eHXg qhWD+6pP09BI5uMP1xatAqCxLkMrlgrCvITE3jKiQubSHfaXlhPw9Vsz2wwX8EXnJhGs xn1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=3CLf59KGSjWUQb8ryREHzVKvbUGjsmxFO7bkVEZRsGc=; b=cJCnxeIIm+eiw8K1tDr3ig2a4oFHqbAOehWGWWXBy5kvMBUc6PJY8UMlhvmSrtzHkF Qf/WZSwRD0HzuJrHYXnjyESLa+XCevi1wQ2FSdRMUb0rJbyN5reBCz6m0hp81r3wR4i8 FoxzHTMUzxF9CENsrwwVK2QbAAzPOjUptn27ixCU+yEAiRkCYSwb2YFMuRuVa7e25bxb kguRfCxdu/NPWOT/rCAGAg5XQYKxyfSW3GZdswSkH4RgTDuKj4DEqt22G143+0kQQsp1 /pCDjcyu+p3IoMWUsy8jEC4Vm0+UXOj4WgCDwvSieR8Ae2wq4hJE9FcSqTz5/nXFw5Hg dVhg== X-Gm-Message-State: AOAM5313OIvCnoUly9xeaglED57dn0MYG4jUvyyNON7WUqS1sBY43grX qveQ8v86YBBK9fA/wRkuL2CjxA== X-Google-Smtp-Source: ABdhPJyCCzgwkT84nB+lCeOlEEZy0yZaq2CFScXPw+tnsBDYmRqOzLG+O1WMLhU+gNZhnU22QmSZAg== X-Received: by 2002:a05:6402:1649:: with SMTP id s9mr34635755edx.177.1615883227921; Tue, 16 Mar 2021 01:27:07 -0700 (PDT) Received: from enceladus (ppp-94-64-113-158.home.otenet.gr. [94.64.113.158]) by smtp.gmail.com with ESMTPSA id t6sm9836888edq.48.2021.03.16.01.27.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Mar 2021 01:27:07 -0700 (PDT) Date: Tue, 16 Mar 2021 10:27:04 +0200 From: Ilias Apalodimas To: Ard Biesheuvel Cc: Heinrich Schuchardt , Shawn Guo , Atish Patra , Steve McIntyre , Rob Clark , linux-efi , Jeffrey Hugo , Bjorn Andersson , Leif Lindholm , linux-arm-msm Subject: Re: [PATCH] efi: stub: override RT_PROP table supported mask based on EFI variable Message-ID: References: <20210309032248.GR17424@dragon> <20210315031119.GY17424@dragon> <81899e5a-ab6d-69a2-c172-535300b3ce02@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Tue, Mar 16, 2021 at 09:14:22AM +0100, Ard Biesheuvel wrote: > On Tue, 16 Mar 2021 at 09:04, Ilias Apalodimas > wrote: > > > > Hi Ard, > > > > On Tue, Mar 16, 2021 at 08:52:52AM +0100, Ard Biesheuvel wrote: > > > On Tue, 16 Mar 2021 at 08:42, Heinrich Schuchardt wrote: > > > > > ... > > > > looking at this thread it is hard to understand why this patch should be > > > > needed. > > > > > > > > If an UEFI application does not want to consume a service, it can do so > > > > without having to manipulate the RT properties table. > > > > > > > > Which UEFI applications are broken? Why can't they be fixed instead of > > > > patching the kernel? > > > > > > > > Can we have complete descriptions of the deficiencies of the involved > > > > applications. I saw GRUB and the Debian installer mentioned in the > > > > thread. Are there others? > > > > > > > > > > The problem is that the proprietary EDK2 / UEFI firmware on Qualcomm > > > Snapdragon based laptops that were built to run Windows does not > > > implement get/setvariable after ExitBootServices. Instead, every call > > > to any of the variable services returns with an EFI_UNSUPPORTED error. > > > > > > The correct way to address this is a RT_PROP table that encodes this > > > behavior, and this is what we added in the special DtbLoader driver > > > that is used to boot Linux in DT mode (as the firmware only implements > > > ACPI support). So for systems that can/will run DtbLoader, the problem > > > is solved. > > > > > > What remains is ACPI boot, or boot modes where DtbLoader does not > > > work. In those cases, it would be useful to have another way to convey > > > this information to the OS in a way that does not rely on the kernel > > > command line. > > > > > > But thinking about this, perhaps we should be fixing this in > > > efibootmgr instead. EFI_UNSUPPORTED is a valid and documented return > > > code that conveys that the operation did not fail with an error, but > > > that efibootmgr is not supported to begin with on the platform in > > > question. > > > > It all depends on how smart we want to make the efi stub. In essence > > it's an OS loader, that we have complete control over and we can play tricks > > on broken/incompatible firmwares, but is that what we want ? And if yes, were > > do we draw the line of what we fix or not? > > > > I think the current problem doesn't make a strong case to add such > > functionality. U-Boot doesn't expose SetVariable at all, but even if it did > > and returned EFI_UNSUPPORTED, I'd expect the consuming applications to handle > > the error gracefully. I mean why should we treat EFI_UNSUPPORTED differently > > than EFI_DEVICE_ERROR or EFI_INVALID_PARAMETER (or all the allowed return > > codes)? > > > > EFI_DEVICE_ERROR or EFI_INVALID_PARAMETER means that the particular > call resulted in an error, which may be related to the values of the > arguments, the state of the the flash, etc etc > > EFI_UNSUPPORTED means that the platform in question does not support > the routine at all at runtime, and the arguments or the context is > irrelevant. By differently I implied 'not handle the error correctly'. So my point was that an application must handle all errors that are allowed from the spec. Not select the ones it prefers in a meaningfull way. Which brings us to your next point. > > Given that GRUB already tolerates the second condition, but only if it > is communicated explicitly (via --no-nvram) or implicitly when > efivarfs is absent altogether, I am saying that we should classify a > EFI_UNSUPPORTED return value in the same way, and tolerate it rather > than abort the install. +1 Thanks /Ilias