From: David Hildenbrand <david@redhat.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
"bsingharora@gmail.com" <bsingharora@gmail.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"Syromiatnikov, Eugene" <esyr@redhat.com>,
"peterz@infradead.org" <peterz@infradead.org>,
"rdunlap@infradead.org" <rdunlap@infradead.org>,
"keescook@chromium.org" <keescook@chromium.org>,
"Eranian, Stephane" <eranian@google.com>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"fweimer@redhat.com" <fweimer@redhat.com>,
"nadav.amit@gmail.com" <nadav.amit@gmail.com>,
"jannh@google.com" <jannh@google.com>,
"dethoma@microsoft.com" <dethoma@microsoft.com>,
"kcc@google.com" <kcc@google.com>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"pavel@ucw.cz" <pavel@ucw.cz>,
"oleg@redhat.com" <oleg@redhat.com>,
"hjl.tools@gmail.com" <hjl.tools@gmail.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"Yang, Weijiang" <weijiang.yang@intel.com>,
"Lutomirski, Andy" <luto@kernel.org>,
"arnd@arndb.de" <arnd@arndb.de>,
"jamorris@linux.microsoft.com" <jamorris@linux.microsoft.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"bp@alien8.de" <bp@alien8.de>,
"Schimpe, Christina" <christina.schimpe@intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"mike.kravetz@oracle.com" <mike.kravetz@oracle.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
"john.allen@amd.com" <john.allen@amd.com>,
"rppt@kernel.org" <rppt@kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
"gorcunov@gmail.com" <gorcunov@gmail.com>
Cc: "Yu, Yu-cheng" <yu-cheng.yu@intel.com>
Subject: Re: [PATCH v5 18/39] mm: Handle faultless write upgrades for shstk
Date: Thu, 26 Jan 2023 09:57:27 +0100 [thread overview]
Message-ID: <79e0a85e-1ec4-e359-649d-618ca79c36f7@redhat.com> (raw)
In-Reply-To: <dd06b54291ad5721da392a42f2d8e5636301ffef.camel@intel.com>
On 25.01.23 19:43, Edgecombe, Rick P wrote:
> On Wed, 2023-01-25 at 10:27 +0100, David Hildenbrand wrote:
>>>> Roughly speaking: if we abstract it that way and get all of the
>>>> "how
>>>> to
>>>> set it writable now?" out of core-MM, it not only is cleaner and
>>>> less
>>>> error prone, it might even allow other architectures that
>>>> implement
>>>> something comparable (e.g., using a dedicated HW bit) to actually
>>>> reuse
>>>> some of that work. Otherwise most of that "shstk" is really just
>>>> x86
>>>> specific ...
>>>>
>>>> I guess the only cases we have to special case would be page
>>>> pinning
>>>> code where pte_write() would indicate that the PTE is writable
>>>> (well,
>>>> it
>>>> is, just not by "ordinary CPU instruction" context directly): but
>>>> you
>>>> do
>>>> that already, so ... :)
>>>>
>>>> Sorry for stumbling over that this late, I only started looking
>>>> into
>>>> this when you CCed me on that one patch.
>>>
>>> Sorry for not calling more attention to it earlier. Appreciate your
>>> comments.
>>>
>>> Previously versions of this series had changed some of these
>>> pte_mkwrite() calls to maybe_mkwrite(), which of course takes a
>>> vma.
>>> This way an x86 implementation could use the VM_SHADOW_STACK vma
>>> flag
>>> to decide between pte_mkwrite() and pte_mkwrite_shstk(). The
>>> feedback
>>> was that in some of these code paths "maybe" isn't really an
>>> option, it
>>> *needs* to make it writable. Even though the logic was the same,
>>> the
>>> name of the function made it look wrong.
>>>
>>> But another option could be to change pte_mkwrite() to take a vma.
>>> This
>>> would save using another software bit on x86, but instead requires
>>> a
>>> small change to each arch's pte_mkwrite().
>>
>> I played with that idea shortly as well, but discarded it. I was not
>> able to convince myself that it wouldn't be required to pass in the
>> VMA
>> as well for things like pte_dirty(), pte_mkdirty(), pte_write(), ...
>> which would end up fairly ugly (or even impossible in thing slike
>> GUP-fast).
>>
>> For example, I wonder how we'd be handling stuff like do_numa_page()
>> cleanly correctly, where we use pte_modify() + pte_mkwrite(), and
>> either
>> call might set the PTE writable and maintain dirty bit ...
>
> pte_modify() is handled like this currently:
>
> https://lore.kernel.org/lkml/20230119212317.8324-12-rick.p.edgecombe@intel.com/
>
> There has been a couple iterations on that. The current solution is to
> do the Dirty->SavedDirty fixup if needed after the new prots are added.
>
> Of course pte_modify() can't know whether you are are attempting to
> create a shadow stack PTE with the prot you are passing in. But the
> callers today explicitly call pte_mkwrite() after filling in the other
> bits with pte_modify().
See below on my MAP_PRIVATE vs. MAP_SHARED comment.
> Today this patch causes the pte_mkwrite() to be
> skipped and another fault may be required in the mprotect() and numa
> cases, but if we change pte_mkwrite() to take a VMA we can just make it
> shadow stack to start.
>
> It might be worth mentioning, there was a suggestion in the past to try
> to have the shadow stack bits come out of vm_get_page_prot(), but MM
> code would then try to map the zero page as (shadow stack) writable
> when there was a normal (non-shadow stack) read access. So I had to
> abandon that approach and rely on explicit calls to pte_mkwrite/shstk()
> to make it shadow stack.
Thanks, do you have a pointer?
>
>>
>> Having that said, maybe it could work with only a single saved-dirty
>> bit
>> and passing in the VMA for pte_mkwrite() only.
>>
>> pte_wrprotect() would detect "writable=0,dirty=1" and move the dirty
>> bit
>> to the soft-dirty bit instead, resulting in
>> "writable=0,dirty=0,saved-dirty=1",
>>
>> pte_dirty() would return dirty==1||saved-dirty==1.
>>
>> pte_mkdirty() would set either set dirty=1 or saved-dirty=1,
>> depending
>> on the writable bit.
>>
>> pte_mkclean() would clean both bits.
>>
>> pte_write() would detect "writable == 1 || (writable==0 && dirty==1)"
>>
>> pte_mkwrite() would act according to the VMA, and in addition, merge
>> the
>> saved-dirty bit into the dirty bit.
>>
>> pte_modify() and mk_pte() .... would require more thought ...
>
> Not sure I'm following what the mk_pte() problem would be. You mean if
> Write=0,Dirty=1 is manually added to the prot?
>
> Shouldn't people generally use the pte_mkwrite() helpers unless they
> are drawing from a prot that was already created with the helpers or
> vm_get_page_prot()?
pte_mkwrite() is mostly only used (except for writenotify ...) for
MAP_PRIVATE memory ("COW-able"). For MAP_SHARED memory,
vma->vm_page_prot in a VM_WRITE mapping already contains the write
permissions. pte_mkwrite() is not necessary (again, unless writenotify
is active).
I assume shstk VMAs don't apply to MAP_SHARED VMAs, which is why you
didn't stumble over that issue yet? Because I don't see how it could
work with MAP_SHARED VMAs.
The other thing I had in mind was that we have to make sure that we're
not accidentally setting "Write=0,Dirty=1" in mk_pte() / pte_modify().
Assume we had a "Write=1,Dirty=1" PTE, and we effectively wrprotect
using pte_modify(), we have to make sure to move the dirty bit to the
saved_dirty bit.
> I think they can't manually create prot's from bits
> in core mm code, right? And x86 arch code already has to be aware of
> shadow stack. It's a bit of an assumption I guess, but I think maybe
> not too crazy of one?
I think that's true. Arch code is supposed to deal with that IIRC.
>
>>
>>
>> Further, ptep_modify_prot_commit() might have to be adjusted to
>> properly
>> flush in all relevant cases IIRC.
>
> Sorry, I'm not following. Can you elaborate? There is an adjustment
> made in pte_flags_need_flush().
Note that I did not fully review all bits of this patch set, just
throwing out what was on my mind. If already handled, great.
>
>>
>>>
>>> x86's pte_mkwrite() would then be pretty close to maybe_mkwrite(),
>>> but
>>> maybe it could additionally warn if the vma is not writable. It
>>> also
>>> seems more aligned with your changes to stop taking hints from PTE
>>> bits
>>> and just look at the VMA? (I'm thinking about the dropping of the
>>> dirty
>>> check in GUP and dropping pte_saved_write())
>>
>> The soft-shstk bit wouldn't be a hint, it would be logically
>> changing
>> the "type" of the PTE such that any other PTE functions can do the
>> right
>> thing without having to consume the VMA.
>
> Yea, true.
>
> 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.
Good!
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2023-01-26 8:57 UTC|newest]
Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-19 21:22 [PATCH v5 00/39] Shadow stacks for userspace Rick Edgecombe
2023-01-19 21:22 ` [PATCH v5 01/39] Documentation/x86: Add CET shadow stack description Rick Edgecombe
2023-01-20 0:38 ` Kees Cook
2023-01-19 21:22 ` [PATCH v5 02/39] x86/shstk: Add Kconfig option for shadow stack Rick Edgecombe
2023-01-20 0:40 ` Kees Cook
2023-01-19 21:22 ` [PATCH v5 03/39] x86/cpufeatures: Add CPU feature flags for shadow stacks Rick Edgecombe
2023-01-20 0:44 ` Kees Cook
2023-01-19 21:22 ` [PATCH v5 04/39] x86/cpufeatures: Enable CET CR4 bit for shadow stack Rick Edgecombe
2023-01-20 0:46 ` Kees Cook
2023-01-19 21:22 ` [PATCH v5 05/39] x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states Rick Edgecombe
2023-01-20 0:46 ` Kees Cook
2023-01-19 21:22 ` [PATCH v5 06/39] x86/fpu: Add helper for modifying xstate Rick Edgecombe
2023-01-20 0:47 ` Kees Cook
2023-02-01 11:01 ` Borislav Petkov
2023-02-01 17:31 ` Edgecombe, Rick P
2023-02-01 18:18 ` Borislav Petkov
2023-01-19 21:22 ` [PATCH v5 07/39] x86: Add user control-protection fault handler Rick Edgecombe
2023-01-20 0:50 ` Kees Cook
2023-02-03 19:09 ` Borislav Petkov
2023-02-03 19:24 ` Edgecombe, Rick P
2023-02-03 19:44 ` Borislav Petkov
2023-02-03 23:01 ` Edgecombe, Rick P
2023-02-04 10:37 ` Borislav Petkov
2023-01-19 21:22 ` [PATCH v5 08/39] x86/mm: Remove _PAGE_DIRTY from kernel RO pages Rick Edgecombe
2023-01-20 0:52 ` Kees Cook
2023-01-19 21:22 ` [PATCH v5 09/39] x86/mm: Move pmd_write(), pud_write() up in the file Rick Edgecombe
2023-01-19 21:22 ` [PATCH v5 10/39] x86/mm: Introduce _PAGE_COW Rick Edgecombe
2023-01-20 0:55 ` Kees Cook
2023-01-23 9:16 ` David Hildenbrand
2023-01-23 9:28 ` David Hildenbrand
2023-01-23 20:56 ` Edgecombe, Rick P
2023-01-24 16:28 ` David Hildenbrand
2023-01-19 21:22 ` [PATCH v5 11/39] x86/mm: Update pte_modify for _PAGE_COW Rick Edgecombe
2023-01-20 0:57 ` Kees Cook
2023-02-09 14:08 ` Borislav Petkov
2023-02-09 17:09 ` Edgecombe, Rick P
2023-02-10 13:57 ` Borislav Petkov
2023-02-10 17:00 ` Edgecombe, Rick P
2023-02-17 16:11 ` Borislav Petkov
2023-02-17 16:53 ` Edgecombe, Rick P
2023-01-19 21:22 ` [PATCH v5 12/39] x86/mm: Update ptep_set_wrprotect() and pmdp_set_wrprotect() for transition from _PAGE_DIRTY to _PAGE_COW Rick Edgecombe
2023-01-20 0:58 ` Kees Cook
2023-01-19 21:22 ` [PATCH v5 13/39] x86/mm: Start actually marking _PAGE_COW Rick Edgecombe
2023-01-19 21:22 ` [PATCH v5 14/39] mm: Move VM_UFFD_MINOR_BIT from 37 to 38 Rick Edgecombe
2023-01-19 21:22 ` [PATCH v5 15/39] mm: Introduce VM_SHADOW_STACK for shadow stack memory Rick Edgecombe
2023-01-19 21:22 ` [PATCH v5 16/39] x86/mm: Check shadow stack page fault errors Rick Edgecombe
2023-01-20 0:59 ` Kees Cook
2023-01-19 21:22 ` [PATCH v5 17/39] x86/mm: Update maybe_mkwrite() for shadow stack Rick Edgecombe
2023-01-19 21:22 ` [PATCH v5 18/39] mm: Handle faultless write upgrades for shstk Rick Edgecombe
2023-01-23 9:50 ` David Hildenbrand
2023-01-23 20:47 ` Edgecombe, Rick P
2023-01-24 16:24 ` David Hildenbrand
2023-01-24 18:14 ` Edgecombe, Rick P
2023-01-25 9:27 ` David Hildenbrand
2023-01-25 18:43 ` Edgecombe, Rick P
2023-01-26 0:59 ` Edgecombe, Rick P
2023-01-26 8:46 ` David Hildenbrand
2023-01-26 20:19 ` Edgecombe, Rick P
2023-01-27 16:12 ` David Hildenbrand
2023-01-28 0:51 ` Edgecombe, Rick P
2023-01-31 8:46 ` David Hildenbrand
2023-01-31 23:33 ` Edgecombe, Rick P
2023-02-01 9:03 ` David Hildenbrand
2023-02-01 17:32 ` Edgecombe, Rick P
2023-02-01 18:03 ` David Hildenbrand
2023-01-26 8:57 ` David Hildenbrand [this message]
2023-01-26 20:16 ` Edgecombe, Rick P
2023-01-27 16:19 ` David Hildenbrand
2023-01-19 21:22 ` [PATCH v5 19/39] mm: Fixup places that call pte_mkwrite() directly Rick Edgecombe
2023-01-20 1:01 ` Kees Cook
2023-02-14 0:09 ` Deepak Gupta
2023-02-14 1:07 ` Edgecombe, Rick P
2023-02-14 6:10 ` Deepak Gupta
2023-02-14 18:24 ` Edgecombe, Rick P
2023-02-15 6:37 ` Deepak Gupta
2023-01-19 21:22 ` [PATCH v5 20/39] mm: Add guard pages around a shadow stack Rick Edgecombe
2023-01-19 21:22 ` [PATCH v5 21/39] mm/mmap: Add shadow stack pages to memory accounting Rick Edgecombe
2023-01-19 21:23 ` [PATCH v5 22/39] mm: Re-introduce vm_flags to do_mmap() Rick Edgecombe
2023-01-19 21:23 ` [PATCH v5 23/39] mm: Don't allow write GUPs to shadow stack memory Rick Edgecombe
2023-01-23 9:10 ` David Hildenbrand
2023-01-23 10:45 ` Florian Weimer
2023-01-23 20:46 ` Edgecombe, Rick P
2023-01-24 16:26 ` David Hildenbrand
2023-01-24 18:42 ` Edgecombe, Rick P
2023-01-24 23:08 ` Kees Cook
2023-01-24 23:41 ` Edgecombe, Rick P
2023-01-25 9:29 ` David Hildenbrand
2023-01-25 15:23 ` Kees Cook
2023-01-25 15:36 ` Schimpe, Christina
2023-01-25 16:43 ` Schimpe, Christina
2023-01-19 21:23 ` [PATCH v5 24/39] x86/mm: Introduce MAP_ABOVE4G Rick Edgecombe
2023-01-19 21:23 ` [PATCH v5 25/39] mm: Warn on shadow stack memory in wrong vma Rick Edgecombe
2023-01-20 1:01 ` Kees Cook
2023-01-19 21:23 ` [PATCH v5 26/39] x86: Introduce userspace API for shadow stack Rick Edgecombe
2023-01-20 1:04 ` Kees Cook
2023-01-19 21:23 ` [PATCH v5 27/39] x86/shstk: Add user-mode shadow stack support Rick Edgecombe
2023-01-20 1:05 ` Kees Cook
2023-01-19 21:23 ` [PATCH v5 28/39] x86/shstk: Handle thread shadow stack Rick Edgecombe
2023-01-19 21:23 ` [PATCH v5 29/39] x86/shstk: Introduce routines modifying shstk Rick Edgecombe
2023-01-20 1:05 ` Kees Cook
2023-01-19 21:23 ` [PATCH v5 30/39] x86/shstk: Handle signals for shadow stack Rick Edgecombe
2023-01-19 21:23 ` [PATCH v5 31/39] x86/shstk: Introduce map_shadow_stack syscall Rick Edgecombe
2023-01-20 1:07 ` Kees Cook
2023-01-19 21:23 ` [PATCH v5 32/39] x86/shstk: Support WRSS for userspace Rick Edgecombe
2023-01-20 1:06 ` Kees Cook
2023-01-19 21:23 ` [PATCH v5 33/39] x86: Expose thread features in /proc/$PID/status Rick Edgecombe
2023-01-19 21:23 ` [PATCH v5 34/39] x86/shstk: Wire in shadow stack interface Rick Edgecombe
2023-01-19 21:23 ` [PATCH v5 35/39] selftests/x86: Add shadow stack test Rick Edgecombe
2023-01-19 21:23 ` [PATCH v5 36/39] x86/fpu: Add helper for initing features Rick Edgecombe
2023-01-19 21:23 ` [PATCH v5 37/39] x86: Add PTRACE interface for shadow stack Rick Edgecombe
2023-01-20 1:08 ` Kees Cook
2023-01-19 21:23 ` [PATCH v5 38/39] x86/shstk: Add ARCH_SHSTK_UNLOCK Rick Edgecombe
2023-01-19 21:23 ` [PATCH v5 39/39] x86/shstk: Add ARCH_SHSTK_STATUS Rick Edgecombe
2023-01-20 1:08 ` Kees Cook
2023-01-19 22:26 ` [PATCH v5 00/39] Shadow stacks for userspace Andrew Morton
2023-01-20 17:27 ` Edgecombe, Rick P
2023-01-20 19:19 ` Kees Cook
2023-01-25 19:46 ` Edgecombe, Rick P
2023-01-20 17:48 ` John Allen
2023-01-22 8:20 ` Mike Rapoport
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=79e0a85e-1ec4-e359-649d-618ca79c36f7@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andrew.cooper3@citrix.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=bsingharora@gmail.com \
--cc=christina.schimpe@intel.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=dethoma@microsoft.com \
--cc=eranian@google.com \
--cc=esyr@redhat.com \
--cc=fweimer@redhat.com \
--cc=gorcunov@gmail.com \
--cc=hjl.tools@gmail.com \
--cc=hpa@zytor.com \
--cc=jamorris@linux.microsoft.com \
--cc=jannh@google.com \
--cc=john.allen@amd.com \
--cc=kcc@google.com \
--cc=keescook@chromium.org \
--cc=kirill.shutemov@linux.intel.com \
--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@kernel.org \
--cc=mike.kravetz@oracle.com \
--cc=mingo@redhat.com \
--cc=nadav.amit@gmail.com \
--cc=oleg@redhat.com \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rppt@kernel.org \
--cc=tglx@linutronix.de \
--cc=weijiang.yang@intel.com \
--cc=x86@kernel.org \
--cc=yu-cheng.yu@intel.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;
as well as URLs for NNTP newsgroup(s).