Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #67585

Bug#963033: linux-image-arm64: kexec loses EFI system tables with Debian kernels

Path csiph.com!weretis.net!feeder7.news.weretis.net!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod
From Uwe Kleine-König <uwe@kleine-koenig.org>
Newsgroups linux.debian.bugs.dist, linux.debian.kernel
Subject Bug#963033: linux-image-arm64: kexec loses EFI system tables with Debian kernels
Date Wed, 22 Jul 2020 21:30:01 +0200
Message-ID <AvsBb-s0-5@gated-at.bofh.it> (permalink)
References <AiUOC-1Ho-1@gated-at.bofh.it> <Am3iF-1ZE-9@gated-at.bofh.it> <AiUOC-1Ho-1@gated-at.bofh.it> <Am3iF-1ZE-9@gated-at.bofh.it>
X-Original-To Gabriel Krisman Bertazi <krisman@collabora.com>, 963033@bugs.debian.org
X-Mailbox-Line From debian-bugs-dist-request@lists.debian.org Wed Jul 22 19:21:09 2020
Old-Return-Path <debbugs@buxtehude.debian.org>
X-Spam-Flag NO
X-Spam-Score -0.45
Reply-To Uwe Kleine-König <uwe@kleine-koenig.org>, 963033@bugs.debian.org
Resent-To debian-bugs-dist@lists.debian.org
Resent-Cc Debian Kernel Team <debian-kernel@lists.debian.org>
X-Debian-Pr-Message followup 963033
X-Debian-Pr-Package src:linux
X-Debian-Pr-Source linux
X-Spam-Bayes score:0.0000 Tokens: new, 56; hammy, 150; neutral, 138; spammy, 0. spammytokens: hammytokens:0.000-+--H*UA:1.10.1, 0.000-+--H*u:1.10.1, 0.000-+--H*UA:2018-07-13, 0.000-+--H*u:2018-07-13, 0.000-+--sizeof
MIME-Version 1.0
Content-Type multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO"
Content-Disposition inline
User-Agent Mutt/1.10.1 (2018-07-13)
X-Greylist delayed 364 seconds by postgrey-1.36 at buxtehude; Wed, 22 Jul 2020 19:17:25 UTC
X-Debian-Message from BTS
X-Mailing-List <debian-bugs-dist@lists.debian.org> archive/latest/1615019
List-ID <debian-bugs-dist.lists.debian.org>
List-URL <https://lists.debian.org/debian-bugs-dist/>
Approved robomod@news.nic.it
Lines 140
Organization linux.* mail to news gateway
Sender robomod@news.nic.it
X-Original-Date Wed, 22 Jul 2020 21:11:15 +0200
X-Original-Message-ID <20200722191115.GA28942@taurus.defre.kleine-koenig.org>
X-Original-References <159245605342.407.6332206929547963206.reportbug@debian> <874kqx7ei3.fsf@collabora.com> <159245605342.407.6332206929547963206.reportbug@debian> <874kqx7ei3.fsf@collabora.com>
Xref csiph.com linux.debian.bugs.dist:1018929 linux.debian.kernel:67585

Cross-posted to 2 groups.

Show key headers only | View raw


[Multipart message — attachments visible in raw view] - view raw

Hello,

On Fri, Jun 26, 2020 at 04:34:28PM -0400, Gabriel Krisman Bertazi wrote:
> Hi,
> 
> This is introduced by a Debian specific patch
> features/all/lockdown/arm64-add-kernel-config-option-to-lock-down-when.patch
> 
> The following patch fixes it.

Note, I'm not an expert in the area this patch modifies, just some
general feedback.
 
