Bug 1732173 - aarch64 syscall arguments are incorrect
Summary: aarch64 syscall arguments are incorrect
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: systemtap
Version: 8.1
Hardware: aarch64
OS: Linux
unspecified
medium
Target Milestone: rc
: 8.0
Assignee: Frank Ch. Eigler
QA Contact: Martin Cermak
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-22 21:18 UTC by William Cohen
Modified: 2019-11-05 20:55 UTC (History)
5 users (show)

Fixed In Version: systemtap-4.1-4.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
: 1733535 1741831 (view as bug list)
Environment:
Last Closed: 2019-11-05 20:55:09 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)
Patch for arm64 to use CONTEXT->sregs when available (612 bytes, patch)
2019-07-22 21:18 UTC, William Cohen
no flags Details | Diff
Fix aarch64 to properly access arguments for wrapped syscalls (1.46 KB, application/mbox)
2019-07-23 18:37 UTC, William Cohen
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2019:3366 None None None 2019-11-05 20:55:17 UTC

Description William Cohen 2019-07-22 21:18:51 UTC
Created attachment 1592704 [details]
Patch for arm64 to use CONTEXT->sregs when available

Description of problem:

Systemtap does not obtain the correct arguments for systemcalls


Version-Release number of selected component (if applicable):

kernel-4.18.0-107.el8.aarch64
systemtap-4.1-3.el8.aarch64

How reproducible:

every time


Steps to Reproduce:
1. sudo dnf install systemtap*
2. sudo stap -e 'probe syscall.close { printf("%x\n", fd) ; print_regs(); exit()}' 


Actual results:

ffff0000163afec0
pc : [<ffff2f7809fed910>] lr : [<ffff2f7809d74a10>] pstate: 80000005
sp : ffff0000163afe90
x29: ffff0000163afe90 x28: ffff99698660dd00 
x27: 0000ffffd8574c68 x26: 0000ffffd85754a0 
x25: 0000000056000000 x24: 0000000000000015 
x23: 0000000020000000 x22: 0000000000000000 
x21: 0000000000000039 x20: 0000000000000039 
x19: ffff0000163afec0 x18: 000000000000034f 
x17: 0000ffff97542c60 x16: 0000ffff97b8e930 
x15: 00007c6051c87fa2 x14: 0000000000000026 
x13: 0065636976726573 x12: 2e646c616e72756f 
x11: 6a2d646d65747379 x10: 732f6563696c732e 
x9 : 732e646c616e7275 x8 : 0000000000000039 
x7 : 7f7f7f7f7f7f7f7f x6 : 0000000000000000 
x5 : 0000000000000000 x4 : 0000ffff96790630 
x3 : 0000ffff96790e30 x2 : ffff99698660dd00 
x1 : ffff2f7809fed910 x0 : ffff0000163afec0 



Expected results:

The number printed out before the register dump should be a small hex number, not the same value as x0.  x0 is a pointer to a pt_regs struct.


Additional info:

What is occurring is the tapsets set CONTEXT->sregs for the various kernel.kprobe("*") syscall functions.  However, only the x86_64 register.stp is using that value.  The tapset/arm64/register.stp is not using the value in CONTEXT->sregs, so the registers from kprobe trigger are being used rather than the pt_regs argument passed into the syscalls.

Note that other non-x86 processors that use syscall wrappers look like they will suffer from the same problem.

Comment 1 Frank Ch. Eigler 2019-07-22 21:25:18 UTC
Without this fix, basic syscall tracing on arm64 is impossible.  The fix should be small & safe, and ready very shortly.

Comment 6 William Cohen 2019-07-23 18:37:17 UTC
Created attachment 1592950 [details]
Fix aarch64 to properly access arguments for wrapped syscalls

This is the patch that has been checked into upstream systemtap to address this problem.

Comment 9 Martin Cermak 2019-08-27 12:31:58 UTC
Verified with systemtap-4.1-6.el8.

Comment 11 errata-xmlrpc 2019-11-05 20:55:09 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:3366


Note You need to log in before you can comment on or make changes to this bug.