Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [patch V4 part 1 08/36] x86/doublefault: Remove memmove() call
To:     Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>
Cc:     x86@kernel.org, "Paul E. McKenney" <paulmck@kernel.org>,
        Andy Lutomirski <luto@kernel.org>,
        Frederic Weisbecker <frederic@kernel.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Sean Christopherson <sean.j.christopherson@intel.com>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Petr Mladek <pmladek@suse.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Joel Fernandes <joel@joelfernandes.org>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        Juergen Gross <jgross@suse.com>,
        Brian Gerst <brgerst@gmail.com>,
        Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Will Deacon <will@kernel.org>, Borislav Petkov <bp@alien8.de>,
        "Peter Zijlstra (Intel)" <peterz@infradead.org>
References: <20200505131602.633487962@linutronix.de>
 <20200505134058.863038566@linutronix.de>
From:   Alexandre Chartre <alexandre.chartre@oracle.com>
Message-ID: <426fb037-9573-f616-6015-b732f66493c0@oracle.com>
Date:   Wed, 6 May 2020 15:47:03 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <20200505134058.863038566@linutronix.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On 5/5/20 3:16 PM, Thomas Gleixner wrote:
> Use of memmove() in #DF is problematic considered tracing and other
> instrumentation.
> 
> Remove the memmove() call and simply write out what needs doing; this
> even clarifies the code, win-win! The code copies from the espfix64
> stack to the normal task stack, there is no possible way for that to
> overlap.
> 
> Survives selftests/x86, specifically sigreturn_64.
> 
> Suggested-by: Borislav Petkov <bp@alien8.de>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Acked-by: Andy Lutomirski <luto@kernel.org>
> Link: https://lkml.kernel.org/r/20200220121727.GB507@zn.tnic
> ---
>   arch/x86/kernel/traps.c |    7 ++++++-
>   1 file changed, 6 insertions(+), 1 deletion(-)

Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>

alex.

> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -278,6 +278,7 @@ dotraplinkage void do_double_fault(struc
>   		regs->ip == (unsigned long)native_irq_return_iret)
>   	{
>   		struct pt_regs *gpregs = (struct pt_regs *)this_cpu_read(cpu_tss_rw.x86_tss.sp0) - 1;
> +		unsigned long *p = (unsigned long *)regs->sp;
>   
>   		/*
>   		 * regs->sp points to the failing IRET frame on the
> @@ -285,7 +286,11 @@ dotraplinkage void do_double_fault(struc
>   		 * in gpregs->ss through gpregs->ip.
>   		 *
>   		 */
> -		memmove(&gpregs->ip, (void *)regs->sp, 5*8);
> +		gpregs->ip	= p[0];
> +		gpregs->cs	= p[1];
> +		gpregs->flags	= p[2];
> +		gpregs->sp	= p[3];
> +		gpregs->ss	= p[4];
>   		gpregs->orig_ax = 0;  /* Missing (lost) #GP error code */
>   
>   		/*
>