Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3419289imm; Thu, 17 May 2018 08:28:48 -0700 (PDT) X-Google-Smtp-Source: AB8JxZq74+Tsel3VDTjnm1V2V0/DORk6EXrL3+DUGsOUvkoza6Yi4FfoAw7Ydi5WQM9kII2yoIh+ X-Received: by 2002:a17:902:bb07:: with SMTP id l7-v6mr5709318pls.128.1526570928047; Thu, 17 May 2018 08:28:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526570928; cv=none; d=google.com; s=arc-20160816; b=pjSBjmUBoHMLMmzixx2jZ7o66cwYF68AcgtrsFWfTPe0Jk4hBzLXgL1Q0ZDG6KJNL2 ZQT70R7hSTPe1vl5DsJ9vm60VwOeHx0c9Mj57Q66ckgHlX30QIMcY86WV2YNSOwWqtFD /KLXQn60KLDMfiTT8HX8L50VpF72C1l/tVlydUbY9nOy53lSrZCs3hNSY6lrIrKNjMfW Tb6DF+9OD13/05AxWvNbBdmnL5K/hbmK4c64J547vO14nz+ZsBfLHsPg0ehid7prmvm4 8gLIl5B6MTKRN64UgWDHslE6udHg/q7LQ+U8i41YhueOIyUwoCOOWTAbD0S747n/wT7u G1Lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:thread-index:thread-topic :content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:dkim-signature:dkim-filter :arc-authentication-results; bh=5SXGRhKkMURiTQjQC5Sg8148nDJ1n7jjfdQRISaTqWU=; b=IuUnlct2q2qDZPb8sPZGguo2ofa7k1rIfpcZ4fSYG2sqdAIG0bcdEjtjuyYMfe9kJ2 Fa4aZILiCh9h5TvzUFRkpqjKvx4P23GuDBTUrZDsjoodhttzETtWPYUeDSP8Qh5chi6U SXYGQRh+/FptHV7VW0OycORlVIrNfycz7mxdO3jSh4xlOtZzgAA3af3bjIEZUozuXZil 9Fid2QzKEmIZ92Fpy4fLy0JLyMI277IeHHXO7dSVur82F9trJeYdMnHrUy8SjKo6n3Wz S/aevgUBOFUiQo5bMO/kzmYImmIW8HDt7v9J8U58jLbpBz0p7LHAAo7irV2odR5+p784 6TLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b=p53qf0Z9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q22-v6si5414576pfi.282.2018.05.17.08.28.33; Thu, 17 May 2018 08:28:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b=p53qf0Z9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752191AbeEQP2N (ORCPT + 99 others); Thu, 17 May 2018 11:28:13 -0400 Received: from mail.efficios.com ([167.114.142.138]:40412 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751293AbeEQP2L (ORCPT ); Thu, 17 May 2018 11:28:11 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id D78371C0141; Thu, 17 May 2018 11:28:10 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail02.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 4G9HNyMBzorJ; Thu, 17 May 2018 11:28:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 208431C013B; Thu, 17 May 2018 11:28:10 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 208431C013B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1526570890; bh=5SXGRhKkMURiTQjQC5Sg8148nDJ1n7jjfdQRISaTqWU=; h=Date:From:To:Message-ID:MIME-Version; b=p53qf0Z9PCUaOd10mwvedAp1uNAi/pj6vfJmxAx6WNHMDsFBCIzIV5Yvx2RsQDInf y5DXKA69EcUbRl2+BUIRlFOB0nHEI5y/xX6AR0nASTWaeCljRQf5IMyQtfcdgoMPEH gimPLEHzaUncCYJ3+w0wUlvZJmUNo7FAI4hOyot8cY0M8oPGZJOAlq6D9Tvd6NMsHl wwq/2BwcqmicStTjSTJqvxx8cYMTW+1PXb0k0rXEU+kZndRQ7qL7aO6XAY/ETkduwM UOo2hWaBN4wjMLLBWZmUmJ6EY4sEqVLWIJlNeuPezD6ZXaChpo8rM1iaqA3tpRQR79 1AnZX9TXedfFg== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail02.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MlIROcGvz_mo; Thu, 17 May 2018 11:28:10 -0400 (EDT) Received: from mail02.efficios.com (mail02.efficios.com [167.114.142.138]) by mail.efficios.com (Postfix) with ESMTP id 008E31C0134; Thu, 17 May 2018 11:28:09 -0400 (EDT) Date: Thu, 17 May 2018 11:28:09 -0400 (EDT) From: Mathieu Desnoyers To: Boqun Feng , Will Deacon Cc: Peter Zijlstra , "Paul E. McKenney" , Andy Lutomirski , Dave Watson , linux-kernel , linux-api , Paul Turner , Andrew Morton , Russell King , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andrew Hunter , Andi Kleen , Chris Lameter , Ben Maurer , rostedt , Josh Triplett , Linus Torvalds , Catalin Marinas , Michael Kerrisk , Joel Fernandes , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , linuxppc-dev Message-ID: <277374719.2144.1526570889798.JavaMail.zimbra@efficios.com> In-Reply-To: <20180517011949.GA1121@tardis> References: <20180430224433.17407-1-mathieu.desnoyers@efficios.com> <20180430224433.17407-8-mathieu.desnoyers@efficios.com> <20180516161837.GI12198@hirez.programming.kicks-ass.net> <112970629.1913.1526501596485.JavaMail.zimbra@efficios.com> <20180517011949.GA1121@tardis> Subject: Re: [PATCH 07/14] powerpc: Add support for restartable sequences MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.142.138] X-Mailer: Zimbra 8.8.8_GA_2026 (ZimbraWebClient - FF52 (Linux)/8.8.8_GA_2031) Thread-Topic: powerpc: Add support for restartable sequences Thread-Index: t85YqVTIgXObWq1917sxjLzY1A4eQw== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On May 16, 2018, at 9:19 PM, Boqun Feng boqun.feng@gmail.com wrote: > On Wed, May 16, 2018 at 04:13:16PM -0400, Mathieu Desnoyers wrote: >> ----- On May 16, 2018, at 12:18 PM, Peter Zijlstra peterz@infradead.org wrote: >> >> > On Mon, Apr 30, 2018 at 06:44:26PM -0400, Mathieu Desnoyers wrote: >> >> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig >> >> index c32a181a7cbb..ed21a777e8c6 100644 >> >> --- a/arch/powerpc/Kconfig >> >> +++ b/arch/powerpc/Kconfig >> >> @@ -223,6 +223,7 @@ config PPC >> >> select HAVE_SYSCALL_TRACEPOINTS >> >> select HAVE_VIRT_CPU_ACCOUNTING >> >> select HAVE_IRQ_TIME_ACCOUNTING >> >> + select HAVE_RSEQ >> >> select IRQ_DOMAIN >> >> select IRQ_FORCED_THREADING >> >> select MODULES_USE_ELF_RELA >> >> diff --git a/arch/powerpc/kernel/signal.c b/arch/powerpc/kernel/signal.c >> >> index 61db86ecd318..d3bb3aaaf5ac 100644 >> >> --- a/arch/powerpc/kernel/signal.c >> >> +++ b/arch/powerpc/kernel/signal.c >> >> @@ -133,6 +133,8 @@ static void do_signal(struct task_struct *tsk) >> >> /* Re-enable the breakpoints for the signal stack */ >> >> thread_change_pc(tsk, tsk->thread.regs); >> >> >> >> + rseq_signal_deliver(tsk->thread.regs); >> >> + >> >> if (is32) { >> >> if (ksig.ka.sa.sa_flags & SA_SIGINFO) >> >> ret = handle_rt_signal32(&ksig, oldset, tsk); >> >> @@ -164,6 +166,7 @@ void do_notify_resume(struct pt_regs *regs, unsigned long >> >> thread_info_flags) >> >> if (thread_info_flags & _TIF_NOTIFY_RESUME) { >> >> clear_thread_flag(TIF_NOTIFY_RESUME); >> >> tracehook_notify_resume(regs); >> >> + rseq_handle_notify_resume(regs); >> >> } >> >> >> >> user_enter(); >> > >> > Again no rseq_syscall(). >> >> Same question for PowerPC as for ARM: >> >> Considering that rseq_syscall is implemented as follows: >> >> +void rseq_syscall(struct pt_regs *regs) >> +{ >> + unsigned long ip = instruction_pointer(regs); >> + struct task_struct *t = current; >> + struct rseq_cs rseq_cs; >> + >> + if (!t->rseq) >> + return; >> + if (!access_ok(VERIFY_READ, t->rseq, sizeof(*t->rseq)) || >> + rseq_get_rseq_cs(t, &rseq_cs) || in_rseq_cs(ip, &rseq_cs)) >> + force_sig(SIGSEGV, t); >> +} >> >> and that x86 calls it from syscall_return_slowpath() (which AFAIU is >> now used in the fast-path since KPTI), I wonder where we should call > > So we actually detect this after the syscall takes effect, right? I > wonder whether this could be problematic, because "disallowing syscall" > in rseq areas may means the syscall won't take effect to some people, I > guess? > >> this on PowerPC ? I was under the impression that PowerPC return to >> userspace fast-path was not calling C code unless work flags were set, >> but I might be wrong. >> > > I think you're right. So we have to introduce callsite to rseq_syscall() > in syscall path, something like: > > diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S > index 51695608c68b..a25734a96640 100644 > --- a/arch/powerpc/kernel/entry_64.S > +++ b/arch/powerpc/kernel/entry_64.S > @@ -222,6 +222,9 @@ system_call_exit: > mtmsrd r11,1 > #endif /* CONFIG_PPC_BOOK3E */ > > + addi r3,r1,STACK_FRAME_OVERHEAD > + bl rseq_syscall > + > ld r9,TI_FLAGS(r12) > li r11,-MAX_ERRNO > andi. > r0,r9,(_TIF_SYSCALL_DOTRACE|_TIF_SINGLESTEP|_TIF_USER_WORK_MASK|_TIF_PERSYSCALL_MASK) > > But I think it's important for us to first decide where (before or after > the syscall) we do the detection. As Peter said, we don't really care whether it's on syscall entry or exit, as long as the process gets killed when the erroneous use is detected. I think doing it on syscall exit is a bit easier because we can clearly access the userspace TLS, which AFAIU may be less straightforward on syscall entry. We may want to add #ifdef CONFIG_DEBUG_RSEQ / #endif around the code you proposed above, so it's only compiled in if CONFIG_DEBUG_RSEQ=y. On the ARM leg of the email thread, Will Deacon suggests to test whether current->rseq is non-NULL before calling rseq_syscall(). I wonder if this added check is justified as the assembly level, considering that this is just a debugging option. We already do that check at the very beginning of rseq_syscall(). Thoughts ? Thanks, Mathieu > > Regards, > Boqun > >> Thoughts ? >> >> Thanks! >> >> Mathieu >> >> -- >> Mathieu Desnoyers >> EfficiOS Inc. > > http://www.efficios.com -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com