All of lore.kernel.org
 help / color / mirror / Atom feed
From: Venki Pallipadi <venkatesh.pallipadi@intel.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Venki Pallipadi <venkatesh.pallipadi@intel.com>,
	Frans Pop <elendil@planet.nl>,
	Jesse Barnes <jesse.barnes@intel.com>,
	linux-kernel@vger.kernel.org, "Packard,
	Keith" <keith.packard@intel.com>,
	Yinghai Lu <yhlu.kernel@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Hugh Dickins <hugh@veritas.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	suresh.b.siddha@intel.com
Subject: Re: [git head] X86_PAT & mprotect
Date: Wed, 7 May 2008 15:36:46 -0700	[thread overview]
Message-ID: <20080507223646.GA10757@linux-os.sc.intel.com> (raw)
In-Reply-To: <20080507070217.GD32195@elte.hu>

On Wed, May 07, 2008 at 09:02:17AM +0200, Ingo Molnar wrote:
> 
> * Venki Pallipadi <venkatesh.pallipadi@intel.com> wrote:
> 
> > There is a hole in mprotect, which lets the user to change the page 
> > cache type bits by-passing the kernel reserve_memtype and free_memtype 
> > wrappers. Fix the hole by not letting mprotect change the PAT bits.
> > 
> > Some versions of X used the mprotect hole to change caching type from 
> > UC to WB, so that it can then use mtrr to program WC for that region 
> > [1]. Change the mmap of pci space through /sys or /proc interfaces 
> > from UC to UC_MINUS. With this change, X will not need to use mprotect 
> > hole to get WC type.
> > 
> > [1] lkml.org/lkml/2008/4/16/369
> > 
> > Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
> > Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
> > 
> > ---
> >  arch/x86/pci/i386.c       |    4 +---
> >  include/asm-x86/pgtable.h |    5 ++++-
> >  include/linux/mm.h        |    1 +
> >  mm/mmap.c                 |   13 +++++++++++++
> >  mm/mprotect.c             |    4 +++-
> >  5 files changed, 22 insertions(+), 5 deletions(-)
> 
> hm, that's one dangerous looking patch. (Cc:-ed more MM folks. I've 
> attached the patch below for reference.)
> 
> the purpose of the fix itself seems to make some sense - we dont want 
> mprotect() change the PAT bits in the pte from what they got populated 
> with at fault or mmap time.
> 
> the pte_modify() change looks correct at first sight.
> 
> The _PAGE_PROT_PRESERVE_BITS solution looks a bit ugly (although we do 
> have a couple of other similar #ifndefs in the MM already).
> 
> at minimum we should add vm_get_page_prot_preserve() as an inline 
> function to mm.h if _PAGE_PROT_PRESERVE_BITS is not defined, and make it 
> call vm_get_page_prot(). Also, vm_get_page_prot() in mm/mmap.c should 
> probably be marked inline so that we'll have only a single function call 
> [vm_get_page_prot() is trivial].

I did check that with _PAGE_PROT_PRESERVE_BITS defined to zero,
compiler optimizes vm_get_page_prot_preserve to generate same code as
vm_get_page_prot with no function call (on x86 64). So, things should be OK
from overhead perspective. But, from the code cleanliness aspect,
PRESERVE_BITS looks unclean and needs some cleanup. The reason I posted the
patch as is, was to get the confirmation on the original thread, whether this
indeed fixes those PAT related error messages.
 
> but i'm wondering why similar issues never came up on other 
> architectures - i thought it would be rather common to have immutable 
> pte details. So maybe i'm missing something here ...

Probably other architectures does not depend on preserving things in
vma->vm_page_prot once ptes are set correctly. With PAT, we use
vm_page_prot to keep track of PAT attributes for vmas from parent to
child across fork.

pte_modify() part will be required in all archs that wants to preserve
some bits in pte in a mprotect call.

Thanks,
Venki


  parent reply	other threads:[~2008-05-07 22:37 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-02 19:22 [git head] Should X86_PAT really default to yes? Frans Pop
2008-05-02 19:37 ` Pallipadi, Venkatesh
2008-05-02 20:40   ` Jesse Barnes
2008-05-02 21:55     ` Pallipadi, Venkatesh
2008-05-02 22:07       ` Jesse Barnes
2008-05-04  7:10     ` Frans Pop
2008-05-04  9:04       ` Ingo Molnar
2008-05-04 20:23       ` Yinghai Lu
2008-05-05 16:55         ` Frans Pop
2008-05-05 17:00           ` Pallipadi, Venkatesh
2008-05-05 17:42             ` Yinghai Lu
2008-05-05 18:56             ` Frans Pop
2008-05-05 15:57       ` Jesse Barnes
2008-05-05 17:32         ` Frans Pop
2008-05-05 17:45           ` Jesse Barnes
2008-05-05 17:59             ` Pallipadi, Venkatesh
2008-05-05 18:59             ` Frans Pop
2008-05-05 19:04               ` fb layer & ioremap_wc Jesse Barnes
2008-05-05 19:30                 ` Frans Pop
2008-06-13 16:42                 ` Frans Pop
2008-06-13 16:42                   ` Frans Pop
2008-05-06 22:42           ` [git head] Should X86_PAT really default to yes? Venki Pallipadi
2008-05-07  7:02             ` [git head] X86_PAT & mprotect Ingo Molnar
2008-05-07 19:18               ` Hugh Dickins
2008-05-07 23:23                 ` Venki Pallipadi
2008-05-09 10:08                   ` Ingo Molnar
2008-05-09 20:05                     ` Venki Pallipadi
2008-05-09 20:09                       ` Venki Pallipadi
2008-05-09 20:48                         ` Hugh Dickins
2008-05-09 22:11                       ` Dave Airlie
2008-05-09 22:20                         ` Pallipadi, Venkatesh
2008-05-10  6:19                           ` Dave Airlie
2008-05-10  6:29                             ` Keith Packard
2008-05-10  5:45                         ` Keith Packard
2008-05-07 22:36               ` Venki Pallipadi [this message]
2008-05-25 15:08             ` [git head] Should X86_PAT really default to yes? Frans Pop

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=20080507223646.GA10757@linux-os.sc.intel.com \
    --to=venkatesh.pallipadi@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=elendil@planet.nl \
    --cc=hpa@zytor.com \
    --cc=hugh@veritas.com \
    --cc=jesse.barnes@intel.com \
    --cc=keith.packard@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=yhlu.kernel@gmail.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 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.