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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 23 Oct 2013 14:25:31 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Dave Young <dyoung@...hat.com>
Cc:	Matt Fleming <matt@...sole-pimps.org>, X86 ML <x86@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Borislav Petkov <bp@...e.de>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Vivek Goyal <vgoyal@...hat.com>, linux-efi@...r.kernel.org,
	fwts-devel@...ts.ubuntu.com
Subject: Re: [PATCH 12/12] EFI: Runtime services virtual mapping

On Wed, Oct 23, 2013 at 10:17:31AM +0800, Dave Young wrote:
> The reason is that I only pass runtime regions from 1st kernel to
> kexec kernel, your efi mapping function uses the region size to
> determin the virtual address from top to down. Because the passed-in
> md ranges in kexec kernel are different from ranges booting from
> firmware so the virtual address will be different.

Well, this shouldn't be because SetVirtualAddressMap has already fixed
the virtual addresses for us. And if they're different, then runtime
services won't work anyway. Or am I missing something...?

> Even I pass the whole untouched ranges including BOOT_SERVICE there's
> still chance the function for reserving boot regions overwrite the
> boot region size to 0, and 1st kernel will leave it to be used as
> normal memory after efi init. I think we have talked about this issue
> previously.

Matt, didn't you question the need to keep boot services regions
mapped indefinitely? What was the story there?

Thanks.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