public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@zytor.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:39:51 -0700	[thread overview]
Message-ID: <m1ocd2i0u0.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <8f5e697c-e9ae-4453-aa7a-7086dd156cc9@email.android.com> (H. Peter Anvin's message of "Sun, 15 Aug 2010 22:08:43 -0700")


"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.

>>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.

Eric

  reply	other threads:[~2010-08-16 23:40 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 [this message]
2010-08-16 23:54           ` H. Peter Anvin

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=m1ocd2i0u0.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=hpa@zytor.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