> >8
> From: Gabriel Krisman Bertazi <krisman@collabora.com>
> Subject: [PATCH] arm64: Don't disable EFI boot mode on linux,uefi-secure-boot
>  table absence
> 
> The Debian specific out-of-tree kernel patch titled ("arm64: add kernel
> config option to lock down when in Secure Boot mode") introduces a
> regression for EFI-booted systems that don't have a
> "linux,uefi-secure-boot" FDT entry.
> 
> In these systems, when the table is not found, it causes the FDT
> function to error out and not return other UEFI tables, in particular
> the System Table, which makes the kernel think it is not running on EFI
> mode.
> 
> Instead, let the EFI mode boot continue with the correct System Table,
> and consider the efi secureboot mode as unknown.
> 
> This regression was found at least as early as the debian port to 5.4.19,
> but it still affects the most recent 5.7.6 debian kernel.
> 
> Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
> ---
>  drivers/firmware/efi/arm-init.c  |  2 +-
>  drivers/firmware/efi/fdtparams.c | 18 +++++++++++-------
>  2 files changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
> index 78fcfbe3ddb9..fcb60320e77a 100644
> --- a/drivers/firmware/efi/arm-init.c
> +++ b/drivers/firmware/efi/arm-init.c
> @@ -206,7 +206,7 @@ void __init efi_init(void)
>  {
>  	struct efi_memory_map_data data;
>  	u64 efi_system_table;
> -	u32 secure_boot;
> +	u32 secure_boot = efi_secureboot_mode_unknown;
>  
>  	/* Grab UEFI information placed in FDT by stub */
>  	efi_system_table = efi_get_fdt_params(&data, &secure_boot);

I'd prefer to have the assignment in efi_get_fdt_params.

> diff --git a/drivers/firmware/efi/fdtparams.c b/drivers/firmware/efi/fdtparams.c
> index 152ca7cfccc9..78c36e582408 100644
> --- a/drivers/firmware/efi/fdtparams.c
> +++ b/drivers/firmware/efi/fdtparams.c
> @@ -96,13 +96,15 @@ u64 __init efi_get_fdt_params(struct efi_memory_map_data *mm, u32 *secure_boot)
>  	struct {
>  		void	*var;
>  		int	size;
> +		int	required;
> +
>  	} target[] = {
> -		[SYSTAB] = { &systab,		sizeof(systab) },
> -		[MMBASE] = { &mm->phys_map,	sizeof(mm->phys_map) },
> -		[MMSIZE] = { &mm->size,		sizeof(mm->size) },
> -		[DCSIZE] = { &mm->desc_size,	sizeof(mm->desc_size) },
> -		[DCVERS] = { &mm->desc_version,	sizeof(mm->desc_version) },
> -		[SBMODE] = { secure_boot,       sizeof(*secure_boot) },
> +		[SYSTAB] = {&systab,		sizeof(systab),	1},
> +		[MMBASE] = {&mm->phys_map,	sizeof(mm->phys_map), 1},
> +		[MMSIZE] = {&mm->size,		sizeof(mm->size), 1},
> +		[DCSIZE] = {&mm->desc_size,	sizeof(mm->desc_size), 1},
> +		[DCVERS] = {&mm->desc_version,	sizeof(mm->desc_version), 1},
> +		[SBMODE] = {secure_boot,	sizeof(*secure_boot), 0 },

Is the whitespace change intended here? I wonder if it would be easier
to drop this hunk and ...

>  	};
>  
>  	BUILD_BUG_ON(ARRAY_SIZE(target) != ARRAY_SIZE(name));
> @@ -125,8 +127,10 @@ u64 __init efi_get_fdt_params(struct efi_memory_map_data *mm, u32 *secure_boot)
>  				continue;
>  			if (!j)
>  				goto notfound;
> +
>  			pr_err("Can't find property '%s' in DT!\n", pname);
> -			return 0;
> +			if (target[j].required)
> +				return 0;

... do here

		if (j != SBMODE)
			return 0;

here.

Is it right that a missing linux,uefi-secure-boot property still results
in a pr_err?

I wonder what the upstream status of the broken patch is.

Best regards
Uwe

Back to linux.debian.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Bug#963033: linux-image-arm64: kexec loses EFI system tables with Debian kernels Da Xue <da+debianbug@lessconfused.com> - 2020-06-18 07:00 +0200
  Bug#963033: linux-image-arm64: kexec loses EFI system tables with Debian kernels Gabriel Krisman Bertazi <krisman@collabora.com> - 2020-06-26 22:40 +0200
    Bug#963033: linux-image-arm64: kexec loses EFI system tables with Debian kernels Uwe Kleine-König <uwe@kleine-koenig.org> - 2020-07-22 21:30 +0200
      Bug#963033: linux-image-arm64: kexec loses EFI system tables with Debian kernels Gabriel Krisman Bertazi <krisman@collabora.com> - 2020-07-22 21:40 +0200
        Bug#963033: linux-image-arm64: kexec loses EFI system tables with Debian kernels Romain Perier <romain.perier@gmail.com> - 2020-07-24 15:20 +0200

csiph-web