linux-kernel - Re: [regression, bisected] x86: efi: Pass boot services variable info to runtime code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 30 May 2013 00:22:13 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Russ Anderson <rja@....com>
Cc:	Matt Fleming <matt@...sole-pimps.org>,
	Matthew Garrett <matthew.garrett@...ula.com>,
	matt.fleming@...el.com, linux-efi@...r.kernel.org, x86@...nel.org,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [regression, bisected] x86: efi: Pass boot services variable
 info to runtime code

On Wed, 29 May 2013, Russ Anderson wrote:

> > What appears to be happening is that your the EFI runtime services code
> > is calling into the EFI boot services code, which is definitely a bug in
> > your firmware because we're at runtime, but we've seen other machines
> > that do similar things so we usually handle it just fine. However, what
> > makes your case different, and the reason you see the above splat, is
> > that it's using the physical address of the EFI boot services region,
> > not the virtual one we setup with SetVirtualAddressMap(). Which is a
> > second firmware bug. Again, we have seen other machines that access
> > physical addresses after SetVirtualAddressMap(), but until now we
> > haven't had any non-optional code that triggered them.
> > 
> > The only reason I can see that the offending commit would introduce this
> > problem is because it calls QueryVariableInfo() at boot time. I notice
> > that your machine is an SGI UV one, is there any chance you could get a
> > firmware fix for this? If possible, it would be also good to confirm
> > that it's this chunk of code in setup_efi_vars(),
> > 
> > 	status = efi_call_phys4(sys_table->runtime->query_variable_info,
> > 				EFI_VARIABLE_NON_VOLATILE |
> > 				EFI_VARIABLE_BOOTSERVICE_ACCESS |
> > 				EFI_VARIABLE_RUNTIME_ACCESS, &store_size,
> > 				&remaining_size, &var_size);
> 
> This does trigger the problem.  Note that the definition of
> QueryVariableInfo() in the UEFI spec says:
> 
>   The returned MaximumVariableStorageSize, RemainingVariableStorageSize,
>   MaximumVariableSize information may change immediately after the call
>   based on other runtime activities including asynchronous error events.
>   Also, these values associated with different attributes are not
>   additive in nature.
> 
> Note the values may be accurate at the point in time when returned,
> but may not be after that.
> 
>   After the system has transitioned into runtime (after
>   ExitBootServices() is called), an implementation may not be able to
>   accurately return information about the Boot Services variable store.
>   In such cases, EFI_INVALID_PARAMETER should be returned.
> 
> It is not clear to me exactly when ExitBootServices() is called.
> Our bios is returning a failing indication on the call.

Yes, but this call is clearly happening way before ExitBootServices() -- 
see the surrounding code, see for example this in efi_main():

[ ... snip ... ]
	setup_efi_vars(boot_params);

	setup_efi_pci(boot_params);

	status = efi_call_phys3(sys_table->boottime->allocate_pool,
				EFI_LOADER_DATA, sizeof(*gdt),
				(void **)&gdt);
	if (status != EFI_SUCCESS) {
		efi_printk("Failed to alloc mem for gdt structure\n");
		goto fail;
	}
[ ... snip ... ]

We are calling QueryVariableInfo() in setup_efi_vars(), and later on 
AllocatePool is being called (through boot table). That'd inherently fail 
if we were calling it after ExitBootServices() has happened, but I believe 
that call is succeeding on your affected system as well.

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/