Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
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.
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
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.