All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: "Yu, Yu-cheng" <yu-cheng.yu@intel.com>
Cc: Andy Lutomirski <luto@kernel.org>, X86 ML <x86@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Balbir Singh <bsingharora@gmail.com>,
	Borislav Petkov <bp@alien8.de>,
	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>
Subject: Re: [PATCH v13 8/8] x86/vsyscall/64: Fixup Shadow Stack and Indirect Branch Tracking for vsyscall emulation
Date: Fri, 25 Sep 2020 09:51:14 -0700	[thread overview]
Message-ID: <99B32E59-CFF2-4756-89BD-AEA0021F355F@amacapital.net> (raw)
In-Reply-To: <d0e4077e-129f-6823-dcea-a101ef626e8c@intel.com>



> On Sep 25, 2020, at 9:48 AM, Yu, Yu-cheng <yu-cheng.yu@intel.com> wrote:
> 
> On 9/25/2020 9:31 AM, Andy Lutomirski wrote:
>>> On Fri, Sep 25, 2020 at 7:58 AM Yu-cheng Yu <yu-cheng.yu@intel.com> wrote:
>>> 
> 
> [...]
> 
>>> @@ -286,6 +289,37 @@ bool emulate_vsyscall(unsigned long error_code,
>>>         /* Emulate a ret instruction. */
>>>         regs->ip = caller;
>>>         regs->sp += 8;
>>> +
>>> +#ifdef CONFIG_X86_CET
>>> +       if (tsk->thread.cet.shstk_size || tsk->thread.cet.ibt_enabled) {
>>> +               struct cet_user_state *cet;
>>> +               struct fpu *fpu;
>>> +
>>> +               fpu = &tsk->thread.fpu;
>>> +               fpregs_lock();
>>> +
>>> +               if (!test_thread_flag(TIF_NEED_FPU_LOAD)) {
>>> +                       copy_fpregs_to_fpstate(fpu);
>>> +                       set_thread_flag(TIF_NEED_FPU_LOAD);
>>> +               }
>>> +
>>> +               cet = get_xsave_addr(&fpu->state.xsave, XFEATURE_CET_USER);
>>> +               if (!cet) {
>>> +                       fpregs_unlock();
>>> +                       goto sigsegv;
>> I *think* your patchset tries to keep cet.shstk_size and
>> cet.ibt_enabled in sync with the MSR, in which case it should be
>> impossible to get here, but a comment and a warning would be much
>> better than a random sigsegv.
> 
> Yes, it should be impossible to get here.  I will add a comment and a warning, but still do sigsegv.  Should this happen, and the function return, the app gets a control-protection fault.  Why not let it fail early?

I’m okay with either approach as long as we get a comment and warning.

> 
>> 
>> Shouldn't we have a get_xsave_addr_or_allocate() that will never
>> return NULL but instead will mark the state as in use and set up the
>> init state if the feature was previously not in use?
> 
> We already have a static __raw_xsave_addr(), which returns a pointer to the requested xstate.  Maybe we can export __raw_xsave_addr(), if that is needed.

I don’t think that’s what we want in general — we want the whole construct of initializing the state if needed.

  reply	other threads:[~2020-09-25 16:51 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-25 14:57 [PATCH v13 0/8] Control-flow Enforcement: Indirect Branch Tracking Yu-cheng Yu
2020-09-25 14:57 ` [PATCH v13 1/8] x86/cet/ibt: Add Kconfig option for user-mode " Yu-cheng Yu
2020-09-25 14:57 ` [PATCH v13 2/8] x86/cet/ibt: User-mode Indirect Branch Tracking support Yu-cheng Yu
2020-09-25 14:57 ` [PATCH v13 3/8] x86/cet/ibt: Handle signals for Indirect Branch Tracking Yu-cheng Yu
2020-09-25 14:58 ` [PATCH v13 4/8] x86/cet/ibt: ELF header parsing " Yu-cheng Yu
2020-09-25 14:58 ` [PATCH v13 5/8] x86/cet/ibt: Update arch_prctl functions " Yu-cheng Yu
2020-09-25 14:58 ` [PATCH v13 6/8] x86/vdso/32: Add ENDBR32 to __kernel_vsyscall entry point Yu-cheng Yu
2020-09-25 14:58 ` [PATCH v13 7/8] x86/vdso: Insert endbr32/endbr64 to vDSO Yu-cheng Yu
2020-09-25 16:18   ` Andy Lutomirski
2020-09-25 16:18     ` Andy Lutomirski
2020-09-25 16:24     ` Yu, Yu-cheng
2020-09-25 14:58 ` [PATCH v13 8/8] x86/vsyscall/64: Fixup Shadow Stack and Indirect Branch Tracking for vsyscall emulation Yu-cheng Yu
2020-09-25 16:31   ` Andy Lutomirski
2020-09-25 16:31     ` Andy Lutomirski
2020-09-25 16:47     ` Yu, Yu-cheng
2020-09-25 16:51       ` Andy Lutomirski [this message]
2020-09-28 16:59         ` Yu-cheng Yu
2020-09-28 16:59           ` Yu-cheng Yu
2020-09-28 17:37           ` Andy Lutomirski
2020-09-28 17:37             ` Andy Lutomirski
2020-09-28 19:04             ` Yu, Yu-cheng
2020-09-29 18:37             ` Yu, Yu-cheng
2020-09-29 19:57               ` Andy Lutomirski
2020-09-29 19:57                 ` Andy Lutomirski
2020-09-29 20:00                 ` Andy Lutomirski
2020-09-29 20:00                   ` Andy Lutomirski
2020-09-30 22:33                   ` Yu, Yu-cheng
2020-09-30 23:44                     ` Andy Lutomirski
2020-09-30 23:44                       ` Andy Lutomirski
2020-10-01  1:00                       ` H.J. Lu
2020-10-01  1:00                         ` H.J. Lu
2020-10-01  1:10                         ` Andy Lutomirski
2020-10-01  1:10                           ` Andy Lutomirski
2020-10-01  1:21                           ` H.J. Lu
2020-10-01  1:21                             ` H.J. Lu
2020-10-01 16:51                           ` Yu, Yu-cheng
2020-10-01 17:26                             ` Andy Lutomirski
2020-10-01 17:26                               ` Andy Lutomirski
2020-10-06 19:09                               ` Yu, Yu-cheng
2020-10-09 17:42                                 ` Andy Lutomirski
2020-10-09 17:42                                   ` Andy Lutomirski

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=99B32E59-CFF2-4756-89BD-AEA0021F355F@amacapital.net \
    --to=luto@amacapital.net \
    --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=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 \
    --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 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.