All of lore.kernel.org
 help / color / mirror / Atom feed
From: matthieu castet <castet.matthieu@free.fr>
To: Linux Kernel list <linux-kernel@vger.kernel.org>
Cc: Siarhei Liakh <sliakh.lkml@gmail.com>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [tip:x86/mm] x86, mm: NX protection for kernel data
Date: Sat, 13 Mar 2010 13:12:31 +0100	[thread overview]
Message-ID: <4B9B812F.3030306@free.fr> (raw)

Hi,

> > looking for c17ebdb8 in system.map points to a location in pgd_lock:
> > ============================================
> > $grep c17ebd System.map
> > c17ebd68 d bios_check_work
> > c17ebda8 d highmem_pages
> > c17ebdac D pgd_lock
> > c17ebdc8 D pgd_list
> > c17ebdd0 D show_unhandled_signals
> > c17ebdd4 d cpa_lock
> > c17ebdf0 d memtype_lock
> > ============================================
> >
> > I've looked at the lock debugging and could not find any place that
> > would look like an attempt to execute data. This would lead me to
> > think that calling set_memory_nx from kernel_init somehow confuses the
> > lock debugging subsystem, or set_memory_nx does not change page
> > attributes in a safe manner (for example when a lock is stored inside
> > the page whose attributes are being changed).
> 
> I've done some extra debugging and it really does look like the crash
> happens when we are setting NX on a large page which has pgd_lock
> inside it.
> 
> Here is a trace of printk's that I added to troubleshoot this issue:
> =========================
> [    3.072003] try_preserve_large_page - enter
> [    3.073185] try_preserve_large_page - address: 0xc1600000
> [    3.074513] try_preserve_large_page - 2M page
> [    3.075606] try_preserve_large_page - about to call static_protections
> [    3.076000] try_preserve_large_page - back from static_protections
> [    3.076000] try_preserve_large_page - past loop
> [    3.076000] try_preserve_large_page - new_prot != old_prot
> [    3.076000] try_preserve_large_page - the address is aligned and
> the number of pages covers the full range
> [    3.076000] try_preserve_large_page - about to call __set_pmd_pte
> [    3.076000] __set_pmd_pte - enter
> [    3.076000] __set_pmd_pte - address: 0xc1600000
> [    3.076000] __set_pmd_pte - about to call
> set_pte_atomic(*0xc18c0058(low=0x16001e3, high=0x0), (low=0x16001e1,
> high=0x80000000))
> [lock-up here]
> =========================
> 

This may be stupid but :


0xc1600000 2MB page is in 0xc1600000-0xc1800000 range.  pgd_lock (0xc17ebdac) seems to be in that range.

You change attribute from (low=0x16001e3, high=0x0) to (low=0x16001e1, high=0x80000000). IE you set
NX bit (bit 63), but you also clear R/W bit (bit 2). So the page become read only, but you are using a lock
inside this page that need RW access. So you got a page fault.


Now I don't know what should be done.
Is that normal we set the page RO ?

Matthieu

             reply	other threads:[~2010-03-13 12:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-13 12:12 matthieu castet [this message]
2010-03-15 18:20 ` [tip:x86/mm] x86, mm: NX protection for kernel data Siarhei Liakh
2010-03-15 21:40   ` Siarhei Liakh
  -- strict thread matches above, loose matches on Subject: below --
2010-03-02 16:23 castet.matthieu
2010-03-02 17:51 ` Siarhei Liakh
2010-03-02 18:03   ` Siarhei Liakh
2010-01-31 23:27 [PATCH V6] x86: " Siarhei Liakh
2010-02-17 19:51 ` [tip:x86/mm] x86, mm: " tip-bot for Siarhei Liakh
2010-02-22 10:54   ` Ingo Molnar
2010-02-22 11:01     ` Ingo Molnar
2010-02-22 17:19       ` H. Peter Anvin
2010-02-22 17:21         ` Ingo Molnar
2010-03-06 19:44           ` Siarhei Liakh
2010-03-10 13:32             ` Ingo Molnar
2010-03-10 15:06               ` Siarhei Liakh
2010-03-12  3:12             ` Siarhei Liakh
2010-03-02 15:13     ` Siarhei Liakh

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=4B9B812F.3030306@free.fr \
    --to=castet.matthieu@free.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=sliakh.lkml@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.