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:	Sat, 12 Oct 2013 12:30:55 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Matt Fleming <matt@...sole-pimps.org>
Cc:	Dave Young <dyoung@...hat.com>, 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 Sat, Oct 12, 2013 at 11:13:08AM +0100, Matt Fleming wrote:
> On Sat, 12 Oct, at 03:54:44PM, Dave Young wrote:
> > Boris:
> > 
> > For the boot service region overlapping problem I have another idea,
> > how about modify your mapping code to always mapping the RUNTIME region
> > (non boot service region) firstly from the efi_va, then mapping other
> > regions in order, in this way kexec 2nd kernel will be happy because
> > it does not call SetVirtualAddressMap and it does not need the boot
> > service area at all.
> 
> Coalescing the runtime regions together implies that the second kernel
> would care about the fragmentation caused by unmapping the boot service
> regions - it shouldn't. We've sliced up a considerable chunk of kernel
> virtual address space (64G) and fragmentation shouldn't be an issue
> right now.
> 
> Even if we run out of address space in the future due to fragmentation,
> and end up needing to coalesce runtime regions, this would be
> transparent to the kexec kernel because it's passed the memmap entries
> through setup_data.
> 
> Though we are defining an ABI around the EFI address range
> (0xffffffef00000000 - 0xffffffff00000000), such that it needs to be the
> same between kernels, we must not make the layout of regions within that
> range part of the ABI. We need the freedom to change the layout in the
> future.

Basically, to sum up what Matt so eloquently explained, we will be
passing all the runtime regions *but* *not* the boot regions (because
the kexec kernel doesn't need them anyway) through setup_data to the
kexec kernel.

I.e., boot services regions is a dont-care for kexec.

And it is very important to restate that we want to reserve ourselves
the most flexible way of passing regions to the kexec kernel in case we
want to change the mapping algorithm in the future. Therefore, kexec
should simply not know anything about the VA layout of the EFI regions
but will get them spelled out through the boot header's setup_data.

This is the picture so far, AFAICT. Matt, please make a lot of noise if
I've misrepresented anything.

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/