From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964874AbcIPPNM (ORCPT ); Fri, 16 Sep 2016 11:13:12 -0400 Received: from mail-vk0-f43.google.com ([209.85.213.43]:33724 "EHLO mail-vk0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935125AbcIPPND (ORCPT ); Fri, 16 Sep 2016 11:13:03 -0400 MIME-Version: 1.0 In-Reply-To: <20160916074730.GJ5012@twins.programming.kicks-ass.net> References: <7cd5e328dc75d8ccd912e5783665de34503f7c63.1473801993.git.luto@kernel.org> <20160914145556.5whqcpzys7c23nib@treble> <20160914183501.cknjhsbkzxg6m6pl@treble> <20160915183741.wka5dzdsvbn53drp@treble> <20160915191938.mm2k7ccv6d2o622t@treble> <20160916074730.GJ5012@twins.programming.kicks-ass.net> From: Andy Lutomirski Date: Fri, 16 Sep 2016 08:12:40 -0700 Message-ID: Subject: Re: [PATCH 08/12] x86/dumpstack: Pin the target stack in save_stack_trace_tsk() To: Peter Zijlstra Cc: Josh Poimboeuf , Andy Lutomirski , X86 ML , Borislav Petkov , "linux-kernel@vger.kernel.org" , Brian Gerst , Jann Horn , Ingo Molnar , live-patching@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 16, 2016 at 12:47 AM, Peter Zijlstra wrote: > On Thu, Sep 15, 2016 at 02:19:38PM -0500, Josh Poimboeuf wrote: >> On Thu, Sep 15, 2016 at 11:41:25AM -0700, Andy Lutomirski wrote: >> > I also wouldn't mind trying to do something to prevent ever dumping >> > the stack of an actively running task. It's definitely safe to dump: >> > >> > - current >> > >> > - any task that's stopped via ptrace, etc >> > >> > - any task on the current CPU if running atomically enough that the >> > task can't migrate (which probably covers the nasty NMI cases, I hope) >> > >> > What's *not* safe AFAIK is /proc/PID/stack. I don't know if we can >> > somehow fix that short of actually sending an interrupt or NMI to >> > freeze the task if it's running. I'm also not sure it's worth >> > worrying about it. >> >> Yeah, I proposed a fix for /proc/PID/stack a while back: >> >> https://lkml.kernel.org/r/cover.1424109806.git.jpoimboe@redhat.com >> >> My idea was to use task_rq_lock() to lock the runqueue and then check >> tsk->on_cpu. I think Peter wasn't too keen on it. > > That basically allows a DoS on the scheduler, since a user can run tasks > on every cpu (through sys_sched_setaffinity()). Then doing while (1) cat > /proc/$PID/stack would saturate the rq->lock on every CPU. > > The more tasks the merrier. > > Is this worse than it would be if this code used preempt_disable() (which I think it did until very recently)? -- Andy Lutomirski AMA Capital Management, LLC