From: "Yu, Yu-cheng" <yu-cheng.yu@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: 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@kernel.org>,
Balbir Singh <bsingharora@gmail.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Eugene Syromiatnikov <esyr@redhat.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@chromium.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>,
Randy Dunlap <rdunlap@infradead.org>,
"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>,
Dave Martin <Dave.Martin@arm.com>,
Weijiang Yang <weijiang.yang@intel.com>,
Pengfei Xu <pengfei.xu@intel.com>,
Haitao Huang <haitao.huang@intel.com>
Subject: Re: [PATCH v26 22/30] x86/cet/shstk: Add user-mode shadow stack support
Date: Wed, 28 Apr 2021 11:39:00 -0700 [thread overview]
Message-ID: <3a0ed2e3-b13d-0db6-87af-fecd394ddd2e@intel.com> (raw)
In-Reply-To: <YImg5hmBnTZTkYIp@zn.tnic>
On 4/28/2021 10:52 AM, Borislav Petkov wrote:
> On Tue, Apr 27, 2021 at 01:43:07PM -0700, Yu-cheng Yu wrote:
>> @@ -535,6 +536,10 @@ struct thread_struct {
>>
>> unsigned int sig_on_uaccess_err:1;
>>
>> +#ifdef CONFIG_X86_SHADOW_STACK
>> + struct cet_status cet;
>
> A couple of versions ago I said:
>
> " struct shstk_desc shstk;
>
> or so"
>
> but no movement here. That thing is still called cet_status even though
> there's nothing status-related with it.
>
> So what's up?
>
Sorry about that. After that email thread, we went ahead to separate
shadow stack and ibt into different files. I thought about the struct,
the file names cet.h, etc. The struct still needs to include ibt
status, and if it is shstk_desc, the name is not entirely true. One
possible approach is, we don't make it a struct here, and put every item
directly in thread_struct. However, the benefit of putting all in a
struct is understandable (you might argue the opposite :-)). Please
make the call, and I will do the change.
>> +static unsigned long alloc_shstk(unsigned long size)
>> +{
>> + struct mm_struct *mm = current->mm;
>> + unsigned long addr, populate;
>> + int flags = MAP_ANONYMOUS | MAP_PRIVATE;
>
> The tip-tree preferred ordering of variable declarations at the
> beginning of a function is reverse fir tree order::
>
> struct long_struct_name *descriptive_name;
> unsigned long foo, bar;
> unsigned int tmp;
> int ret;
>
> The above is faster to parse than the reverse ordering::
>
> int ret;
> unsigned int tmp;
> unsigned long foo, bar;
> struct long_struct_name *descriptive_name;
>
> And even more so than random ordering::
>
> unsigned long foo, bar;
> int ret;
> struct long_struct_name *descriptive_name;
> unsigned int tmp;
>
> Please fix it up everywhere.
>
Ok!
>> + mmap_write_lock(mm);
>> + addr = do_mmap(NULL, 0, size, PROT_READ, flags, VM_SHADOW_STACK, 0,
>> + &populate, NULL);
>> + mmap_write_unlock(mm);
>> +
>> + return addr;
>> +}
>> +
>> +int shstk_setup(void)
>> +{
>> + unsigned long addr, size;
>> + struct cet_status *cet = ¤t->thread.cet;
>> +
>> + if (!cpu_feature_enabled(X86_FEATURE_SHSTK))
>> + return -EOPNOTSUPP;
>> +
>> + size = round_up(min_t(unsigned long long, rlimit(RLIMIT_STACK), SZ_4G), PAGE_SIZE);
>> + addr = alloc_shstk(size);
>> + if (IS_ERR_VALUE(addr))
>> + return PTR_ERR((void *)addr);
>> +
>> + cet->shstk_base = addr;
>> + cet->shstk_size = size;
>> +
>> + start_update_msrs();
>> + wrmsrl(MSR_IA32_PL3_SSP, addr + size);
>> + wrmsrl(MSR_IA32_U_CET, CET_SHSTK_EN);
>> + end_update_msrs();
>
> <---- newline here.
>
>> + return 0;
>> +}
>> +
>> +void shstk_free(struct task_struct *tsk)
>> +{
>> + struct cet_status *cet = &tsk->thread.cet;
>> +
>> + if (!cpu_feature_enabled(X86_FEATURE_SHSTK) ||
>> + !cet->shstk_size ||
>> + !cet->shstk_base)
>> + return;
>> +
>> + if (!tsk->mm)
>> + return;
>
> Where are the comments you said you wanna add:
>
> https://lkml.kernel.org/r/b05ee7eb-1b5d-f84f-c8f3-bfe9426e8a7d@intel.com
>
> ?
>
Yes, the comments are in patch #23: Handle thread shadow stack. I
wanted to add that in the patch that takes the path.
>> +
>> + while (1) {
>> + int r;
>> +
>> + r = vm_munmap(cet->shstk_base, cet->shstk_size);
>
> int r = vm_munmap...
>
>> +
>> + /*
>> + * vm_munmap() returns -EINTR when mmap_lock is held by
>> + * something else, and that lock should not be held for a
>> + * long time. Retry it for the case.
>> + */
>> + if (r == -EINTR) {
>> + cond_resched();
>> + continue;
>> + }
>> + break;
>> + }
>
> vm_munmap() can return other negative error values, where are you
> handling those?
>
For other error values, the loop stops.
>> +
>> + cet->shstk_base = 0;
>> + cet->shstk_size = 0;
>> +}
>> +
>> +void shstk_disable(void)
>> +{
>> + struct cet_status *cet = ¤t->thread.cet;
>
> Same question as before: what guarantees that current doesn't change
> from under you here?
The actual reading/writing MSRs are protected by fpregs_lock().
>
> One of the worst thing to do is to ignore review comments. I'd strongly
> suggest you pay more attention and avoid that in the future.
>
> Thx.
>
next prev parent reply other threads:[~2021-04-28 18:39 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-27 20:42 [PATCH v26 00/30] Control-flow Enforcement: Shadow Stack Yu-cheng Yu
2021-04-27 20:42 ` [PATCH v26 01/30] Documentation/x86: Add CET description Yu-cheng Yu
2021-04-27 20:42 ` [PATCH v26 02/30] x86/cet/shstk: Add Kconfig option for Shadow Stack Yu-cheng Yu
2021-04-27 20:42 ` [PATCH v26 03/30] x86/cpufeatures: Add CET CPU feature flags for Control-flow Enforcement Technology (CET) Yu-cheng Yu
2021-04-27 20:42 ` [PATCH v26 04/30] x86/cpufeatures: Introduce CPU setup and option parsing for CET Yu-cheng Yu
2021-04-27 20:42 ` [PATCH v26 05/30] x86/fpu/xstate: Introduce CET MSR and XSAVES supervisor states Yu-cheng Yu
2021-04-27 20:42 ` [PATCH v26 06/30] x86/cet: Add control-protection fault handler Yu-cheng Yu
2021-04-27 20:42 ` [PATCH v26 07/30] x86/mm: Remove _PAGE_DIRTY from kernel RO pages Yu-cheng Yu
2021-04-27 20:42 ` [PATCH v26 08/30] x86/mm: Move pmd_write(), pud_write() up in the file Yu-cheng Yu
2021-04-27 20:42 ` [PATCH v26 09/30] x86/mm: Introduce _PAGE_COW Yu-cheng Yu
2021-04-27 20:42 ` [PATCH v26 10/30] drm/i915/gvt: Change _PAGE_DIRTY to _PAGE_DIRTY_BITS Yu-cheng Yu
2021-04-27 20:42 ` [PATCH v26 11/30] x86/mm: Update pte_modify for _PAGE_COW Yu-cheng Yu
2021-04-27 20:42 ` [PATCH v26 12/30] x86/mm: Update ptep_set_wrprotect() and pmdp_set_wrprotect() for transition from _PAGE_DIRTY to _PAGE_COW Yu-cheng Yu
2021-04-27 20:42 ` [PATCH v26 13/30] mm: Introduce VM_SHADOW_STACK for shadow stack memory Yu-cheng Yu
2021-04-27 20:42 ` [PATCH v26 14/30] x86/mm: Shadow Stack page fault error checking Yu-cheng Yu
2021-04-27 20:43 ` [PATCH v26 15/30] x86/mm: Update maybe_mkwrite() for shadow stack Yu-cheng Yu
2021-04-27 20:43 ` [PATCH v26 16/30] mm: Fixup places that call pte_mkwrite() directly Yu-cheng Yu
2021-04-27 20:43 ` [PATCH v26 17/30] mm: Add guard pages around a shadow stack Yu-cheng Yu
2021-04-27 20:43 ` [PATCH v26 18/30] mm/mmap: Add shadow stack pages to memory accounting Yu-cheng Yu
2021-04-27 20:43 ` [PATCH v26 19/30] mm: Update can_follow_write_pte() for shadow stack Yu-cheng Yu
2021-04-27 20:43 ` [PATCH v26 20/30] mm/mprotect: Exclude shadow stack from preserve_write Yu-cheng Yu
2021-04-27 20:43 ` [PATCH v26 21/30] mm: Re-introduce vm_flags to do_mmap() Yu-cheng Yu
2021-04-27 20:43 ` [PATCH v26 22/30] x86/cet/shstk: Add user-mode shadow stack support Yu-cheng Yu
2021-04-28 17:52 ` Borislav Petkov
2021-04-28 18:39 ` Yu, Yu-cheng [this message]
2021-04-29 9:12 ` Borislav Petkov
2021-04-29 16:17 ` Yu, Yu-cheng
2021-04-29 16:45 ` Borislav Petkov
2021-04-27 20:43 ` [PATCH v26 23/30] x86/cet/shstk: Handle thread shadow stack Yu-cheng Yu
2021-05-10 14:15 ` Borislav Petkov
2021-05-10 22:57 ` Yu, Yu-cheng
2021-05-11 17:09 ` Borislav Petkov
2021-05-12 8:12 ` David Laight
2021-05-11 18:35 ` Yu, Yu-cheng
2021-05-12 15:56 ` Borislav Petkov
2021-04-27 20:43 ` [PATCH v26 24/30] x86/cet/shstk: Introduce shadow stack token setup/verify routines Yu-cheng Yu
2021-05-17 7:45 ` Borislav Petkov
2021-05-17 20:55 ` Yu, Yu-cheng
2021-05-18 0:14 ` Eugene Syromiatnikov
2021-05-18 17:58 ` Borislav Petkov
2021-05-18 19:45 ` Yu, Yu-cheng
2021-05-18 18:05 ` Yu, Yu-cheng
2021-05-18 5:56 ` Borislav Petkov
2021-05-21 16:17 ` Yu, Yu-cheng
2021-05-21 18:40 ` Borislav Petkov
2021-04-27 20:43 ` [PATCH v26 25/30] x86/cet/shstk: Handle signals for shadow stack Yu-cheng Yu
2021-04-28 23:03 ` extending ucontext (Re: [PATCH v26 25/30] x86/cet/shstk: Handle signals for shadow stack) Andy Lutomirski
2021-04-28 23:20 ` Yu, Yu-cheng
2021-04-29 7:28 ` Cyrill Gorcunov
2021-04-29 14:44 ` Andy Lutomirski
2021-04-29 15:35 ` Cyrill Gorcunov
2021-04-30 6:45 ` Florian Weimer
2021-04-30 17:00 ` Yu, Yu-cheng
2021-04-30 17:47 ` Andy Lutomirski
2021-04-30 18:32 ` Yu, Yu-cheng
2021-05-04 20:49 ` Yu, Yu-cheng
2021-05-06 22:05 ` Yu, Yu-cheng
2021-05-06 23:31 ` Andy Lutomirski
2021-05-02 23:23 ` Andy Lutomirski
2021-05-03 6:03 ` H. Peter Anvin
2021-05-03 15:13 ` Yu, Yu-cheng
2021-05-03 15:29 ` Andy Lutomirski
2021-05-03 20:25 ` Yu, Yu-cheng
2021-04-27 20:43 ` [PATCH v26 26/30] ELF: Introduce arch_setup_elf_property() Yu-cheng Yu
2021-05-19 18:10 ` Borislav Petkov
2021-05-19 22:14 ` Yu, Yu-cheng
2021-05-20 9:26 ` Borislav Petkov
2021-05-20 17:18 ` Yu, Yu-cheng
2021-05-20 17:35 ` Borislav Petkov
2021-05-20 17:51 ` Yu, Yu-cheng
2021-05-20 17:38 ` Matthew Wilcox
2021-05-20 17:52 ` Yu, Yu-cheng
2021-05-20 21:06 ` Yu, Yu-cheng
2021-04-27 20:43 ` [PATCH v26 27/30] x86/cet/shstk: Add arch_prctl functions for shadow stack Yu-cheng Yu
2021-04-27 20:43 ` [PATCH v26 28/30] mm: Move arch_calc_vm_prot_bits() to arch/x86/include/asm/mman.h Yu-cheng Yu
2021-04-27 20:43 ` [PATCH v26 29/30] mm: Update arch_validate_flags() to test vma anonymous Yu-cheng Yu
2021-05-11 11:35 ` Kirill A. Shutemov
2021-04-27 20:43 ` [PATCH v26 30/30] mm: Introduce PROT_SHADOW_STACK for shadow stack Yu-cheng Yu
2021-05-11 11:48 ` Kirill A. Shutemov
2021-05-11 14:44 ` Yu, Yu-cheng
2021-04-29 17:13 ` [PATCH v26 00/30] Control-flow Enforcement: Shadow Stack Borislav Petkov
2021-04-29 17:32 ` Yu, Yu-cheng
2021-04-29 17:49 ` Borislav Petkov
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=3a0ed2e3-b13d-0db6-87af-fecd394ddd2e@intel.com \
--to=yu-cheng.yu@intel.com \
--cc=Dave.Martin@arm.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=bsingharora@gmail.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=esyr@redhat.com \
--cc=fweimer@redhat.com \
--cc=gorcunov@gmail.com \
--cc=haitao.huang@intel.com \
--cc=hjl.tools@gmail.com \
--cc=hpa@zytor.com \
--cc=jannh@google.com \
--cc=keescook@chromium.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@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=pengfei.xu@intel.com \
--cc=peterz@infradead.org \
--cc=ravi.v.shankar@intel.com \
--cc=rdunlap@infradead.org \
--cc=tglx@linutronix.de \
--cc=vedvyas.shanbhogue@intel.com \
--cc=weijiang.yang@intel.com \
--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 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).