[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <899d8f3baaf45b896cf335dec2143cd0969a2d8a.camel@intel.com>
Date: Thu, 26 Jan 2023 00:59:11 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "david@...hat.com" <david@...hat.com>,
"bsingharora@...il.com" <bsingharora@...il.com>,
"hpa@...or.com" <hpa@...or.com>,
"Syromiatnikov, Eugene" <esyr@...hat.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"rdunlap@...radead.org" <rdunlap@...radead.org>,
"keescook@...omium.org" <keescook@...omium.org>,
"Eranian, Stephane" <eranian@...gle.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"fweimer@...hat.com" <fweimer@...hat.com>,
"nadav.amit@...il.com" <nadav.amit@...il.com>,
"jannh@...gle.com" <jannh@...gle.com>,
"dethoma@...rosoft.com" <dethoma@...rosoft.com>,
"kcc@...gle.com" <kcc@...gle.com>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"pavel@....cz" <pavel@....cz>, "oleg@...hat.com" <oleg@...hat.com>,
"hjl.tools@...il.com" <hjl.tools@...il.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"Yang, Weijiang" <weijiang.yang@...el.com>,
"Lutomirski, Andy" <luto@...nel.org>,
"arnd@...db.de" <arnd@...db.de>,
"jamorris@...ux.microsoft.com" <jamorris@...ux.microsoft.com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"bp@...en8.de" <bp@...en8.de>,
"Schimpe, Christina" <christina.schimpe@...el.com>,
"x86@...nel.org" <x86@...nel.org>,
"mike.kravetz@...cle.com" <mike.kravetz@...cle.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
"john.allen@....com" <john.allen@....com>,
"rppt@...nel.org" <rppt@...nel.org>,
"mingo@...hat.com" <mingo@...hat.com>,
"corbet@....net" <corbet@....net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
"gorcunov@...il.com" <gorcunov@...il.com>
CC: "Yu, Yu-cheng" <yu-cheng.yu@...el.com>
Subject: Re: [PATCH v5 18/39] mm: Handle faultless write upgrades for shstk
On Wed, 2023-01-25 at 10:43 -0800, Rick Edgecombe wrote:
> Thanks for your comments and ideas here, I'll give the:
> pte_t pte_mkwrite(struct vm_area_struct *vma, pte_t pte)
> ...solution a try.
Well, it turns out there are some pte_mkwrite() callers in other arch's
that operate on kernel memory and don't have a VMA. So it needed a new
function that can be overridden in arch code. I ended up with x86
versions of these, like this:
pte_t maybe_mkwrite(pte_t pte, struct vm_area_struct *vma)
{
if (!(vma->vm_flags & VM_WRITE))
return pte;
if (vma->vm_flags & VM_SHADOW_STACK)
return pte_mkwrite_shstk(pte);
return pte_mkwrite(pte);
}
pte_t pte_mkwrite_vma(pte_t pte, struct vm_area_struct *vma)
{
if (vma->vm_flags & VM_SHADOW_STACK)
return pte_mkwrite_shstk(pte);
return pte_mkwrite(pte);
}
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
pmd_t maybe_pmd_mkwrite(pmd_t pmd, struct vm_area_struct *vma)
{
if (!(vma->vm_flags & VM_WRITE))
return pmd;
if (vma->vm_flags & VM_SHADOW_STACK)
return pmd_mkwrite_shstk(pmd);
return pmd_mkwrite(pmd);
}
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
All the other pte_mkdirty()s, etc remain the same.
Previously, there was a suggestion to not override the
maybe_mkwrite()'s and put the logic in core MM by having a generic
version of pte_mkwrite_shstk() that does nothing. But given what we are
trying to do with pte_mkwrite_vma() it seemed better to hide all the
shadow stack PTE changes in arch code again.
After the changes, the only shadow stack specific bits in core mm are
the bit in GUP to require FOLL_FORCE, the memory accounting, and these
warnings:
https://lore.kernel.org/lkml/20230119212317.8324-26-rick.p.edgecombe@intel.com/
Powered by blists - more mailing lists