From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <systemtap-return-26004-listarch-systemtap=sources.redhat.com@sourceware.org>
Received: (qmail 127830 invoked by alias); 11 May 2018 21:27:30 -0000
Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <systemtap.sourceware.org>
List-Subscribe: <mailto:systemtap-subscribe@sourceware.org>
List-Post: <mailto:systemtap@sourceware.org>
List-Help: <mailto:systemtap-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: systemtap-owner@sourceware.org
Received: (qmail 127742 invoked by uid 48); 11 May 2018 21:27:25 -0000
From: "fche at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sourceware.org
Subject: [Bug tapsets/23160] 4.17 breaks syscalls tapset
Date: Fri, 11 May 2018 21:27:00 -0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: systemtap
X-Bugzilla-Component: tapsets
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fche at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: systemtap at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-23160-6586-bqzoiTpcNt@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-23160-6586@http.sourceware.org/bugzilla/>
References: <bug-23160-6586@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2018-q2/txt/msg00063.txt.bz2

https://sourceware.org/bugzilla/show_bug.cgi?id=3D23160

--- Comment #1 from Frank Ch. Eigler <fche at redhat dot com> ---
As a curiosity, I have a little prototype hacky solution to this problem.

It involves:
- hooking into the __$ARCH_sys_$SYSCALL function (__x64_sys_read etc.)
- grabbing its $regs (pt_regs*) parameter
- reusing the nd_$SYSCALL probe alias parameter handling (int_arg(2) etc.)

... but how?  Add this to some common .stp file:

function set_user_mode(r) %{
    c->uregs =3D (void*)STAP_ARG_r;
    c->user_mode_p =3D 1;
    %}

... and a variant of this to every sysc_*.stp file:

probe __nd_syscall.read =3D kernel.function("__x64_sys_read")
{
  set_user_mode($regs)
}

Then the preexisting nd_syscall.read alias works unmodified:

probe nd_syscall.read =3D
        __nd_syscall.read
{
        @_SYSCALL_READ_NAME
        asmlinkage()
        fd =3D int_arg(1)
        buf_uaddr =3D pointer_arg(2)
[...]
}

i.e., the set_user_mode function tricks probes built upon this alias
into thinking that the pt_regs* given to the new syscall wrapper is the
new proper register set for later registers.stp function calls to read
from.

(Season to taste; adjust kernel.function -> kprobe.function() and int_arg(2)
to fetch $regs probably.)

One big downside: no access to individual parameters as context variables.
I guess we missed that with nd_syscall probes already.  But that means that
it's not possible to modify the parameters in the stap probe before they
get relayed to the real __do_sys_FUNCTION.

--=20
You are receiving this mail because:
You are the assignee for the bug.