Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965625AbdGTVQ3 (ORCPT ); Thu, 20 Jul 2017 17:16:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45146 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933285AbdGTVQ1 (ORCPT ); Thu, 20 Jul 2017 17:16:27 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5A98E80B29 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jpoimboe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5A98E80B29 Date: Thu, 20 Jul 2017 16:16:25 -0500 From: Josh Poimboeuf To: Jiri Slaby Cc: x86@kernel.org, linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Linus Torvalds , Andy Lutomirski , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra , Mike Galbraith Subject: Re: [PATCH v3.1 09/10] x86/unwind: add ORC unwinder Message-ID: <20170720211625.2uebcyyxfceenzw6@treble> References: <55eba34724a72b4b03d1e787ef17397931af68fe.1499786555.git.jpoimboe@redhat.com> <20170714172214.pnol6ve45qpa33si@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 20 Jul 2017 21:16:27 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1963 Lines: 59 On Thu, Jul 20, 2017 at 09:12:16AM +0200, Jiri Slaby wrote: > On 07/14/2017, 07:22 PM, Josh Poimboeuf wrote: > > +void __unwind_start(struct unwind_state *state, struct task_struct *task, > > + struct pt_regs *regs, unsigned long *first_frame) > > +{ > > + memset(state, 0, sizeof(*state)); > > + state->task = task; > > + > > + /* > > + * Refuse to unwind the stack of a task while it's executing on another > > + * CPU. This check is racy, but that's ok: the unwinder has other > > + * checks to prevent it from going off the rails. > > + */ > > + if (task_on_another_cpu(task)) > > + goto done; > > + > > + if (regs) { > > + if (user_mode(regs)) > > + goto done; > > + > > + state->ip = regs->ip; > > + state->sp = kernel_stack_pointer(regs); > > + state->bp = regs->bp; > > + state->regs = regs; > > + state->full_regs = true; > > + state->signal = true; > > + > > + } else if (task == current) { > > + asm volatile("lea (%%rip), %0\n\t" > > + "mov %%rsp, %1\n\t" > > + "mov %%rbp, %2\n\t" > > + : "=r" (state->ip), "=r" (state->sp), > > + "=r" (state->bp)); > > + > > + } else { > > + struct inactive_task_frame *frame = (void *)task->thread.sp; > > + > > + state->ip = frame->ret_addr; > > + state->sp = task->thread.sp; > > + state->bp = frame->bp; > > I wonder, if the reads from 'frame' should have READ_ONCE_NOCHECK for > the same reason as in: > commit 84936118bdf37bda513d4a361c38181a216427e0 > Author: Josh Poimboeuf > Date: Mon Jan 9 12:00:23 2017 -0600 > > x86/unwind: Disable KASAN checks for non-current tasks > ? Yeah, maybe so. Since the task_on_another_cpu() check above is racy, here it's remotely possible that the task has since starting executing and has poisoned the stack memory we're about to read. I don't know how realistic that scenario is, but it wouldn't hurt to add a couple of READ_ONCE_NOCHECKs here for the 'frame' dereferences. -- Josh