All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@suse.de>
To: Matt Fleming <matt.fleming@intel.com>,
	Dave Hansen <dave.hansen@intel.com>
Cc: the arch/x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: BUG() at boot in __phys_addr with DEBUG_VIRTUAL
Date: Tue, 9 Dec 2014 11:35:18 +0100	[thread overview]
Message-ID: <20141209103518.GA4147@pd.tnic> (raw)
In-Reply-To: <1415874993.14686.434.camel@mfleming-mobl1.ger.corp.intel.com>

On Thu, Nov 13, 2014 at 10:36:33AM +0000, Matt Fleming wrote:
> So that when we switch into 32-bit mode we can still access the kernel
> text via the 1:1 mapping in protected mode.

Ok, I am able to trigger the same splat with latest EDKII here. Applying
the hunk below fixes it and the guest boots fine.

And this is the thing we could now do short of teaching pageattr.c to
distinguish PGDs. This way we're sending any mapping requests which have
a pgd different than the implicit kernel one into populate_pgd().

What that does is overwrite any mappings there are in the pagetable
prior to that because the userspace part is reserved for UEFI RT 1:1
mappings and since those should be static and not change, we can allow
ourselves the more clumsy method of simply overwriting the page table
with the regions.

The VA mappings region is also reserved for UEFI so not an issue there
right now.

What I'm having problems with is mapping the kernel text 1:1 for
EFI_MIXED in the presence of KASLR and then, as getting "lucky" and
having the kernel addresses overlap with EFI regions. I think if that
happens, then we have a boom but I could very well be missing something.

Matt?

---
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index a3a5d46605d2..226ecb319913 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1120,7 +1140,7 @@ static int __change_page_attr(struct cpa_data *cpa, int primary)
                address = *cpa->vaddr;
 repeat:
        kpte = _lookup_address_cpa(cpa, address, &level);
-       if (!kpte)
+       if (!kpte || cpa->pgd)
                return __cpa_process_fault(cpa, address, primary);
 
        old_pte = *kpte;



-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

  reply	other threads:[~2014-12-09 10:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-11 23:19 BUG() at boot in __phys_addr with DEBUG_VIRTUAL Dave Hansen
2014-11-11 23:47 ` Borislav Petkov
2014-11-12  9:24 ` Matt Fleming
2014-11-12 14:57   ` Dave Hansen
2014-11-12 15:11     ` Borislav Petkov
2014-11-12 15:20       ` Dave Hansen
2014-11-12 17:25         ` Borislav Petkov
2014-11-13 10:36           ` Matt Fleming
2014-12-09 10:35             ` Borislav Petkov [this message]
2014-11-13 13:08         ` Matt Fleming
2015-01-27 21:37 ` Matt Fleming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141209103518.GA4147@pd.tnic \
    --to=bp@suse.de \
    --cc=dave.hansen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.fleming@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.