From patchwork Wed Oct 16 21:50:54 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg Kroah-Hartman X-Patchwork-Id: 11194485 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id B16011575 for ; Wed, 16 Oct 2019 21:59:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 919C6222CD for ; Wed, 16 Oct 2019 21:59:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1571263142; bh=IBDqXUFTgvbXNtgLNo86W8OOy+sVrhGFPMnCyefn4gQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=JOLjTawBLo8dYexOEDIGW5k8BslqImsnZnTk1RmhAMypYg+M3GQtGIiiECm4xgO0i cUITRSsFJIkIF6p8VTPFYXDl82ytx5PqUHtr7KMOrLHiis4aOy1T+gQiNIEur8YDJf XAJpOM7yu0w7/Wba3dmAwxRKxgJ5KQv5STSIYyyk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2438360AbfJPV7B (ORCPT ); Wed, 16 Oct 2019 17:59:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:53068 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404003AbfJPV7A (ORCPT ); Wed, 16 Oct 2019 17:59:00 -0400 Received: from localhost (unknown [192.55.54.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CB93C20872; Wed, 16 Oct 2019 21:58:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1571263139; bh=IBDqXUFTgvbXNtgLNo86W8OOy+sVrhGFPMnCyefn4gQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=1lGijWaR5W7UTOBc8W9DUqk8PIlsdiUmnai0zzDrJIXL4+3nlt1XbqKjQdl47wLMF rA5dh6XEyHf7XidWUWniQwfvkdDitqdI3XK15MtX9n9YDHEUMbDzZZ5paM9GaDyEY+ lYP0i5h7weEybKsY2dCYZrg7iobiSfq4Gsaev/AQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Scott Talbert , Ard Biesheuvel , Ben Dooks , Dave Young , Jarkko Sakkinen , Jerry Snitselaar , Linus Torvalds , Lukas Wunner , Lyude Paul , Matthew Garrett , Octavian Purdila , Peter Jones , Peter Zijlstra , Thomas Gleixner , linux-efi@vger.kernel.org, linux-integrity@vger.kernel.org, Ingo Molnar Subject: [PATCH 5.3 062/112] efivar/ssdt: Dont iterate over EFI vars if no SSDT override was specified Date: Wed, 16 Oct 2019 14:50:54 -0700 Message-Id: <20191016214900.840734790@linuxfoundation.org> X-Mailer: git-send-email 2.23.0 In-Reply-To: <20191016214844.038848564@linuxfoundation.org> References: <20191016214844.038848564@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org From: Ard Biesheuvel commit c05f8f92b701576b615f30aac31fabdc0648649b upstream. The kernel command line option efivar_ssdt= allows the name to be specified of an EFI variable containing an ACPI SSDT table that should be loaded into memory by the OS, and treated as if it was provided by the firmware. Currently, that code will always iterate over the EFI variables and compare each name with the provided name, even if the command line option wasn't set to begin with. So bail early when no variable name was provided. This works around a boot regression on the 2012 Mac Pro, as reported by Scott. Tested-by: Scott Talbert Signed-off-by: Ard Biesheuvel Cc: # v4.9+ Cc: Ben Dooks Cc: Dave Young Cc: Jarkko Sakkinen Cc: Jerry Snitselaar Cc: Linus Torvalds Cc: Lukas Wunner Cc: Lyude Paul Cc: Matthew Garrett Cc: Octavian Purdila Cc: Peter Jones Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Cc: linux-integrity@vger.kernel.org Fixes: 475fb4e8b2f4 ("efi / ACPI: load SSTDs from EFI variables") Link: https://lkml.kernel.org/r/20191002165904.8819-3-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- drivers/firmware/efi/efi.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -282,6 +282,9 @@ static __init int efivar_ssdt_load(void) void *data; int ret; + if (!efivar_ssdt[0]) + return 0; + ret = efivar_init(efivar_ssdt_iter, &entries, true, &entries); list_for_each_entry_safe(entry, aux, &entries, list) {