public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: huang ying <huang.ying.caritas@gmail.com>,
	Takao Indoh <indou.takao@jp.fujitsu.com>,
	linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
	tglx@linutronix.de, mingo@redhat.com, vgoyal@redhat.com,
	nhorman@tuxdriver.com
Subject: Re: [PATCH][EFI] Run EFI in physical mode
Date: Mon, 16 Aug 2010 16:54:44 -0700	[thread overview]
Message-ID: <4C69CFC4.8020307@zytor.com> (raw)
In-Reply-To: <m1ocd2i0u0.fsf@fess.ebiederm.org>

On 08/16/2010 04:39 PM, Eric W. Biederman wrote:
> 
> "H. Peter Anvin" <hpa@zytor.com> writes:
>> "huang ying" <huang.ying.caritas@gmail.com> wrote:
>>
>>> On Mon, Aug 16, 2010 at 11:27 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>>>> No, it should not be dynamic; rather we should unify all the users
>>>> who need a 1:1 map and just keep that page table set around.
> 
> We still want to restore cr3 from the local task structure as soon
> as is reasonable, as an identity mapped page table will have page 0
> mapped and thus hide null pointer dereferences.
> 

Absolutely!

>>> Agree. One known issue of global 1:1 map is that we need to make at
>>> least part of page table PAGE_KERNEL_EXEC for EFI runtime code, and
>>> change_page_attr can not be used before page allocator is available.
> 
>> For the 1:1 map we probably should make all pages executable; other
>> things need it too, but we shouldn't have it mapped in except when
>> needed.
> 
> We need to be careful in the setup of the global page table so that
> we are in sync with the pat structure for the attributes pages
> are mapped so that we don't map a page as cached and uncached
> at the same time.  Otherwise we could accidentally get cache
> corruption.  To do that would seem to mean change_page_attr
> is relevant at least after we switch from our default set of
> page permissions.

Quite, which is yet another reason to have a common global page table
for all the 1:1 users... right now this is all ad hoc.

	-hpa

      reply	other threads:[~2010-08-16 23:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-13 19:18 [PATCH][EFI] Run EFI in physical mode Takao Indoh
2010-08-13 22:19 ` Eric W. Biederman
2010-08-16 19:30   ` Takao Indoh
2010-08-13 22:24 ` H. Peter Anvin
2010-08-13 22:33   ` Luck, Tony
2010-08-13 23:11     ` Eric W. Biederman
2010-08-13 23:16       ` H. Peter Anvin
2010-08-13 23:36         ` Tony Luck
2010-08-16  1:31           ` Simon Horman
2010-08-13 22:28 ` H. Peter Anvin
2010-08-16  1:43 ` huang ying
2010-08-16  3:27   ` H. Peter Anvin
2010-08-16  4:58     ` huang ying
2010-08-16  5:08       ` H. Peter Anvin
2010-08-16 23:39         ` Eric W. Biederman
2010-08-16 23:54           ` H. Peter Anvin [this message]

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=4C69CFC4.8020307@zytor.com \
    --to=hpa@zytor.com \
    --cc=ebiederm@xmission.com \
    --cc=huang.ying.caritas@gmail.com \
    --cc=indou.takao@jp.fujitsu.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nhorman@tuxdriver.com \
    --cc=tglx@linutronix.de \
    --cc=vgoyal@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox