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 13:34:53 +0100
From:	Matt Fleming <matt@...sole-pimps.org>
To:	Borislav Petkov <bp@...en8.de>
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 Thu, 10 Oct, at 10:58:28AM, Borislav Petkov wrote:
> On Thu, Oct 10, 2013 at 04:14:34PM +0800, Dave Young wrote:
> > 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
> 
> Right, "settle down" being the key here.
> 
> Matt just mentioned on IRC that we might not need boot services mappings
> by the time we have to start the kexec kernel, which would mean, you
> don't have to do anything in efi_reserve_boot_services().

Dave, apologies for not discussing the whole Boot Services thing sooner.
I missed your questions.

We really should not be passing the EFI Boot Service regions via the
memmap to kexec at all, because by the time the kexec'd kernel is
running those pages that previously contained Boot Service code/data
will have likely been reused for something else.

Which, to answer your question, is why the Boot Service regions overlap
the kernel text in the kexec'd kernel - those regions have been
reallocated by the first kernel and now happen to contain the kernel
text of the kexec kernel.

The reason that we don't keep the Boot Service regions around forever is
because they can take up a considerable amount of memory, so the current
situation of free'ing them after we're sure the firmware isn't going to
reference them is still the right way to go, and simply not including
any Boot Service entries in the memory map passed to kexec should make
everything work OK.

> The question which needs answering first though is, how the whole efi
> thing is going to handle any functionality like calling into efi boot
> regions from runtime functions and such. Which hasn't really been tested
> and fw vendors don't really want to support that. But this is all bits
> and pieces I heard yesterday so it is all pretty wet and I'll let efi
> guys, i.e. the Matts and a couple of others :-), figure out this whole
> issue.

We currently treat the scenario where Runtime Services reference Boot
Service regions as a bug and either work around it (where we do
efi_reserve_boot_services() and efi_free_boot_services() around
SetVirtualAddressMap()) or we avoid calling those services altogether.

The spec is pretty clear that runtime drivers shouldn't be doing this,
and so far this approach has served us well.

There are only two reasons why we keep the Boot Services regions around
(for a short period) at all,

  1) To work around the aforementioned runtime firmware bugs
  2) To copy a ACPI BGRT image into kernel memory

I'm not sure whether the kexec kernel would care about the BGRT?

-- 
Matt Fleming, Intel Open Source Technology Center
--
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/