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 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 17C0AC433E9 for ; Tue, 16 Mar 2021 09:34:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B78B96501C for ; Tue, 16 Mar 2021 09:34:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231719AbhCPJdi (ORCPT ); Tue, 16 Mar 2021 05:33:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44144 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230469AbhCPJd2 (ORCPT ); Tue, 16 Mar 2021 05:33:28 -0400 Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 98FACC061756 for ; Tue, 16 Mar 2021 02:33:27 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id x13so7052838wrs.9 for ; Tue, 16 Mar 2021 02:33:27 -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=et+1ZvQ1+gasZwQhD3sG15pwfg1DAlDgsMAObHI9SQI=; b=k99Do/ibQk6c/NeYMaFi2pLZspwXBRoXXnd+ayQ866j02kvxP0Dy61E3vKnhUHIpja H2Cxt1DZF4Isz1Wd5Ks+0N4EbahzVdyAV4nL3LOuxdDzRw/jmeEpKzIUqFllHM4Fwp1q HGbSvdv+hO1csv2Yb8v1m2z/4ipV07iilUv7aCouBpnwqODHCRNXmssR8RkHBDMtnGiG 1ksg2nSfKlp40tyklN/Dca+BIwmLb3TBnxvT9h10Q+/FTYSyoUT3sI2U/oXtAfLSsnPW DSNjfejurNhf/X/1V9avo4d5mYsqPBPOqKyP6fGKjpHgx6S+pXfUTrWWXcgQ2BfcLdn4 EDHw== 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=et+1ZvQ1+gasZwQhD3sG15pwfg1DAlDgsMAObHI9SQI=; b=EwNjRulKIOzYLs543S+zJxvyMd1jYu4igj2Mx64cT13I6syrp0fL2zWlYSCNRiJimO jYWz5yipSM9LJi3FsBJ7oKStbX1cWvw6AW9KSAueANWkggVusCI8VHEYuDBqdKPRLBLU x21V8bqdtjqnUDmS007DtwKpfUECMQAJ1C26rn4k5MFvtuk5UJcVsCjJg8WUbHPVNMED rAk/EaHZDPEwJo9A3ua7a+vfTPo1oJVPt6sKqRLMuDUtD6sexMaLDxy6ntxn8LrF7jzM +cCmw6idQHOzm8wdlqJw/ssD5ZtoF7luV3fh1n9a/GL+ICF/YzumUYnCtEU8P1AwzDhc TE5A== X-Gm-Message-State: AOAM531k+o3CZzkXm/nReRfQHgDHA4Kb9TsewSWZUBcPj8OEAPcsBlJS +HK2hIXgSKCMaXR2upFQK/kt0A== X-Google-Smtp-Source: ABdhPJwC7HGrtfYKqXfX6qEl85FnHRO39oFh9Nz9/qnNUfk813kz4MXo5GBFHdlgOiZGGGeuQvqgrA== X-Received: by 2002:adf:84e6:: with SMTP id 93mr3678452wrg.376.1615887206246; Tue, 16 Mar 2021 02:33:26 -0700 (PDT) Received: from enceladus (ppp-94-64-113-158.home.otenet.gr. [94.64.113.158]) by smtp.gmail.com with ESMTPSA id w11sm22899048wrv.88.2021.03.16.02.33.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Mar 2021 02:33:25 -0700 (PDT) Date: Tue, 16 Mar 2021 11:33:23 +0200 From: Ilias Apalodimas To: Shawn Guo Cc: Ard Biesheuvel , Heinrich Schuchardt , 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: <20210307110228.GP17424@dragon> <20210309032248.GR17424@dragon> <20210315031119.GY17424@dragon> <20210316075214.GA32651@dragon> <20210316090609.GB32651@dragon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210316090609.GB32651@dragon> Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Hi Shawn, > > > > > > So an installer either needs to set the EFI variable, or pass > > > > > > efi=novamap on the first boot. Note that there are no arm64 EFI > > > > > > systems known where efi=novamap causes problems. In fact, I would > > > > > > prefer to stop using SetVirtualAddressMap() altogether, as it does not > > > > > > provide any benefit whatsoever. So perhaps we should make efi=novamap > > > > > > the default and be done with it. > > > > > > > > > > > > Broken poweroff is hardly a showstopper for an installer, given that > > > > > > we cannot even install GRUB correctly. > > > > > > > > > > > > In summary, I am more than happy to collaborate constructively on this > > > > > > (which is why I wrote the patch), but I don't think we're at a point > > > > > > yet where this is the only thing standing in our way when it comes to > > > > > > a smooth out-of-the-box Linux installation experience. > > > > > > > > > > There might be more to be done for getting a smooth Linux installation > > > > > experience. But IMHO, this `OverrideSupported` thing is definitely > > > > > a big step to that. > > > > > > > > > > > > > So the problem here seems to be that grub-install (or efibootmgr) > > > > tolerates efivarfs being absent entirely, but bails out if it exists > > > > but gives an error when trying to access it, right? > > > > > > Yes, with EFI variables runtime service marked as unsupported, > > > efibootmgr will just exit on efi_variables_supported() check [1] in > > > a way that its parent process, i.e. grub-install, doesn't take as an > > > error. But otherwise, efibootmgr will go much further and exit with > > > a real error when trying to access efivars. > > > > > > > OK, so I suggest we fix efibootmgr, by extending the > > efi_variables_supported() check to perform a GetVariable() call on an > > arbitrary variable (e.g., BootOrder), > > Hmm, I'm not sure we should ask more from user space, as it's already > been doing the right thing, and efi_variables_supported() is proved to > work properly with any sane low-level software (kernel + firmware), > either EFI variables service is supported or not. That said, IMHO, > right now the low-level software on Snapdragon laptops is insane, i.e. > the unsupported/broken EFI runtime services are not communicated to > user space properly in established way. But the EFI_UNSUPPORTED is an error that's allowed from the spec. Yes the sane thing to do is not expose it at all, but it's not violating any spec by doing so. So why shouldn't a userspace application be able to handle all return codes explicitly and instead treat them as a single error? And when that happens why should the kernel mask that error out for it? Thanks /Ilias > > Shawn > > > and treat EFI_UNSUPPORTED as a > > special case that means that carrying on is pointless. > > > > (but someone please confirm that the snapdragon efi firmware does > > return EFI_UNSUPPORTED and not some other return value when calling > > GetVariable() from under the OS)