Message ID | 20230119164255.28091-1-johan+linaro@kernel.org |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp435942wrn; Thu, 19 Jan 2023 08:56:54 -0800 (PST) X-Google-Smtp-Source: AMrXdXtz3uq7twRb0QcSXoAIGKxzKqdJfb6zddeeKNcldpu/H2GpzQcK4nTX0GO367dJt+2CtfIY X-Received: by 2002:a17:907:7424:b0:872:a754:da73 with SMTP id gj36-20020a170907742400b00872a754da73mr9711246ejc.63.1674147414450; Thu, 19 Jan 2023 08:56:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674147414; cv=none; d=google.com; s=arc-20160816; b=Ki1MwP1oTiAReL0uiAQNuTKpob7dfIh64lmZfHuT/iex1PoStgSCTw4vv/YTJFS8pD 3IjvbZF9DyjafzVWiIEA8wlKboBGyn13lESvt1rWLACikI+GkLdCiUBq+N5YMhHljhNr kIePPBtYDhU6IN8OCRUxeEaHgQOddUBlEAsiLlSERuD7qdAbYTV7wifhXa5BrY1Tw6fW g1JUDfuz79hX4CsuGN1oZbrMQQelIAjUE7WHcafHG40gHS557kfYcrs0K1y1tUhBEftY xQt61IO4f8gOa9FYMRZacpusQitavX7dmGIzUtsJBvHs5sCOSwq8YkwgIHNAqrvZk/t+ A3uQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=FY3JluP2yGUNWoU7nWuKR3Pfqh9uMYL3hdZrcZr5quw=; b=uVTVvqv23wkrf6bSJEx9o4i2KwG6jlR74KxkLTT3vgRPoXvwTtu/y+7k2+ckaN5wwk XPKOaMf4BCETRHWyE0457smO2KbC+2tJqs+s5e1xYGT9bXhv09Upb+lTgl4EHhQE9KhG H4d9zHU7VPsOT4kfIw19j2p9tbAHy2pm196IBazi8FsCuHPaHJhP9OljxuVi2fl4frh7 mpG6EgxlEsk1tApfQYMIOr8wyLxEdbyCIovBy4FoaIgCMmye5WCQul7aPEClxqyYc2Fo RXdVFdN+Pf49y2nboZ3m+x/nX4S9xPAYLKrRTVbA/lgPRfxpww8AXilzZJ2Y5Ia3vEWw FErA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=iJ9DCWPj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s2-20020a17090699c200b0086fedd36776si16414308ejn.823.2023.01.19.08.56.31; Thu, 19 Jan 2023 08:56:54 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=iJ9DCWPj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230391AbjASQpy (ORCPT <rfc822;pfffrao@gmail.com> + 99 others); Thu, 19 Jan 2023 11:45:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39170 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230390AbjASQpu (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 19 Jan 2023 11:45:50 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F323C4E52D; Thu, 19 Jan 2023 08:45:48 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8FB3161CCD; Thu, 19 Jan 2023 16:45:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EFE99C433EF; Thu, 19 Jan 2023 16:45:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1674146748; bh=SynuDDILfehL2T8hvUkrH01rNlfRaPkey2aIBkXZnIs=; h=From:To:Cc:Subject:Date:From; b=iJ9DCWPjBFu5yEWCcak1CL+EvQGhTSwSldgFj5QwVliquZTANRSw0CJPZ0dFqMmlm x2ttvAu6Jy2sBJUe1EKKHQ0gFWIxHUqPNX4vmEuba4++L02zRzsMiEnWXUIv6F0QWw DPicR+diMSuXSLonCl3ZkbgLmtcX2Y4qnyHkYaYjWFl2LUuIICnlm+1lXcpSIJvv9F b62ggmHkAHEiDshlDaYITgY5inU1WnwIR4i8uDJNqbaiI9uwUknWsCkc290+7WOK9/ GpuOStTndQW1irU3aU5XJgZrHktrGDgg9q/sJ5MSPXWVauk79WtCrstyhvIKCJd136 y+6rzIY3Afekw== Received: from johan by xi.lan with local (Exim 4.94.2) (envelope-from <johan+linaro@kernel.org>) id 1pIY3L-0007Mp-UA; Thu, 19 Jan 2023 17:46:16 +0100 From: Johan Hovold <johan+linaro@kernel.org> To: Ard Biesheuvel <ardb@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org>, Jeremy Kerr <jk@ozlabs.org>, Maximilian Luz <luzmaximilian@gmail.com>, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, Johan Hovold <johan+linaro@kernel.org> Subject: [PATCH 0/4] efi: verify that variable services are supported Date: Thu, 19 Jan 2023 17:42:51 +0100 Message-Id: <20230119164255.28091-1-johan+linaro@kernel.org> X-Mailer: git-send-email 2.38.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1755470799327381840?= X-GMAIL-MSGID: =?utf-8?q?1755470799327381840?= |
Series |
efi: verify that variable services are supported
|
|
Message
Johan Hovold
Jan. 19, 2023, 4:42 p.m. UTC
This series adds a sanity check to make sure that the variable services are actually available before registering the generic efivar ops. This is used to address some potential races with custom efivars implementation such as the Google SMI or upcoming Qualcomm SCM ones. Specifically, efivarfs currently requires that the efivar ops have been registered before module init time even though the Google driver can be built as a module. Instead, the driver has so far relied on the fact that the generic ops have been registered by efi core only to later be overridden by the custom implementation (or Google doesn't use efivarfs). Instead, let's move the efivars sanity check to mount time to allow for late registration of efivars. Note that requiring that all efivars implementation to always be built-in and registered before module init time could be an alternative, but we'd still need to make sure that the custom implementation is then not overridden by the default (broken) one. To avoid such init call games, allowing late registration seems preferable. This would however require any drivers that use efivars to probe defer until it becomes available, which is also unfortunate, but possibly still better than having generic kernels carry multiple built-in efivars implementations. Note that there are currently no such (efivars consumer) drivers in-tree except for the efivars_pstore driver, which currently do rely on efivarfs being available at module init time (and hence may fail to initialise with the custom efivar implementations). Johan Johan Hovold (4): efi: efivars: add efivars printk prefix efivarfs: always register filesystem efi: verify that variable services are supported efi: efivars: prevent double registration drivers/firmware/efi/efi.c | 22 ++++++++++++++++++++++ drivers/firmware/efi/vars.c | 17 ++++++++++++++--- fs/efivarfs/super.c | 6 +++--- 3 files changed, 39 insertions(+), 6 deletions(-)
Comments
On Thu, 19 Jan 2023 at 17:45, Johan Hovold <johan+linaro@kernel.org> wrote: > > This series adds a sanity check to make sure that the variable services > are actually available before registering the generic efivar ops. > > This is used to address some potential races with custom efivars > implementation such as the Google SMI or upcoming Qualcomm SCM ones. > > Specifically, efivarfs currently requires that the efivar ops have been > registered before module init time even though the Google driver can be > built as a module. Instead, the driver has so far relied on the fact > that the generic ops have been registered by efi core only to later be > overridden by the custom implementation (or Google doesn't use > efivarfs). > > Instead, let's move the efivars sanity check to mount time to allow for > late registration of efivars. > > Note that requiring that all efivars implementation to always be > built-in and registered before module init time could be an alternative, > but we'd still need to make sure that the custom implementation is then > not overridden by the default (broken) one. To avoid such init call > games, allowing late registration seems preferable. > > This would however require any drivers that use efivars to probe defer > until it becomes available, which is also unfortunate, but possibly > still better than having generic kernels carry multiple built-in efivars > implementations. > > Note that there are currently no such (efivars consumer) drivers in-tree > except for the efivars_pstore driver, which currently do rely on > efivarfs being available at module init time (and hence may fail to > initialise with the custom efivar implementations). > > Johan > > > Johan Hovold (4): > efi: efivars: add efivars printk prefix > efivarfs: always register filesystem > efi: verify that variable services are supported > efi: efivars: prevent double registration > Queued up in efi/next - thanks. > drivers/firmware/efi/efi.c | 22 ++++++++++++++++++++++ > drivers/firmware/efi/vars.c | 17 ++++++++++++++--- > fs/efivarfs/super.c | 6 +++--- > 3 files changed, 39 insertions(+), 6 deletions(-) > > -- > 2.38.2 >