From: Lai Jiangshan <laijs@linux.alibaba.com>
To: Steven Rostedt <rostedt@goodmis.org>,
Lai Jiangshan <jiangshanlai@gmail.com>
Cc: linux-kernel@vger.kernel.org, Andy Lutomirski <luto@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Juergen Gross <jgross@suse.com>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Arvind Sankar <nivedita@alum.mit.edu>
Subject: Re: [RFC PATCH 1/4] x86/entry/nmi: Switch to the entry stack before switching to the thread stack
Date: Wed, 2 Jun 2021 08:09:25 +0800 [thread overview]
Message-ID: <6aa4a193-e596-9c01-6b36-0c25410ebb82@linux.alibaba.com> (raw)
In-Reply-To: <20210601130537.7b389804@oasis.local.home>
On 2021/6/2 01:05, Steven Rostedt wrote:
> On Tue, 1 Jun 2021 14:52:14 +0800
> Lai Jiangshan <jiangshanlai@gmail.com> wrote:
>
>> From: Lai Jiangshan <laijs@linux.alibaba.com>
>>
>> Current kernel has no code to enforce data breakpoint not on the thread
>> stack. If there is any data breakpoint on the top area of the thread
>> stack, there might be problem.
>>
>> For example, when NMI hits on userspace in this setting, the code copies
>> the exception frame from the NMI stack to the thread stack and it will
>> cause #DB and after #DB is handled, the not yet copied portion on the
>> NMI stack is in danger of corruption because the NMI is unmasked.
>>
>> Stashing the exception frame on the entry stack before touching the
>> entry stack can fix the problem.
>>
>> Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com>
>> ---
>> arch/x86/entry/entry_64.S | 22 ++++++++++++++++++++++
>> arch/x86/kernel/asm-offsets.c | 1 +
>> 2 files changed, 23 insertions(+)
>>
>> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
>> index a5f02d03c585..4190e668f346 100644
>> --- a/arch/x86/entry/entry_64.S
>> +++ b/arch/x86/entry/entry_64.S
>> @@ -1121,8 +1121,30 @@ SYM_CODE_START(asm_exc_nmi)
>> *
>> * We also must not push anything to the stack before switching
>> * stacks lest we corrupt the "NMI executing" variable.
>> + *
>> + * Before switching to the thread stack, it switches to the entry
>> + * stack first lest there is any data breakpoint in the thread
>> + * stack and the iret of #DB will cause NMI unmasked before
>> + * finishing switching.
>> */
>>
>> + /* Switch stack to entry stack */
>> + movq %rsp, %rdx
>> + addq $(+6*8 /* to NMI stack top */ \
>> + -EXCEPTION_STKSZ /* to NMI stack bottom */ \
>> + -CPU_ENTRY_AREA_nmi_stack /* to entry area */ \
>
> Just so that I understand this correctly. This "entry area" is not part
> of the NMI stack, but just at the bottom of it? That is, this part of
> the stack will never be touched by an NMI coming in from kernel space,
> correct?
This "entry area" is the pointer of current CPU's struct cpu_entry_area.
This instruction puts %rsp onto the top of the entry/trampoline stack
which is not touched by an NMI coming in from kernel space.
>
> -- Steve
>
>
>> + +CPU_ENTRY_AREA_entry_stack /* to entry stack bottom */\
>> + +SIZEOF_entry_stack /* to entry stack top */ \
>> + ), %rsp
>> +
>> + /* Stash exception frame and %rdx to entry stack */
>> + pushq 5*8(%rdx) /* pt_regs->ss */
>> + pushq 4*8(%rdx) /* pt_regs->rsp */
>> + pushq 3*8(%rdx) /* pt_regs->flags */
>> + pushq 2*8(%rdx) /* pt_regs->cs */
>> + pushq 1*8(%rdx) /* pt_regs->rip */
>> + pushq 0*8(%rdx) /* %rdx */
>> +
>> swapgs
>> cld
>> FENCE_SWAPGS_USER_ENTRY
>> diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
>> index ecd3fd6993d1..dfafa0c7e887 100644
>> --- a/arch/x86/kernel/asm-offsets.c
>> +++ b/arch/x86/kernel/asm-offsets.c
>> @@ -88,6 +88,7 @@ static void __used common(void)
>> OFFSET(CPU_ENTRY_AREA_entry_stack, cpu_entry_area, entry_stack_page);
>> DEFINE(SIZEOF_entry_stack, sizeof(struct entry_stack));
>> DEFINE(MASK_entry_stack, (~(sizeof(struct entry_stack) - 1)));
>> + OFFSET(CPU_ENTRY_AREA_nmi_stack, cpu_entry_area, estacks.NMI_stack);
>>
>> /* Offset for fields in tss_struct */
>> OFFSET(TSS_sp0, tss_struct, x86_tss.sp0);
next prev parent reply other threads:[~2021-06-02 0:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-01 6:52 [RFC PATCH 0/4] x86/entry/nmi: solidify userspace NMI entry Lai Jiangshan
2021-06-01 6:52 ` [RFC PATCH 1/4] x86/entry/nmi: Switch to the entry stack before switching to the thread stack Lai Jiangshan
2021-06-01 17:05 ` Steven Rostedt
2021-06-02 0:09 ` Lai Jiangshan [this message]
2021-06-02 0:16 ` Lai Jiangshan
2021-06-19 22:51 ` Thomas Gleixner
2021-06-20 3:13 ` Andy Lutomirski
2021-06-20 11:23 ` Thomas Gleixner
2021-06-25 10:40 ` Peter Zijlstra
2021-06-25 11:00 ` Peter Zijlstra
2021-06-26 7:03 ` Thomas Gleixner
2021-06-26 8:28 ` Peter Zijlstra
2021-06-01 6:52 ` [RFC PATCH 2/4] x86/entry/nmi: Use normal idtentry macro for NMI from userspace Lai Jiangshan
2021-06-03 17:36 ` Andy Lutomirski
2021-06-01 6:52 ` [RFC PATCH 3/4] x86/entry: Remove parameter rdx from macro PUSH_AND_CLEAR_REGS and PUSH_REGS Lai Jiangshan
2021-06-01 6:52 ` [RFC PATCH 4/4] x86/entry/nmi: unmask NMIs on userspace NMI when entry debugging Lai Jiangshan
2021-06-03 17:38 ` 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=6aa4a193-e596-9c01-6b36-0c25410ebb82@linux.alibaba.com \
--to=laijs@linux.alibaba.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=jiangshanlai@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=nivedita@alum.mit.edu \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=viro@zeniv.linux.org.uk \
--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
Powered by JetHome