Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1391791imm; Wed, 17 Oct 2018 19:45:12 -0700 (PDT) X-Google-Smtp-Source: ACcGV631x0TLtLsBNH3UUJYppVXGVFc5YW1GD/UR8qAk8DMI/uWCymcPCHYD3FDzdrtmRFzoRt00 X-Received: by 2002:a17:902:b403:: with SMTP id x3-v6mr28676792plr.237.1539830712234; Wed, 17 Oct 2018 19:45:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539830712; cv=none; d=google.com; s=arc-20160816; b=jkqhkOfrEfxWmSbWABaXc6iTKEjIYqUf8VHNnGig4VKy6OVGl73Qi/JehsA3wTAhil iRToMG4I0d/D9Pf9P3xwX+xboa2/S8s1H+01YfaVMn2jvbda99bGRBumj+SQoDr1wPzW vyYsY3LkhpKdeZ0Wb/H4fR6L0RJeR+O6j+Q093unjxGKgfVGO+yV/5q8I7MbbNifEWdK NIlCyhalMj3GXKf8pOzperwSEsFBYqwnC9FeF1WOLkFDFYhJMNo1mCm0WAkeJ2akTwgQ O6hNvjwmeNiDAPv+v+a9NvSXn0FRn5fpbfgSmKb84Sa3o9YZ2l9kot8l3yJfcHKg/whd Yk/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=Xo6N17SKFXnMWNqmZAQBWgx5lh8YH7+Se7h/9715ZzM=; b=jp8GjU5CwgRUCWaPt+mNX42/Va+Z50S6jAeSpuutHC+8oa37s4AMetNjGJMLl0jeok kr+wHl6l726RA13OW+YhFGe0qjWaFbpnzn2u9XxY4Sr5+GNhtAGr1wcI2mfP8cbqi/tu 7lM61Fru7BnnKXfCrUigahJH5lTYxHT9RGmbJokNJ+nrh/hSRZvwXiSigSVYXymojrtc jxkjViMvgBt84WwVtgudR/0gknjSpFeubZv4zazo0THKmJDmqQh6K5Izz4f0bYGiOz38 P/5wyv5yQ/w/x9aXPUpToqsiaCGTzg2qMdOQcwQ1NbA5nwY2kKKoulh8OzDudkHVzYUP PsaQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r16-v6si18415423pgv.548.2018.10.17.19.44.56; Wed, 17 Oct 2018 19:45:12 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727366AbeJRKd3 (ORCPT + 99 others); Thu, 18 Oct 2018 06:33:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:33742 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727247AbeJRKd3 (ORCPT ); Thu, 18 Oct 2018 06:33:29 -0400 Received: from vmware.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E70C521470; Thu, 18 Oct 2018 02:34:48 +0000 (UTC) Date: Wed, 17 Oct 2018 22:34:47 -0400 From: Steven Rostedt To: Masami Hiramatsu Cc: Andy Lutomirski , LKML , Thomas Gleixner , Peter Zijlstra , Ingo Molnar , "H. Peter Anvin" , Josh Poimboeuf Subject: Re: [RFC][PATCH] x86: ptrace: Add function argument access API Message-ID: <20181017223447.0cdcd422@vmware.local.home> In-Reply-To: <20181015235646.2cbb7dc9bc4b7b54f900e0fb@kernel.org> References: <20181011230021.0a7604fa@vmware.local.home> <20181012122641.3d87ed29@gandalf.local.home> <20181012155439.59f77556@gandalf.local.home> <20181015235646.2cbb7dc9bc4b7b54f900e0fb@kernel.org> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 15 Oct 2018 23:56:46 +0900 Masami Hiramatsu wrote: > On Fri, 12 Oct 2018 15:54:39 -0400 > Steven Rostedt wrote: > > > On Fri, 12 Oct 2018 11:21:28 -0700 > > Andy Lutomirski wrote: > > > > > On Fri, Oct 12, 2018 at 9:26 AM Steven Rostedt wrote: > > > > > > > > > > > > Anyone have any issues with this patch? > > > > > > > > > > I'm conceptually okay with it. That being said, > > > regs_within_kernel_stack(), which you're indirectly using, is > > > off-by-a-few. And updating it to use probe_kernel_read() might be > > > nice for robustness. > > > > > > > Something like this? > > > > -- Steve > > > > From: "Steven Rostedt (VMware)" > > Date: Fri, 12 Oct 2018 15:44:20 -0400 > > Subject: [PATCH] x86: ptrace.h: Add regs_get_kernel_stack_nth_safe() function > > > > Andy had some concerns about using regs_get_kernel_stack_nth() in a new > > function regs_get_kernel_argument() as if there's any error in the stack > > code, it could cause a bad memory access. Instead, add a new function called > > regs_get_kernel_stack_nth_safe() that does a probe_kernel_read() on the > > stack address to be extra careful in accessing the memory. To share the > > code, regs_get_kernel_stack_nth_addr() was added to just return the stack > > address (or NULL if not on the stack), that both regs_get_kernel_stack_nth() > > and the _safe() version can use. > > This patch looks good to me. > But if the concern is real, all regs_get_kernel_stack_nth() user must move > onto _safe() version, at least all tracers code. > > Reviewed-by: Masami Hiramatsu > Hi Masami, Can you review my v2 version which implements what you suggest. Thanks, -- Steve