Received: by 2002:ac0:b08d:0:0:0:0:0 with SMTP id l13csp4499667imc; Mon, 25 Feb 2019 06:06:01 -0800 (PST) X-Google-Smtp-Source: AHgI3IZoZmpvWODuPNgW45BLt/9JRf8ou+VhOGDuQlTSuZSYMCBFXvXC8IoEpYZ5o5ZkDIT4rXxj X-Received: by 2002:a65:4381:: with SMTP id m1mr18840686pgp.358.1551103560995; Mon, 25 Feb 2019 06:06:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551103560; cv=none; d=google.com; s=arc-20160816; b=ij6XL6Z0BtipN3wuWKfoTiO9WxMlzZFIy45n6QEHFiXw+KZQs1IDwpjGRwa1DttTQ9 j5wdq02O/vjF7iOtOO8QNF60MzsuC3cWFZe948CV72QYlRgJQ+5QJKdox9aLBu5FO9Sm yY6BNiVI7n2mPeUOHtViqnHjHNEVMk/V88PYjbf8CPZitx/R8DudPZ3bz2jxTu4TrgZm FNqBl6wd8GVs2BUPH37+H6PfhU8Anm2q+NZIKm4sogn451g895KQ92u5cDtxSesjvSjQ slwtMGERGh3c+rtcAueDUkz2+QPNYpTLAMQpXgbScwJJkmoqq/4ujTmhk/JufTbyoq81 PN7Q== 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 :user-agent:message-id:date:subject:cc:to:from:dkim-signature; bh=PfeVSFCi7Fm7x1kjghXZ3PrldDFE+WLDGccNNqUciGI=; b=K8CEOGP6Yxlb9Tuuq2jBBGBJapy3zIgmRDtygpnzO90e8dsilbXpWivgD3Ra8YinmE PAdHx+zXPhX0ykgovrB74fESiYUKqumeO6bSxfNQF3XxJL4romzT07Vn7k2QuBcx/kCG PFIXUp/f0lf/Wff8FqNN2yq7rLQUOxYEZDqWOeZzk3ZH1f8pLZq9p28RsCb+s6Dy4H68 MQ3P6jHVYRqP8naHau+75JAZW7vwuIhLAIip1rd2qOQzsMWTTAT+s+pLGnjXgztuA1VF yqDreMJDIYmF4MDC4TJANf+gtLBXWREMR6O0fSGsu8sZBidh+QoVLd1NBbr39xKTAy3w RwZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=KO3rvTjN; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 98si9900251pls.205.2019.02.25.06.05.44; Mon, 25 Feb 2019 06:06:00 -0800 (PST) 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=@kernel.org header.s=default header.b=KO3rvTjN; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727334AbfBYOFH (ORCPT + 99 others); Mon, 25 Feb 2019 09:05:07 -0500 Received: from mail.kernel.org ([198.145.29.99]:51160 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726099AbfBYOFH (ORCPT ); Mon, 25 Feb 2019 09:05:07 -0500 Received: from localhost.localdomain (NE2965lan1.rev.em-net.ne.jp [210.141.244.193]) (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 8115920663; Mon, 25 Feb 2019 14:05:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1551103506; bh=sUWe+HImqXKFVGfeYJ1vpyFKjg4r11QQr4LMc0u4oyg=; h=From:To:Cc:Subject:Date:From; b=KO3rvTjNQOFjaggw3AM7am7l0ckBWFezdkjQJoG2fqh1JiDYlafe/tVbsBCRU90ae krSEbd6jnxlp6VPyRsh/nfBTc3yyqENMvvykTfom2qCGNVA5q0+1MLvw8LxonLDvQq Xrn+fs7xcZJMHW21ONxL4D9cXbJPMw7iMrvlf/1s= From: Masami Hiramatsu To: Steven Rostedt , Linus Torvalds Cc: mhiramat@kernel.org, linux-kernel@vger.kernel.org, Andy Lutomirski , Ingo Molnar , Andrew Morton , Changbin Du , Jann Horn , Kees Cook , Andy Lutomirski , Alexei Starovoitov , Nadav Amit , Peter Zijlstra Subject: [RFC PATCH 0/4] tracing/probes: uaccess: Add support user-space access Date: Mon, 25 Feb 2019 23:04:42 +0900 Message-Id: <155110348217.21156.3874419272673328527.stgit@devbox> X-Mailer: git-send-email 2.13.6 User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Here is an RFC series of probe-event to support user-space access methods, which we discussed in previous thread. https://lkml.kernel.org/r/20190220171019.5e81a4946b56982f324f7c45@kernel.org So in this thread, it is clear that current probe_kernel_read() and strncpy_from_unsafe() are not enough to access user-space variables from kprobe events on some arch. On such arch, user address space and kernel address space can overlap so we have to change the memory segment to user-mode before copying. But probe_kernel_read() is designed to access primarily kernel memory, it may fail to get, or get unexpected value on such arch. So we need to expand kprobe fetcharg to support new options for such case. For user-space access extension, this series adds 2 features, "ustring" type and user-space dereference syntax. "ustring" is used for recording a null-terminated string in user-space from kprobe events. "ustring" type is easy, it is able to use instead of "string" type, so if you want to record a user-space string via "__user char *", you can use ustring type instead of string. For example, echo 'p do_sys_open path=+0($arg2):ustring' >> kprobe_events will record the path string from user-space. The user-space dereference syntax is also simple. Thi just adds 'u' prefix before an offset value. +|-u() e.g. +u8(%ax), +u0(+0(%si)) This is more generic. If you want to refer the variable in user- space from its address or access a field in data structure in user-space, you need to use this. For example, if you probe do_sched_setscheduler(pid, policy, param) and record param->sched_priority, you can add new probe as below; p do_sched_setscheduler priority=+u0($arg3) Actually, with this feature, "ustring" type is not absolutely necessary, because these are same meanings. +0($arg2):ustring == +u0($arg2):string Perhups, we may be better removing "ustring" and just introducing this user-space dereference syntax... Note that kprobe event provides these methods, but it doesn't change it from kernel to user automatically because we do not know whether the given address is in userspace or kernel on some arch. Moreover, from perf-probe, at this moment it is not able to switch. Since __user is not for compiler but checker, we have no clue which data structure is in user-space, in debuginfo. BTW, according to Linus's comment, I implemented probe_user_read() and strncpy_from_unsafe_user() APIs. And since those use "access_ok()" inside it, if CONFIG_DEBUG_ATOMIC_SLEEP=y on x86, it will get a warn message at once. It should be solved before merging this series. Thank you, --- Masami Hiramatsu (4): uaccess: Make sure kernel_uaccess_faults_ok is updated before pagefault uaccess: Add non-pagefault user-space read functions tracing/probe: Add ustring type for user-space string tracing/probe: Support user-space dereference Documentation/trace/kprobetrace.rst | 13 ++- Documentation/trace/uprobetracer.rst | 9 +- fs/namespace.c | 2 include/linux/uaccess.h | 13 +++ kernel/trace/trace.c | 7 +- kernel/trace/trace_kprobe.c | 65 ++++++++++++++++ kernel/trace/trace_probe.c | 39 ++++++++-- kernel/trace/trace_probe.h | 3 + kernel/trace/trace_probe_tmpl.h | 36 +++++++-- kernel/trace/trace_uprobe.c | 19 +++++ mm/maccess.c | 138 ++++++++++++++++++++++++++++++---- 11 files changed, 302 insertions(+), 42 deletions(-) -- Masami Hiramatsu (Linaro)