linux-kernel - Re: [PATCH 12/12] EFI: Runtime services virtual mapping

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, 10 Oct 2013 16:14:34 +0800
From:	Dave Young <dyoung@...hat.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
	Borislav Petkov <bp@...e.de>,
	Matt Fleming <matt@...sole-pimps.org>,
	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 10/10/13 at 04:06pm, Dave Young wrote:
> On 10/08/13 at 06:48pm, Borislav Petkov wrote:
> > From: Borislav Petkov <bp@...e.de>
> > 
> > We map the EFI regions needed for runtime services contiguously on
> > virtual addresses starting from -4G down for a total max space of 64G.
> > This way, we provide for stable runtime services addresses across
> > kernels so that a kexec'd kernel can still use them.
> > 
> > This way, they're mapped in a separate pagetable so that we don't
> > pollute the kernel namespace (you can see how the whole ioremapping and
> > saving and restoring of PGDs is gone now).
> > 
> > Also, add a chicken bit called "efi=old_map" which can be used as a
> > fallback to the old runtime services mapping method in case there's some
> > b0rkage with a particular EFI implementation (haha, it is hard to hold
> > up the sarcasm here...).
> > 
> > Add UEFI RT VA space to Documentation/x86/x86_64/mm.txt, while at it.
> > 
> 
> Tested this new patch, the kexec kernel still get different mappings.
> Same reason, in first kernel reserve boot service function the size is
> set to 0.
> 
> With a little hack patch below (upon my previous test patches for kexec)
> kexec and kdump works ok in qemu/ovmf, still not tried on real hardware.

Even though I still have no idea why kernel text overlap with efi boot
region, anyway map the un-overlapped part is necessary though.

I can post the kexec related patches after your mapping patches settle
down

> 
> --- bp.orig/arch/x86/platform/efi/efi.c
> +++ bp/arch/x86/platform/efi/efi.c
> @@ -445,10 +445,18 @@ static void __init print_efi_memmap(void
>  #endif  /*  EFI_DEBUG  */
>  }
>  
> +static bool inline overlap_with_ktext(u64 start, u64 size)
> +{
> +	return (start + size >= __pa_symbol(_text)
> +				&& start <= __pa_symbol(_end));
> +}
> +
>  void __init efi_reserve_boot_services(void)
>  {
>  	void *p;
>  
> +	if (kexecboot)
> +		return;
>  	for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
>  		efi_memory_desc_t *md = p;
>  		u64 start = md->phys_addr;
> @@ -463,13 +471,16 @@ void __init efi_reserve_boot_services(vo
>  		 * - Not within any part of the kernel
>  		 * - Not the bios reserved area
>  		*/
> -		if ((start+size >= __pa_symbol(_text)
> -				&& start <= __pa_symbol(_end)) ||
> +		if (overlap_with_ktext(start, size) ||
>  			!e820_all_mapped(start, start+size, E820_RAM) ||
>  			memblock_is_region_reserved(start, size)) {
>  			/* Could not reserve, skip it */
> -			md->num_pages = 0;
> -			memblock_dbg("Could not reserve boot range "
> +			if (overlap_with_ktext(start, size)) {
> +				u64 s = __pa_symbol(_text) - start;
> +				memblock_reserve(start, s);
> +			} else
> +				md->num_pages = 0;
> +			memblock_dbg("Could not reserve whole boot range "
>  					"[0x%010llx-0x%010llx]\n",
>  						start, start+size-1);
>  		} else
> @@ -490,6 +501,8 @@ void __init efi_free_boot_services(void)
>  {
>  	void *p;
>  
> +	if (kexecboot)
> +		return;
>  	if (!efi_is_native())
>  		return;
>  
> 
--
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/