Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3873360imm; Thu, 17 May 2018 16:51:17 -0700 (PDT) X-Google-Smtp-Source: AB8JxZp0pk9GOXa3ZBWzkz2mjqfOwcDSvDOzmCMngAzGXC4/RneIXqQMbtdIyAMF+lj9qTpSW3d8 X-Received: by 2002:a63:ac43:: with SMTP id z3-v6mr5413116pgn.291.1526601077821; Thu, 17 May 2018 16:51:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526601077; cv=none; d=google.com; s=arc-20160816; b=ZXOboAx+gTejiy3Ck5adlaCKWxznJ41oXkH1UD/QA7/VtYPqeE3cqbim5pTRpggHTH 3CVxhIsGQB64pkZ+kwFqn78wOWMOC2sT9a+5SkMaLQS6+kF6bVDuxzeDiSS1tsPiuEzW Po9w2mWShJt0Y8IJvbMJ7jAFErSN8gTxuO5RSuPHud42UVja7amIa/rHiQRpXMGvrfSf S7hKDt6w0fouhB2sNXAaN1Mc7u6/rfIN+O+X2bF+ZH36e+NJxSwSXAMpOoljoUJ0lB6x oyV99W3igvG2GETctdeY965duy4eqYg2Vi7k85Aqa9CW/RSHeTtihFXBzx9TA6RQS/lU 12Jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:date:subject :content-transfer-encoding:mime-version:cc:to:from:message-id :dkim-signature:arc-authentication-results; bh=UklUbVZjvkRPi+71mvQUi9hOUWYFgmi+KdpHQA1P06Y=; b=zjRDW5OSZIxYPDaRLviCaxtRDDoR5GmgmvB+TVn0hc1RMxu9mioCTSBVbRfkVBWFAh KQLVXqYQBj+LEmI4kiE1kGMtvSNa2s3pDOdxdt0FKrtaMNTSDCXwP+/FOr/KpQ4+AemN gyVeqKUCbkDyEPOOA1RoO10I9IkWKY2Dgyz+GBzlV5asqTu4iwMjB2uhSezVPu8BzhuS Zjc3wDHDraHvth5YulI6F0kUtocs7VQ7YYawNemSSkpvKJ90Hjzv37SEOJhDtALnoJWt 8HvYkv07D+i4Gtgw6HQZrFfe46VPhvNaByhiGGb76RQektU+HuYBNdeG9n//V/XDtwr9 BHAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=T17rRO33; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u6-v6si2469086pgo.144.2018.05.17.16.51.00; Thu, 17 May 2018 16:51:17 -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=@gmail.com header.s=20161025 header.b=T17rRO33; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751880AbeEQXut (ORCPT + 99 others); Thu, 17 May 2018 19:50:49 -0400 Received: from mail-qt0-f195.google.com ([209.85.216.195]:42316 "EHLO mail-qt0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751564AbeEQXuq (ORCPT ); Thu, 17 May 2018 19:50:46 -0400 Received: by mail-qt0-f195.google.com with SMTP id c2-v6so8140654qtn.9; Thu, 17 May 2018 16:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:from:to:cc:mime-version:content-transfer-encoding :subject:date:in-reply-to:references; bh=UklUbVZjvkRPi+71mvQUi9hOUWYFgmi+KdpHQA1P06Y=; b=T17rRO33QvPxyhstB+uKi+zmKDMG3KSqMjsQa6Oqc9fcSKUG6/RSl0wd/QEEYHtGBB p/DlR+2muQEzK/6nPdtxLcJe8ZpzR6Ln9JkBaECisobBbX8dRYjLNXY7h06IWqzA/cX/ eVs8kvbT9eq5P7GFxKfzZFi+v66jaBaPtD9P3/BM1dApurBvoznqNi/5JxRpjsoG8zt2 RFCao9Oskk/EtXNa0gUDfw5f5SrR3QW89toemwpmjFQrIMPPUwmqlzxA/BLwjtmXxFtu yv4bCCJ1GzYlRs2vpqNO7ns5NzkEulII+JjQyDzEC2jbKJlwKvZfwnaBKQFrUdyW4VKB 87Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:cc:mime-version :content-transfer-encoding:subject:date:in-reply-to:references; bh=UklUbVZjvkRPi+71mvQUi9hOUWYFgmi+KdpHQA1P06Y=; b=SDcWJ/WUvO8SiC5VxLfAtoayDE8E/O4WG5wJ2m12YX+XaihsXhK2GW51mRItJXc26L beLLz6paHRXVxFFn6UcQDAhxBog162Qs7lU0+KLRU5ik9G+Akh/bsKx+tPnuBfU5PvMK fwMlbSjJj+suvWJ4nu23EaL7MLu3UIB6A01TD/TcbDRPJHLJezAOHtH6g5qZogoMX80C xpszaOfswPvA+/i5uXzg4SY+Bv5aHZuhhTiey6uNNByVdnxks/QdcgQop66EmtB2KPNe R4H7IYL6jUNR+L9yTJm5gCJAaSZVaKQmy3e/Ie6vCYeSTzbK/cX5fbNF+EBqgeM3qdte TTxw== X-Gm-Message-State: ALKqPwfU89qLTEF1mG0uyJ++FkWCnd+oItGu4Q7uCuyYEzHjAjtxiAW/ YPhScNQnQIT4LBvyP7XHd+0= X-Received: by 2002:a0c:bd97:: with SMTP id n23-v6mr3278635qvg.146.1526601045869; Thu, 17 May 2018 16:50:45 -0700 (PDT) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com. [66.111.4.228]) by smtp.gmail.com with ESMTPSA id y5-v6sm1733887qkd.33.2018.05.17.16.50.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 May 2018 16:50:44 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id AA5CC223DA; Thu, 17 May 2018 19:50:43 -0400 (EDT) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Thu, 17 May 2018 19:50:43 -0400 X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 7C88A94089; Thu, 17 May 2018 19:50:43 -0400 (EDT) Message-Id: <1526601043.1338308.1376191416.0444B8C5@webmail.messagingengine.com> From: Boqun Feng To: Mathieu Desnoyers , 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" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29fe4c42 Subject: Re: [PATCH 07/14] powerpc: Add support for restartable sequences Date: Fri, 18 May 2018 07:50:43 +0800 In-Reply-To: <277374719.2144.1526570889798.JavaMail.zimbra@efficios.com> 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> <277374719.2144.1526570889798.JavaMail.zimbra@efficios.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 17, 2018, at 11:28 PM, Mathieu Desnoyers wrote: > ----- 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. > Fair enough. > 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. > OK. > 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(). > Yes, I think it's better to do the check in rseq_syscall(), leaving the asm code a bit cleaner. Regards, Boqun > Thoughts ? > > Thanks, > > Mathieu > > > > > Regards, > > Boqun > > > >> Thoughts ? > >> > >> Thanks! > >> > >> Mathieu > >> > >> -- > >> Mathieu Desnoyers > >> EfficiOS Inc. > > > http://www.efficios.com > > -- > Mathieu Desnoyers > EfficiOS Inc. > http://www.efficios.com