Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[drmemtrace] AMD-32 vdso memtrace contains PC discontinuity at OP_syscall #7340

Open
abhinav92003 opened this issue Mar 10, 2025 · 5 comments · May be fixed by #7343
Open

[drmemtrace] AMD-32 vdso memtrace contains PC discontinuity at OP_syscall #7340

abhinav92003 opened this issue Mar 10, 2025 · 5 comments · May be fixed by #7343
Labels
Bug-ToolFail Component-DrMemtrace Component-Tests OpSys-Linux OpSys-x86-32 x86 32-bit only OpSys-x86

Comments

@abhinav92003
Copy link
Contributor

abhinav92003 commented Mar 10, 2025 •
edited
Loading

As also noted in #4407, 32-bit apps on AMD have a different implementation of the __kernel_vsyscall in vdso.

Note that it uses syscall instead of sysenter. PR #5037 found that this syscall actually acts like the sysenter, notably that it does not return to the subsequent pc, and hooked it like we do for sysenter.

Breakpoint 2, 0xf7fc4570 in __kernel_vsyscall ()
(gdb) x/20i 0xf7fc4570
=> 0xf7fc4570 <__kernel_vsyscall>:      push   %ecx
   0xf7fc4571 <__kernel_vsyscall+1>:    push   %edx
   0xf7fc4572 <__kernel_vsyscall+2>:    push   %ebp
   0xf7fc4573 <__kernel_vsyscall+3>:    mov    %ecx,%ebp
   0xf7fc4575 <__kernel_vsyscall+5>:    syscall 
   0xf7fc4577 <__kernel_vsyscall+7>:    int    $0x80
   0xf7fc4579 <__kernel_vsyscall+9>:    pop    %ebp
   0xf7fc457a <__kernel_vsyscall+10>:   pop    %edx
   0xf7fc457b <__kernel_vsyscall+11>:   pop    %ecx
   0xf7fc457c <__kernel_vsyscall+12>:   ret    
   0xf7fc457d <__kernel_vsyscall+13>:   int3   
   0xf7fc457e:  nop
   0xf7fc457f:  nop

The drmemtrace invariant_checker indeed relaxes the PC discontinuity check for TRACE_TYPE_INSTR_SYSENTER.

dynamorio/clients/drcachesim/tools/invariant_checker.cpp

Line 1468 in a04a39d

TRACE_TYPE_INSTR_SYSENTER IF_X86(

Looks like we need to do the same for the vdso syscall on AMD-32 where the tool.drcacheoff.windows-invar test currently fails. May need us to look into the modules list to figure out that the regular-looking syscall is this special one from __kernel_vsyscall.

#6417 notes various x86-32 tests that fail on AMD. Interestingly we did not see any issues with tool.drcacheoff.windows-invar until we tried migrating our GA CI to Ubuntu22 in #7270.

dynamorio/suite/tests/CMakeLists.txt

Line 6664 in a04a39d

if (UNIX AND X86 AND CPU_AMD AND NOT DR_HOST_X64)

abhinav92003 added a commit that referenced this issue Mar 10, 2025
@abhinav92003
i#7270 Ubuntu22: Ignore drcacheoff.windows-invar failure
ace3d82 
Adds the tool.drcacheoff.windows-invar test to the failure-ignore list for x86-32. This test was observed to consistently fail on x86-32 AMD machines in Github Actions CI runners. Interestingly, this manifested only when we tried running it on Ubuntu22, even though the AMD-specific failures were already known (#6417).

We do have a denylist for tests failing on AMD-32 in i#6417, which causes tests to not run at all. IMO, it is better to run the test but ignore the failure, than to not run the test at all, unless there are timeout issues (which is why we created the denylist), and this test does not have timeout issues.

We plan to work on the AMD-32 failures at a later date and are focusing on completing the Ubuntu22 migration currently.

Issue: #6417, #7270, #7340
@abhinav92003 abhinav92003 mentioned this issue Mar 10, 2025
Open
@abhinav92003 abhinav92003 added the OpSys-x86-32 x86 32-bit only label Mar 10, 2025
@derekbruening
Copy link
Contributor

So #5037 (comment) noted the hook is needed, but then it was never added nor an issue left open for it?

@abhinav92003
Copy link
Contributor Author

So #5037 (comment) noted the hook is needed, but then it was never added nor an issue left open for it?

#5037 already added that hook: https://github.com/DynamoRIO/dynamorio/blame/695affca7ab8c515e623198496d69f851d02834c/core/arch/arch.c#L3301

(Clarified in the issue description)

@derekbruening
Copy link
Contributor

So this issue is only about drmemtrace's invariant checker? The title does not imply that: I found it confusing as it seems to be about a problem in core DR.

@derekbruening
Copy link
Contributor

The labels don't point at Component-DrMemtrace either.

@abhinav92003
Copy link
Contributor Author

This doesn't apply to core DR surely, since syscall hooking for AMD-32 is already done; will add the Component-DrMemtrace tag.

Perhaps we shouldn't limit this issue to just the drmemtrace invariant checker, as we may want to ensure there's some way to let simulators/analyzers know that the vdso syscall is different.

@abhinav92003 abhinav92003 changed the title AMD-32 uses syscall instead of sysenter [drmemtrace] AMD-32 vdso trace includes syscall instead of sysenter Mar 10, 2025
@derekbruening derekbruening changed the title [drmemtrace] AMD-32 vdso trace includes syscall instead of sysenter [drmemtrace] AMD-32 vdso memtrace contains PC discontinuity at OP_syscall Mar 10, 2025
@abhinav92003 abhinav92003 linked a pull request Mar 11, 2025 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug-ToolFail Component-DrMemtrace Component-Tests OpSys-Linux OpSys-x86-32 x86 32-bit only OpSys-x86
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

i#7340 Ubuntu22: Relax PC discontinuity check on AMD-32 OP_syscall DynamoRIO/dynamorio
2 participants
@abhinav92003 @derekbruening