From: Yu-cheng Yu <yu-cheng.yu@intel.com>
To: Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-api@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Andy Lutomirski <luto@amacapital.net>,
Balbir Singh <bsingharora@gmail.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Florian Weimer <fweimer@redhat.com>,
"H.J. Lu" <hjl.tools@gmail.com>, Jann Horn <jannh@google.com>,
Jonathan Corbet <corbet@lwn.net>,
Kees Cook <keescook@chromiun.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
Nadav Amit <nadav.amit@gmail.com>,
Oleg Nesterov <oleg@redhat.com>,
Pavel Machek <pavel@ucw.cz>Peter
Subject: Re: [RFC PATCH v2 16/27] mm: Modify can_follow_write_pte/pmd for shadow stack
Date: Wed, 18 Jul 2018 13:14:42 -0700 [thread overview]
Message-ID: <1531944882.10738.1.camel@intel.com> (raw)
In-Reply-To: <fa9db8c5-41c8-05e9-ad8d-dc6aaf11cb04@linux.intel.com>
On Tue, 2018-07-17 at 16:15 -0700, Dave Hansen wrote:
> On 07/17/2018 04:03 PM, Yu-cheng Yu wrote:
> >
> > We need to find a way to differentiate "someone can write to this PTE"
> > from "the write bit is set in this PTE".
> Please think about this:
>
> Should pte_write() tell us whether PTE.W=1, or should it tell us
> that *something* can write to the PTE, which would include
> PTE.W=0/D=1?
Is it better now?
Subject: [PATCH] mm: Modify can_follow_write_pte/pmd for shadow stack
can_follow_write_pte/pmd look for the (RO & DIRTY) PTE/PMD to
verify a non-sharing RO page still exists after a broken COW.
However, a shadow stack PTE is always RO & DIRTY; it can be:
RO & DIRTY_HW - is_shstk_pte(pte) is true; or
RO & DIRTY_SW - the page is being shared.
Update these functions to check a non-sharing shadow stack page
still exists after the COW.
Also rename can_follow_write_pte/pmd() to can_follow_write() to
make their meaning clear; i.e. "Can we write to the page?", not
"Is the PTE writable?"
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
---
mm/gup.c | 38 ++++++++++++++++++++++++++++++++++----
mm/huge_memory.c | 19 ++++++++++++++-----
2 files changed, 48 insertions(+), 9 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index fc5f98069f4e..316967996232 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -63,11 +63,41 @@ static int follow_pfn_pte(struct vm_area_struct *vma, unsigned long address,
/*
* FOLL_FORCE can write to even unwritable pte's, but only
* after we've gone through a COW cycle and they are dirty.
+ *
+ * Background:
+ *
+ * When we force-write to a read-only page, the page fault
+ * handler copies the page and sets the new page's PTE to
+ * RO & DIRTY. This routine tells
+ *
+ * "Can we write to the page?"
+ *
+ * by checking:
+ *
+ * (1) The page has been copied, i.e. FOLL_COW is set;
+ * (2) The copy still exists and its PTE is RO & DIRTY.
+ *
+ * However, a shadow stack PTE is always RO & DIRTY; it can
+ * be:
+ *
+ * RO & DIRTY_HW: when is_shstk_pte(pte) is true; or
+ * RO & DIRTY_SW: when the page is being shared.
+ *
+ * To test a shadow stack's non-sharing page still exists,
+ * we verify that the new page's PTE is_shstk_pte(pte).
*/
-static inline bool can_follow_write_pte(pte_t pte, unsigned int flags)
+static inline bool can_follow_write(pte_t pte, unsigned int flags,
+ struct vm_area_struct *vma)
{
- return pte_write(pte) ||
- ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pte_dirty(pte));
+ if (!is_shstk_mapping(vma->vm_flags)) {
+ if (pte_write(pte))
+ return true;
+ return ((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
+ pte_dirty(pte));
+ } else {
+ return ((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
+ is_shstk_pte(pte));
+ }
}
static struct page *follow_page_pte(struct vm_area_struct *vma,
@@ -105,7 +135,7 @@ static struct page *follow_page_pte(struct vm_area_struct *vma,
}
if ((flags & FOLL_NUMA) && pte_protnone(pte))
goto no_page;
- if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, flags)) {
+ if ((flags & FOLL_WRITE) && !can_follow_write(pte, flags, vma)) {
pte_unmap_unlock(ptep, ptl);
return NULL;
}
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 7f3e11d3b64a..822a563678b5 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1388,11 +1388,20 @@ int do_huge_pmd_wp_page(struct vm_fault *vmf, pmd_t orig_pmd)
/*
* FOLL_FORCE can write to even unwritable pmd's, but only
* after we've gone through a COW cycle and they are dirty.
+ * See comments in mm/gup.c, can_follow_write().
*/
-static inline bool can_follow_write_pmd(pmd_t pmd, unsigned int flags)
-{
- return pmd_write(pmd) ||
- ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pmd_dirty(pmd));
+static inline bool can_follow_write(pmd_t pmd, unsigned int flags,
+ struct vm_area_struct *vma)
+{
+ if (!is_shstk_mapping(vma->vm_flags)) {
+ if (pmd_write(pmd))
+ return true;
+ return ((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
+ pmd_dirty(pmd));
+ } else {
+ return ((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
+ is_shstk_pmd(pmd));
+ }
}
struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
@@ -1405,7 +1414,7 @@ struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
assert_spin_locked(pmd_lockptr(mm, pmd));
- if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, flags))
+ if (flags & FOLL_WRITE && !can_follow_write(*pmd, flags, vma))
goto out;
/* Avoid dumping huge zero page */
--
WARNING: multiple messages have this Message-ID (diff)
From: Yu-cheng Yu <yu-cheng.yu@intel.com>
To: Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-api@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Andy Lutomirski <luto@amacapital.net>,
Balbir Singh <bsingharora@gmail.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Florian Weimer <fweimer@redhat.com>,
"H.J. Lu" <hjl.tools@gmail.com>, Jann Horn <jannh@google.com>,
Jonathan Corbet <corbet@lwn.net>,
Kees Cook <keescook@chromiun.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
Nadav Amit <nadav.amit@gmail.com>,
Oleg Nesterov <oleg@redhat.com>, Pavel Machek <pavel@ucw.cz>,
Peter Zijlstra <peterz@infradead.org>,
"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>
Subject: Re: [RFC PATCH v2 16/27] mm: Modify can_follow_write_pte/pmd for shadow stack
Date: Wed, 18 Jul 2018 13:14:42 -0700 [thread overview]
Message-ID: <1531944882.10738.1.camel@intel.com> (raw)
Message-ID: <20180718201442.Gm-FIUvNK70sMD8aX5KJS-p1WeggWnqssgK0deL9y1A@z> (raw)
In-Reply-To: <fa9db8c5-41c8-05e9-ad8d-dc6aaf11cb04@linux.intel.com>
On Tue, 2018-07-17 at 16:15 -0700, Dave Hansen wrote:
> On 07/17/2018 04:03 PM, Yu-cheng Yu wrote:
> >
> > We need to find a way to differentiate "someone can write to this PTE"
> > from "the write bit is set in this PTE".
> Please think about this:
>
> Should pte_write() tell us whether PTE.W=1, or should it tell us
> that *something* can write to the PTE, which would include
> PTE.W=0/D=1?
Is it better now?
Subject: [PATCH] mm: Modify can_follow_write_pte/pmd for shadow stack
can_follow_write_pte/pmd look for the (RO & DIRTY) PTE/PMD to
verify a non-sharing RO page still exists after a broken COW.
However, a shadow stack PTE is always RO & DIRTY; it can be:
RO & DIRTY_HW - is_shstk_pte(pte) is true; or
RO & DIRTY_SW - the page is being shared.
Update these functions to check a non-sharing shadow stack page
still exists after the COW.
Also rename can_follow_write_pte/pmd() to can_follow_write() to
make their meaning clear; i.e. "Can we write to the page?", not
"Is the PTE writable?"
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
---
mm/gup.c | 38 ++++++++++++++++++++++++++++++++++----
mm/huge_memory.c | 19 ++++++++++++++-----
2 files changed, 48 insertions(+), 9 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index fc5f98069f4e..316967996232 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -63,11 +63,41 @@ static int follow_pfn_pte(struct vm_area_struct *vma, unsigned long address,
/*
* FOLL_FORCE can write to even unwritable pte's, but only
* after we've gone through a COW cycle and they are dirty.
+ *
+ * Background:
+ *
+ * When we force-write to a read-only page, the page fault
+ * handler copies the page and sets the new page's PTE to
+ * RO & DIRTY. This routine tells
+ *
+ * "Can we write to the page?"
+ *
+ * by checking:
+ *
+ * (1) The page has been copied, i.e. FOLL_COW is set;
+ * (2) The copy still exists and its PTE is RO & DIRTY.
+ *
+ * However, a shadow stack PTE is always RO & DIRTY; it can
+ * be:
+ *
+ * RO & DIRTY_HW: when is_shstk_pte(pte) is true; or
+ * RO & DIRTY_SW: when the page is being shared.
+ *
+ * To test a shadow stack's non-sharing page still exists,
+ * we verify that the new page's PTE is_shstk_pte(pte).
*/
-static inline bool can_follow_write_pte(pte_t pte, unsigned int flags)
+static inline bool can_follow_write(pte_t pte, unsigned int flags,
+ struct vm_area_struct *vma)
{
- return pte_write(pte) ||
- ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pte_dirty(pte));
+ if (!is_shstk_mapping(vma->vm_flags)) {
+ if (pte_write(pte))
+ return true;
+ return ((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
+ pte_dirty(pte));
+ } else {
+ return ((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
+ is_shstk_pte(pte));
+ }
}
static struct page *follow_page_pte(struct vm_area_struct *vma,
@@ -105,7 +135,7 @@ static struct page *follow_page_pte(struct vm_area_struct *vma,
}
if ((flags & FOLL_NUMA) && pte_protnone(pte))
goto no_page;
- if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, flags)) {
+ if ((flags & FOLL_WRITE) && !can_follow_write(pte, flags, vma)) {
pte_unmap_unlock(ptep, ptl);
return NULL;
}
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 7f3e11d3b64a..822a563678b5 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1388,11 +1388,20 @@ int do_huge_pmd_wp_page(struct vm_fault *vmf, pmd_t orig_pmd)
/*
* FOLL_FORCE can write to even unwritable pmd's, but only
* after we've gone through a COW cycle and they are dirty.
+ * See comments in mm/gup.c, can_follow_write().
*/
-static inline bool can_follow_write_pmd(pmd_t pmd, unsigned int flags)
-{
- return pmd_write(pmd) ||
- ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pmd_dirty(pmd));
+static inline bool can_follow_write(pmd_t pmd, unsigned int flags,
+ struct vm_area_struct *vma)
+{
+ if (!is_shstk_mapping(vma->vm_flags)) {
+ if (pmd_write(pmd))
+ return true;
+ return ((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
+ pmd_dirty(pmd));
+ } else {
+ return ((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
+ is_shstk_pmd(pmd));
+ }
}
struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
@@ -1405,7 +1414,7 @@ struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
assert_spin_locked(pmd_lockptr(mm, pmd));
- if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, flags))
+ if (flags & FOLL_WRITE && !can_follow_write(*pmd, flags, vma))
goto out;
/* Avoid dumping huge zero page */
--
WARNING: multiple messages have this Message-ID (diff)
From: Yu-cheng Yu <yu-cheng.yu@intel.com>
To: Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-api@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Andy Lutomirski <luto@amacapital.net>,
Balbir Singh <bsingharora@gmail.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Florian Weimer <fweimer@redhat.com>,
"H.J. Lu" <hjl.tools@gmail.com>, Jann Horn <jannh@google.com>,
Jonathan Corbet <corbet@lwn.net>,
Kees Cook <keescook@chromiun.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
Nadav Amit <nadav.amit@gmail.com>,
Oleg Nesterov <oleg@redhat.com>, Pavel Machek <pavel@ucw.cz>,
Peter Zijlstra <peterz@infradead.org>,
"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>
Subject: Re: [RFC PATCH v2 16/27] mm: Modify can_follow_write_pte/pmd for shadow stack
Date: Wed, 18 Jul 2018 13:14:42 -0700 [thread overview]
Message-ID: <1531944882.10738.1.camel@intel.com> (raw)
In-Reply-To: <fa9db8c5-41c8-05e9-ad8d-dc6aaf11cb04@linux.intel.com>
On Tue, 2018-07-17 at 16:15 -0700, Dave Hansen wrote:
> On 07/17/2018 04:03 PM, Yu-cheng Yu wrote:
> >
> > We need to find a way to differentiate "someone can write to this PTE"
> > from "the write bit is set in this PTE".
> Please think about this:
>
> Should pte_write() tell us whether PTE.W=1, or should it tell us
> that *something* can write to the PTE, which would include
> PTE.W=0/D=1?
Is it better now?
Subject: [PATCH] mm: Modify can_follow_write_pte/pmd for shadow stack
can_follow_write_pte/pmd look for the (RO & DIRTY) PTE/PMD to
verify a non-sharing RO page still exists after a broken COW.
However, a shadow stack PTE is always RO & DIRTY; it can be:
RO & DIRTY_HW - is_shstk_pte(pte) is true; or
RO & DIRTY_SW - the page is being shared.
Update these functions to check a non-sharing shadow stack page
still exists after the COW.
Also rename can_follow_write_pte/pmd() to can_follow_write() to
make their meaning clear; i.e. "Can we write to the page?", not
"Is the PTE writable?"
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
---
mm/gup.c | 38 ++++++++++++++++++++++++++++++++++----
mm/huge_memory.c | 19 ++++++++++++++-----
2 files changed, 48 insertions(+), 9 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index fc5f98069f4e..316967996232 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -63,11 +63,41 @@ static int follow_pfn_pte(struct vm_area_struct *vma, unsigned long address,
/*
* FOLL_FORCE can write to even unwritable pte's, but only
* after we've gone through a COW cycle and they are dirty.
+ *
+ * Background:
+ *
+ * When we force-write to a read-only page, the page fault
+ * handler copies the page and sets the new page's PTE to
+ * RO & DIRTY. This routine tells
+ *
+ * "Can we write to the page?"
+ *
+ * by checking:
+ *
+ * (1) The page has been copied, i.e. FOLL_COW is set;
+ * (2) The copy still exists and its PTE is RO & DIRTY.
+ *
+ * However, a shadow stack PTE is always RO & DIRTY; it can
+ * be:
+ *
+ * RO & DIRTY_HW: when is_shstk_pte(pte) is true; or
+ * RO & DIRTY_SW: when the page is being shared.
+ *
+ * To test a shadow stack's non-sharing page still exists,
+ * we verify that the new page's PTE is_shstk_pte(pte).
*/
-static inline bool can_follow_write_pte(pte_t pte, unsigned int flags)
+static inline bool can_follow_write(pte_t pte, unsigned int flags,
+ struct vm_area_struct *vma)
{
- return pte_write(pte) ||
- ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pte_dirty(pte));
+ if (!is_shstk_mapping(vma->vm_flags)) {
+ if (pte_write(pte))
+ return true;
+ return ((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
+ pte_dirty(pte));
+ } else {
+ return ((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
+ is_shstk_pte(pte));
+ }
}
static struct page *follow_page_pte(struct vm_area_struct *vma,
@@ -105,7 +135,7 @@ static struct page *follow_page_pte(struct vm_area_struct *vma,
}
if ((flags & FOLL_NUMA) && pte_protnone(pte))
goto no_page;
- if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, flags)) {
+ if ((flags & FOLL_WRITE) && !can_follow_write(pte, flags, vma)) {
pte_unmap_unlock(ptep, ptl);
return NULL;
}
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 7f3e11d3b64a..822a563678b5 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1388,11 +1388,20 @@ int do_huge_pmd_wp_page(struct vm_fault *vmf, pmd_t orig_pmd)
/*
* FOLL_FORCE can write to even unwritable pmd's, but only
* after we've gone through a COW cycle and they are dirty.
+ * See comments in mm/gup.c, can_follow_write().
*/
-static inline bool can_follow_write_pmd(pmd_t pmd, unsigned int flags)
-{
- return pmd_write(pmd) ||
- ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pmd_dirty(pmd));
+static inline bool can_follow_write(pmd_t pmd, unsigned int flags,
+ struct vm_area_struct *vma)
+{
+ if (!is_shstk_mapping(vma->vm_flags)) {
+ if (pmd_write(pmd))
+ return true;
+ return ((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
+ pmd_dirty(pmd));
+ } else {
+ return ((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
+ is_shstk_pmd(pmd));
+ }
}
struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
@@ -1405,7 +1414,7 @@ struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
assert_spin_locked(pmd_lockptr(mm, pmd));
- if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, flags))
+ if (flags & FOLL_WRITE && !can_follow_write(*pmd, flags, vma))
goto out;
/* Avoid dumping huge zero page */
--
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Yu-cheng Yu <yu-cheng.yu@intel.com>
To: Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-mm@kvack.org, linux-arch@vger.kernel.org,
linux-api@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Andy Lutomirski <luto@amacapital.net>,
Balbir Singh <bsingharora@gmail.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Florian Weimer <fweimer@redhat.com>,
"H.J. Lu" <hjl.tools@gmail.com>, Jann Horn <jannh@google.com>,
Jonathan Corbet <corbet@lwn.net>,
Kees Cook <keescook@chromiun.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
Nadav Amit <nadav.amit@gmail.com>,
Oleg Nesterov <oleg@redhat.com>, Pavel Machek <pavel@ucw.cz>,
Peter Zijlstra <peterz@infradead.org>,
"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>
Subject: Re: [RFC PATCH v2 16/27] mm: Modify can_follow_write_pte/pmd for shadow stack
Date: Wed, 18 Jul 2018 13:14:42 -0700 [thread overview]
Message-ID: <1531944882.10738.1.camel@intel.com> (raw)
In-Reply-To: <fa9db8c5-41c8-05e9-ad8d-dc6aaf11cb04@linux.intel.com>
On Tue, 2018-07-17 at 16:15 -0700, Dave Hansen wrote:
> On 07/17/2018 04:03 PM, Yu-cheng Yu wrote:
> >
> > We need to find a way to differentiate "someone can write to this PTE"
> > from "the write bit is set in this PTE".
> Please think about this:
>
> Should pte_write() tell us whether PTE.W=1, or should it tell us
> that *something* can write to the PTE, which would include
> PTE.W=0/D=1?
Is it better now?
Subject: [PATCH] mm: Modify can_follow_write_pte/pmd for shadow stack
can_follow_write_pte/pmd look for the (RO & DIRTY) PTE/PMD to
verify a non-sharing RO page still exists after a broken COW.
However, a shadow stack PTE is always RO & DIRTY; it can be:
A RO & DIRTY_HW - is_shstk_pte(pte) is true; or
A RO & DIRTY_SW - the page is being shared.
Update these functions to check a non-sharing shadow stack page
still exists after the COW.
Also rename can_follow_write_pte/pmd() to can_follow_write() to
make their meaning clear; i.e. "Can we write to the page?", not
"Is the PTE writable?"
Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
---
A mm/gup.cA A A A A A A A A | 38 ++++++++++++++++++++++++++++++++++----
A mm/huge_memory.c | 19 ++++++++++++++-----
A 2 files changed, 48 insertions(+), 9 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index fc5f98069f4e..316967996232 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -63,11 +63,41 @@ static int follow_pfn_pte(struct vm_area_struct *vma, unsigned long address,
A /*
A * FOLL_FORCE can write to even unwritable pte's, but only
A * after we've gone through a COW cycle and they are dirty.
+ *
+ * Background:
+ *
+ * When we force-write to a read-only page, the page fault
+ * handler copies the page and sets the new page's PTE to
+ * RO & DIRTY.A A This routine tells
+ *
+ *A A A A A "Can we write to the page?"
+ *
+ * by checking:
+ *
+ *A A A A A (1) The page has been copied, i.e. FOLL_COW is set;
+ *A A A A A (2) The copy still exists and its PTE is RO & DIRTY.
+ *
+ * However, a shadow stack PTE is always RO & DIRTY; it can
+ * be:
+ *
+ *A A A A A RO & DIRTY_HW: when is_shstk_pte(pte) is true; or
+ *A A A A A RO & DIRTY_SW: when the page is being shared.
+ *
+ * To test a shadow stack's non-sharing page still exists,
+ * we verify that the new page's PTE is_shstk_pte(pte).
A */
-static inline bool can_follow_write_pte(pte_t pte, unsigned int flags)
+static inline bool can_follow_write(pte_t pte, unsigned int flags,
+ A A A A struct vm_area_struct *vma)
A {
- return pte_write(pte) ||
- ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pte_dirty(pte));
+ if (!is_shstk_mapping(vma->vm_flags)) {
+ if (pte_write(pte))
+ return true;
+ return ((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
+ pte_dirty(pte));
+ } else {
+ return ((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
+ is_shstk_pte(pte));
+ }
A }
A
A static struct page *follow_page_pte(struct vm_area_struct *vma,
@@ -105,7 +135,7 @@ static struct page *follow_page_pte(struct vm_area_struct *vma,
A }
A if ((flags & FOLL_NUMA) && pte_protnone(pte))
A goto no_page;
- if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, flags)) {
+ if ((flags & FOLL_WRITE) && !can_follow_write(pte, flags, vma)) {
A pte_unmap_unlock(ptep, ptl);
A return NULL;
A }
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 7f3e11d3b64a..822a563678b5 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1388,11 +1388,20 @@ int do_huge_pmd_wp_page(struct vm_fault *vmf, pmd_t orig_pmd)
A /*
A * FOLL_FORCE can write to even unwritable pmd's, but only
A * after we've gone through a COW cycle and they are dirty.
+ * See comments in mm/gup.c, can_follow_write().
A */
-static inline bool can_follow_write_pmd(pmd_t pmd, unsigned int flags)
-{
- return pmd_write(pmd) ||
- A A A A A A A ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pmd_dirty(pmd));
+static inline bool can_follow_write(pmd_t pmd, unsigned int flags,
+ A A A A struct vm_area_struct *vma)
+{
+ if (!is_shstk_mapping(vma->vm_flags)) {
+ if (pmd_write(pmd))
+ return true;
+ return ((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
+ pmd_dirty(pmd));
+ } else {
+ return ((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
+ is_shstk_pmd(pmd));
+ }
A }
A
A struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
@@ -1405,7 +1414,7 @@ struct page *follow_trans_huge_pmd(struct vm_area_struct *vma,
A
A assert_spin_locked(pmd_lockptr(mm, pmd));
A
- if (flags & FOLL_WRITE && !can_follow_write_pmd(*pmd, flags))
+ if (flags & FOLL_WRITE && !can_follow_write(*pmd, flags, vma))
A goto out;
A
A /* Avoid dumping huge zero page */
--A
next prev parent reply other threads:[~2018-07-18 20:14 UTC|newest]
Thread overview: 413+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-10 22:26 [RFC PATCH v2 00/27] Control Flow Enforcement (CET) Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 01/27] x86/cpufeatures: Add CPUIDs for Control-flow Enforcement Technology (CET) Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 02/27] x86/fpu/xstate: Change some names to separate XSAVES system and user states Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 03/27] x86/fpu/xstate: Enable XSAVES system states Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 04/27] x86/fpu/xstate: Add XSAVES system states for shadow stack Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 05/27] Documentation/x86: Add CET description Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-11 8:27 ` Pavel Machek
2018-07-11 8:27 ` Pavel Machek
2018-07-11 15:25 ` Yu-cheng Yu
2018-07-11 15:25 ` Yu-cheng Yu
2018-07-11 15:25 ` Yu-cheng Yu
2018-07-11 15:25 ` Yu-cheng Yu
2018-07-11 9:57 ` Florian Weimer
2018-07-11 9:57 ` Florian Weimer
2018-07-11 9:57 ` Florian Weimer
2018-07-11 13:47 ` H.J. Lu
2018-07-11 13:47 ` H.J. Lu
2018-07-11 13:47 ` H.J. Lu
2018-07-11 14:53 ` Yu-cheng Yu
2018-07-11 14:53 ` Yu-cheng Yu
2018-07-11 14:53 ` Yu-cheng Yu
2018-07-11 14:53 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 06/27] x86/cet: Control protection exception handler Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 07/27] x86/cet/shstk: Add Kconfig option for user-mode shadow stack Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 08/27] mm: Introduce VM_SHSTK for shadow stack memory Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-11 8:34 ` Peter Zijlstra
2018-07-11 8:34 ` Peter Zijlstra
2018-07-11 8:34 ` Peter Zijlstra
2018-07-11 16:15 ` Yu-cheng Yu
2018-07-11 16:15 ` Yu-cheng Yu
2018-07-11 16:15 ` Yu-cheng Yu
2018-07-11 16:15 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 09/27] x86/mm: Change _PAGE_DIRTY to _PAGE_DIRTY_HW Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 10/27] x86/mm: Introduce _PAGE_DIRTY_SW Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-11 8:45 ` Peter Zijlstra
2018-07-11 8:45 ` Peter Zijlstra
2018-07-11 8:45 ` Peter Zijlstra
2018-07-11 9:21 ` Peter Zijlstra
2018-07-11 9:21 ` Peter Zijlstra
2018-07-11 9:21 ` Peter Zijlstra
2018-07-10 22:26 ` [RFC PATCH v2 11/27] x86/mm: Modify ptep_set_wrprotect and pmdp_set_wrprotect for _PAGE_DIRTY_SW Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:44 ` Dave Hansen
2018-07-10 22:44 ` Dave Hansen
2018-07-10 22:44 ` Dave Hansen
2018-07-10 23:23 ` Nadav Amit
2018-07-10 23:23 ` Nadav Amit
2018-07-10 23:23 ` Nadav Amit
2018-07-10 23:23 ` Nadav Amit
2018-07-10 23:52 ` Dave Hansen
2018-07-10 23:52 ` Dave Hansen
2018-07-10 23:52 ` Dave Hansen
2018-07-11 8:48 ` Peter Zijlstra
2018-07-11 8:48 ` Peter Zijlstra
2018-07-11 8:48 ` Peter Zijlstra
2018-07-10 22:26 ` [RFC PATCH v2 12/27] x86/mm: Shadow stack page fault error checking Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:52 ` Dave Hansen
2018-07-10 22:52 ` Dave Hansen
2018-07-10 22:52 ` Dave Hansen
2018-07-11 17:28 ` Yu-cheng Yu
2018-07-11 17:28 ` Yu-cheng Yu
2018-07-11 17:28 ` Yu-cheng Yu
2018-07-11 17:28 ` Yu-cheng Yu
2018-07-10 23:24 ` Dave Hansen
2018-07-10 23:24 ` Dave Hansen
2018-07-10 23:24 ` Dave Hansen
2018-07-10 22:26 ` [RFC PATCH v2 13/27] mm: Handle shadow stack page fault Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 23:06 ` Dave Hansen
2018-07-10 23:06 ` Dave Hansen
2018-07-10 23:06 ` Dave Hansen
2018-07-11 9:06 ` Peter Zijlstra
2018-07-11 9:06 ` Peter Zijlstra
2018-07-11 9:06 ` Peter Zijlstra
2018-08-14 21:28 ` Yu-cheng Yu
2018-08-14 21:28 ` Yu-cheng Yu
2018-08-14 21:28 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 14/27] mm: Handle THP/HugeTLB " Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 23:08 ` Dave Hansen
2018-07-10 23:08 ` Dave Hansen
2018-07-10 23:08 ` Dave Hansen
2018-07-11 9:10 ` Peter Zijlstra
2018-07-11 9:10 ` Peter Zijlstra
2018-07-11 9:10 ` Peter Zijlstra
2018-07-11 16:11 ` Yu-cheng Yu
2018-07-11 16:11 ` Yu-cheng Yu
2018-07-11 16:11 ` Yu-cheng Yu
2018-07-11 16:11 ` Yu-cheng Yu
2018-07-20 14:20 ` Dave Hansen
2018-07-20 14:20 ` Dave Hansen
2018-07-20 14:20 ` Dave Hansen
2018-07-20 14:58 ` Yu-cheng Yu
2018-07-20 14:58 ` Yu-cheng Yu
2018-07-20 14:58 ` Yu-cheng Yu
2018-07-20 14:58 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 15/27] mm/mprotect: Prevent mprotect from changing shadow stack Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 23:10 ` Dave Hansen
2018-07-10 23:10 ` Dave Hansen
2018-07-10 23:10 ` Dave Hansen
2018-07-11 9:12 ` Peter Zijlstra
2018-07-11 9:12 ` Peter Zijlstra
2018-07-11 9:12 ` Peter Zijlstra
2018-07-11 16:07 ` Yu-cheng Yu
2018-07-11 16:07 ` Yu-cheng Yu
2018-07-11 16:07 ` Yu-cheng Yu
2018-07-11 16:07 ` Yu-cheng Yu
2018-07-11 16:22 ` Dave Hansen
2018-07-11 16:22 ` Dave Hansen
2018-07-11 16:22 ` Dave Hansen
2018-07-11 16:22 ` Dave Hansen
2018-07-10 22:26 ` [RFC PATCH v2 16/27] mm: Modify can_follow_write_pte/pmd for " Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 23:37 ` Dave Hansen
2018-07-10 23:37 ` Dave Hansen
2018-07-10 23:37 ` Dave Hansen
2018-07-11 17:05 ` Yu-cheng Yu
2018-07-11 17:05 ` Yu-cheng Yu
2018-07-11 17:05 ` Yu-cheng Yu
2018-07-11 17:05 ` Yu-cheng Yu
2018-07-13 18:26 ` Dave Hansen
2018-07-13 18:26 ` Dave Hansen
2018-07-13 18:26 ` Dave Hansen
2018-07-13 18:26 ` Dave Hansen
2018-07-17 23:03 ` Yu-cheng Yu
2018-07-17 23:03 ` Yu-cheng Yu
2018-07-17 23:03 ` Yu-cheng Yu
2018-07-17 23:03 ` Yu-cheng Yu
2018-07-17 23:11 ` Dave Hansen
2018-07-17 23:11 ` Dave Hansen
2018-07-17 23:11 ` Dave Hansen
2018-07-17 23:11 ` Dave Hansen
2018-07-17 23:15 ` Dave Hansen
2018-07-17 23:15 ` Dave Hansen
2018-07-17 23:15 ` Dave Hansen
2018-07-18 20:14 ` Yu-cheng Yu [this message]
2018-07-18 20:14 ` Yu-cheng Yu
2018-07-18 20:14 ` Yu-cheng Yu
2018-07-18 20:14 ` Yu-cheng Yu
2018-07-18 21:45 ` Dave Hansen
2018-07-18 21:45 ` Dave Hansen
2018-07-18 21:45 ` Dave Hansen
2018-07-18 21:45 ` Dave Hansen
2018-07-18 23:10 ` Yu-cheng Yu
2018-07-18 23:10 ` Yu-cheng Yu
2018-07-18 23:10 ` Yu-cheng Yu
2018-07-18 23:10 ` Yu-cheng Yu
2018-07-19 0:06 ` Dave Hansen
2018-07-19 0:06 ` Dave Hansen
2018-07-19 0:06 ` Dave Hansen
2018-07-19 0:06 ` Dave Hansen
2018-07-19 17:06 ` Yu-cheng Yu
2018-07-19 17:06 ` Yu-cheng Yu
2018-07-19 17:06 ` Yu-cheng Yu
2018-07-19 17:06 ` Yu-cheng Yu
2018-07-19 19:31 ` Dave Hansen
2018-07-19 19:31 ` Dave Hansen
2018-07-19 19:31 ` Dave Hansen
2018-07-11 9:29 ` Peter Zijlstra
2018-07-11 9:29 ` Peter Zijlstra
2018-07-11 9:29 ` Peter Zijlstra
2018-07-17 23:00 ` Yu-cheng Yu
2018-07-17 23:00 ` Yu-cheng Yu
2018-07-17 23:00 ` Yu-cheng Yu
2018-07-17 23:00 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 17/27] x86/cet/shstk: User-mode shadow stack support Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 23:40 ` Dave Hansen
2018-07-10 23:40 ` Dave Hansen
2018-07-10 23:40 ` Dave Hansen
2018-07-11 9:34 ` Peter Zijlstra
2018-07-11 9:34 ` Peter Zijlstra
2018-07-11 9:34 ` Peter Zijlstra
2018-07-11 15:45 ` Yu-cheng Yu
2018-07-11 15:45 ` Yu-cheng Yu
2018-07-11 15:45 ` Yu-cheng Yu
2018-07-11 9:36 ` Peter Zijlstra
2018-07-11 9:36 ` Peter Zijlstra
2018-07-11 9:36 ` Peter Zijlstra
2018-07-11 21:10 ` Jann Horn
2018-07-11 21:10 ` Jann Horn
2018-07-11 21:10 ` Jann Horn
2018-07-11 21:34 ` Andy Lutomirski
2018-07-11 21:34 ` Andy Lutomirski
2018-07-11 21:34 ` Andy Lutomirski
2018-07-11 21:51 ` Jann Horn
2018-07-11 21:51 ` Jann Horn
2018-07-11 21:51 ` Jann Horn
2018-07-11 22:21 ` Andy Lutomirski
2018-07-11 22:21 ` Andy Lutomirski
2018-07-11 22:21 ` Andy Lutomirski
2018-07-13 18:03 ` Yu-cheng Yu
2018-07-13 18:03 ` Yu-cheng Yu
2018-07-13 18:03 ` Yu-cheng Yu
2018-07-13 18:03 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 18/27] x86/cet/shstk: Introduce WRUSS instruction Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 23:48 ` Dave Hansen
2018-07-10 23:48 ` Dave Hansen
2018-07-10 23:48 ` Dave Hansen
2018-07-12 22:59 ` Yu-cheng Yu
2018-07-12 22:59 ` Yu-cheng Yu
2018-07-12 22:59 ` Yu-cheng Yu
2018-07-12 22:59 ` Yu-cheng Yu
2018-07-12 23:49 ` Dave Hansen
2018-07-12 23:49 ` Dave Hansen
2018-07-12 23:49 ` Dave Hansen
2018-07-12 23:49 ` Dave Hansen
2018-07-13 1:50 ` Dave Hansen
2018-07-13 1:50 ` Dave Hansen
2018-07-13 1:50 ` Dave Hansen
2018-07-13 1:50 ` Dave Hansen
2018-07-13 2:21 ` Andy Lutomirski
2018-07-13 2:21 ` Andy Lutomirski
2018-07-13 2:21 ` Andy Lutomirski
2018-07-13 4:16 ` Dave Hansen
2018-07-13 4:16 ` Dave Hansen
2018-07-13 4:16 ` Dave Hansen
2018-07-13 4:16 ` Dave Hansen
2018-07-13 4:18 ` Dave Hansen
2018-07-13 4:18 ` Dave Hansen
2018-07-13 4:18 ` Dave Hansen
2018-07-13 4:18 ` Dave Hansen
2018-07-13 17:39 ` Yu-cheng Yu
2018-07-13 17:39 ` Yu-cheng Yu
2018-07-13 17:39 ` Yu-cheng Yu
2018-07-13 17:39 ` Yu-cheng Yu
2018-07-13 5:55 ` Andy Lutomirski
2018-07-13 5:55 ` Andy Lutomirski
2018-07-13 5:55 ` Andy Lutomirski
2018-07-11 9:44 ` Peter Zijlstra
2018-07-11 9:44 ` Peter Zijlstra
2018-07-11 9:44 ` Peter Zijlstra
2018-07-11 15:06 ` Yu-cheng Yu
2018-07-11 15:06 ` Yu-cheng Yu
2018-07-11 15:06 ` Yu-cheng Yu
2018-07-11 15:06 ` Yu-cheng Yu
2018-07-11 15:30 ` Peter Zijlstra
2018-07-11 15:30 ` Peter Zijlstra
2018-07-11 15:30 ` Peter Zijlstra
2018-07-11 15:30 ` Peter Zijlstra
2018-07-11 9:45 ` Peter Zijlstra
2018-07-11 9:45 ` Peter Zijlstra
2018-07-11 9:45 ` Peter Zijlstra
2018-07-11 14:58 ` Yu-cheng Yu
2018-07-11 14:58 ` Yu-cheng Yu
2018-07-11 14:58 ` Yu-cheng Yu
2018-07-11 14:58 ` Yu-cheng Yu
2018-07-11 15:27 ` Peter Zijlstra
2018-07-11 15:27 ` Peter Zijlstra
2018-07-11 15:27 ` Peter Zijlstra
2018-07-11 15:27 ` Peter Zijlstra
2018-07-11 15:41 ` Yu-cheng Yu
2018-07-11 15:41 ` Yu-cheng Yu
2018-07-11 15:41 ` Yu-cheng Yu
2018-07-11 15:41 ` Yu-cheng Yu
2018-07-13 12:12 ` Dave Hansen
2018-07-13 12:12 ` Dave Hansen
2018-07-13 12:12 ` Dave Hansen
2018-07-13 17:37 ` Yu-cheng Yu
2018-07-13 17:37 ` Yu-cheng Yu
2018-07-13 17:37 ` Yu-cheng Yu
2018-07-13 17:37 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 19/27] x86/cet/shstk: Signal handling for shadow stack Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 20/27] x86/cet/shstk: ELF header parsing of CET Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-11 11:12 ` Florian Weimer
2018-07-11 11:12 ` Florian Weimer
2018-07-11 11:12 ` Florian Weimer
2018-07-11 19:37 ` Jann Horn
2018-07-11 19:37 ` Jann Horn
2018-07-11 19:37 ` Jann Horn
2018-07-11 20:53 ` Yu-cheng Yu
2018-07-11 20:53 ` Yu-cheng Yu
2018-07-11 20:53 ` Yu-cheng Yu
2018-07-11 20:53 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 21/27] x86/cet/ibt: Add Kconfig option for user-mode Indirect Branch Tracking Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 22/27] x86/cet/ibt: User-mode indirect branch tracking support Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-11 0:11 ` Dave Hansen
2018-07-11 0:11 ` Dave Hansen
2018-07-11 0:11 ` Dave Hansen
2018-07-11 22:10 ` Yu-cheng Yu
2018-07-11 22:10 ` Yu-cheng Yu
2018-07-11 22:10 ` Yu-cheng Yu
2018-07-11 22:10 ` Yu-cheng Yu
2018-07-11 22:40 ` Dave Hansen
2018-07-11 22:40 ` Dave Hansen
2018-07-11 22:40 ` Dave Hansen
2018-07-11 22:40 ` Dave Hansen
2018-07-11 23:00 ` Yu-cheng Yu
2018-07-11 23:00 ` Yu-cheng Yu
2018-07-11 23:00 ` Yu-cheng Yu
2018-07-11 23:00 ` Yu-cheng Yu
2018-07-11 23:16 ` Dave Hansen
2018-07-11 23:16 ` Dave Hansen
2018-07-11 23:16 ` Dave Hansen
2018-07-11 23:16 ` Dave Hansen
2018-07-13 17:56 ` Yu-cheng Yu
2018-07-13 17:56 ` Yu-cheng Yu
2018-07-13 17:56 ` Yu-cheng Yu
2018-07-13 17:56 ` Yu-cheng Yu
2018-07-13 18:05 ` Dave Hansen
2018-07-13 18:05 ` Dave Hansen
2018-07-13 18:05 ` Dave Hansen
2018-07-13 18:05 ` Dave Hansen
2018-07-11 21:07 ` Jann Horn
2018-07-11 21:07 ` Jann Horn
2018-07-11 21:07 ` Jann Horn
2018-07-10 22:26 ` [RFC PATCH v2 23/27] mm/mmap: Add IBT bitmap size to address space limit check Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 23:57 ` Dave Hansen
2018-07-10 23:57 ` Dave Hansen
2018-07-10 23:57 ` Dave Hansen
2018-07-11 16:56 ` Yu-cheng Yu
2018-07-11 16:56 ` Yu-cheng Yu
2018-07-11 16:56 ` Yu-cheng Yu
2018-07-11 16:56 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 24/27] x86: Insert endbr32/endbr64 to vDSO Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 25/27] x86/cet: Add PTRACE interface for CET Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-11 10:20 ` Ingo Molnar
2018-07-11 10:20 ` Ingo Molnar
2018-07-11 10:20 ` Ingo Molnar
2018-07-11 15:40 ` Yu-cheng Yu
2018-07-11 15:40 ` Yu-cheng Yu
2018-07-11 15:40 ` Yu-cheng Yu
2018-07-11 15:40 ` Yu-cheng Yu
2018-07-12 14:03 ` Ingo Molnar
2018-07-12 14:03 ` Ingo Molnar
2018-07-12 14:03 ` Ingo Molnar
2018-07-12 14:03 ` Ingo Molnar
2018-07-12 22:37 ` Yu-cheng Yu
2018-07-12 22:37 ` Yu-cheng Yu
2018-07-12 22:37 ` Yu-cheng Yu
2018-07-12 22:37 ` Yu-cheng Yu
2018-07-12 23:08 ` Thomas Gleixner
2018-07-12 23:08 ` Thomas Gleixner
2018-07-12 23:08 ` Thomas Gleixner
2018-07-13 16:07 ` Yu-cheng Yu
2018-07-13 16:07 ` Yu-cheng Yu
2018-07-13 16:07 ` Yu-cheng Yu
2018-07-13 16:07 ` Yu-cheng Yu
2018-07-13 6:28 ` Pavel Machek
2018-07-13 6:28 ` Pavel Machek
2018-07-13 13:33 ` Ingo Molnar
2018-07-13 13:33 ` Ingo Molnar
2018-07-13 13:33 ` Ingo Molnar
2018-07-14 6:27 ` Pavel Machek
2018-07-14 6:27 ` Pavel Machek
2018-07-10 22:26 ` [RFC PATCH v2 26/27] x86/cet/shstk: Handle thread shadow stack Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` [RFC PATCH v2 27/27] x86/cet: Add arch_prctl functions for CET Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-10 22:26 ` Yu-cheng Yu
2018-07-11 12:19 ` Florian Weimer
2018-07-11 12:19 ` Florian Weimer
2018-07-11 12:19 ` Florian Weimer
2018-07-11 12:19 ` Florian Weimer
2018-07-11 21:02 ` Yu-cheng Yu
2018-07-11 21:02 ` Yu-cheng Yu
2018-07-11 21:02 ` Yu-cheng Yu
2018-07-11 21:02 ` Yu-cheng Yu
2018-07-11 19:45 ` Jann Horn
2018-07-11 19:45 ` Jann Horn
2018-07-11 19:45 ` Jann Horn
2018-07-11 20:55 ` Yu-cheng Yu
2018-07-11 20:55 ` Yu-cheng Yu
2018-07-11 20:55 ` Yu-cheng Yu
2018-07-11 20:55 ` Yu-cheng Yu
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=1531944882.10738.1.camel@intel.com \
--to=yu-cheng.yu@intel.com \
--cc=arnd@arndb.de \
--cc=bsingharora@gmail.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=fweimer@redhat.com \
--cc=gorcunov@gmail.com \
--cc=hjl.tools@gmail.com \
--cc=hpa@zytor.com \
--cc=jannh@google.com \
--cc=keescook@chromiun.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@amacapital.net \
--cc=mike.kravetz@oracle.com \
--cc=mingo@redhat.com \
--cc=nadav.amit@gmail.com \
--cc=oleg@redhat.com \
--cc=pavel@ucw.cz \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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.