From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1760007AbcBYJGk (ORCPT <rfc822;w@1wt.eu>);
	Thu, 25 Feb 2016 04:06:40 -0500
Received: from mail-wm0-f65.google.com ([74.125.82.65]:34504 "EHLO
	mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1758668AbcBYJGe (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 25 Feb 2016 04:06:34 -0500
Date: Thu, 25 Feb 2016 10:06:29 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Matt Fleming <matt@codeblueprint.co.uk>, Borislav Petkov <bp@alien8.de>,
        Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>,
        "Ravi V. Shankar" <ravi.v.shankar@intel.com>,
        Toshi Kani <toshi.kani@hp.com>, Brian Gerst <brgerst@gmail.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Luis Rodriguez <mcgrof@suse.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Denys Vlasenko <dvlasenk@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>, ricardo.neri@intel.com,
        Hugh Dickins <hughd@google.com>,
        Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [tip:efi/core] x86/mm/pat: Use _PAGE_GLOBAL bit for EFI page
 table mappings
Message-ID: <20160225090629.GC13833@gmail.com>
References: <1455712566-16727-4-git-send-email-matt@codeblueprint.co.uk>
 <tip-397630150632639b3ca5b4414accd5011c45e276@git.kernel.org>
 <CALCETrW17PWUywMCKWn=KGNLfJQ9kPHXeX2h9sVR47TzyGOJww@mail.gmail.com>
 <1456275002.2781.41.camel@intel.com>
 <CALCETrWUcCRdbY4teQPdv068XH9UDDRLVV3UKzpM=g5k=JGk_A@mail.gmail.com>
 <20160224141046.GA2603@codeblueprint.co.uk>
 <20160224162002.GE3888@pd.tnic>
 <CALCETrVDy2hB_eww8rB0FSWNJMiU0ZZOmWNxpcXsfmupiO8YLw@mail.gmail.com>
 <20160224193315.GD2603@codeblueprint.co.uk>
 <CALCETrX5NPHM=a_C7FmDA_j4kBNU=fx5Zu5mBGsgLZrth3KUVw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALCETrX5NPHM=a_C7FmDA_j4kBNU=fx5Zu5mBGsgLZrth3KUVw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Andy Lutomirski <luto@amacapital.net> wrote:

> >> I mean the one in efi_call_virt.  Why would the spec mandate a TLB flush at 
> >> all?  EFI runtime services have no business touching the paging structures 
> >> directly.  Heck, the 32-bit ones don't even know the *format* of the paging 
> >> structures.
> >
> > Right, and it would necessitate copying out arguments because the firmware 
> > won't understand where/how the kernel has mapped things.
> >
> > No firmware is going to be doing that.
> 
> Just so I understand correctly: could we get away with putting the EFI virtual 
> runtime mappings at positive (user) addresses for 64-bit UEFI, or is there some 
> reason that we need the high bit set?
> 
> If we could use positive addresses, then we could use the existing use_mm 
> infrastructure directly with no funny business at all except to the extent that 
> we might need to use unusual APIs to set up the VMAs (if we use real VMAs) in 
> the first place.  (We could cheat and allocate a single monstrous VM_MIXEDMAP or 
> VM_PFNMAP vma with a .fault handler that always fails.)  If we have to use 
> negative addresses, then we'll always be stuck with a funny pgd, but we could 
> still probably use use_mm instead of manually fiddling with cr3.

Would be nice to get an answer to these questions. The more we isolate firmware 
execution into 'regular' MM concepts, the more robust it all becomes.

> Some day I want to experiment with calling runtime services at CPL 3, too :)

That would be an interesting isolation method as well ...

Thanks,

	Ingo