Page MenuHomeFreeBSD

linuxulator: Some ptrace fixes..
Needs ReviewPublic

Authored by pitwuu_gmail.com on May 25 2021, 5:36 PM.

Details

Reviewers
None
Group Reviewers
Linux Emulation
Summary

This is not a patch ready for inclusion yet, but rather to get the ball rolling on some changes to ptrace.
Once the patch is cleaned up I'd like to see it pulled in.

Discussion: strace doesn't always run right now because it hangs up on lack of SEIZE support. SEIZE is like ATTACH, but it doesn't leave the process stopped after attaching. Rather a follow up INTERRUPT is issued to actually stop the process and wait for events.
Unlike ATTACH, in SEIZE we immediately get ptrace options and can set them right away.

With this patch, strace reliably runs on my end whereas the previous effect was a 'nothing happening' strace.

Test Plan

You can run strace and test that way.

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

Ah yes I forgot. There's a second point of failure in our current ptrace. Currently all signals emit an event for ptrace to consume, which is not the behaviour on Linux, where all signals emit a signal except SIGKILL which behaves normally.
From the man page:

While being traced, the tracee will stop each time a signal is

delivered, even if the signal is being ignored.  (An exception is
SIGKILL, which has its usual effect.)  The tracer will be
notified at its next call to waitpid(2) (or one of the related
"wait" system calls);

So the effect is that strace checks this and hangs up. My patch attempts to correct this situation. But AFAIK it shouldn't be done in the "normal" freebsd mode.

This looks really interesting, thanks for working on it!

Which version of strace(1) are you testing with? I kind of hoped this would fix the one from Ubuntu Focal (the one from Bionic already worked fine), but this doesn't seem to be the case.

This looks really interesting, thanks for working on it!

Which version of strace(1) are you testing with? I kind of hoped this would fix the one from Ubuntu Focal (the one from Bionic already worked fine), but this doesn't seem to be the case.

As of today strace 4.25 is at least in working status.
I have git master almost working. I added GET_SYSCALL_INFO support in my local branch. One tiny issue I can't resolve is that the thread dies when receiving some initial signal. I can't figure it out :( The signals stuff is very hacky in Unix and this is at the edge of my ability I think. If I comment out this line in src/syscall.c then the process starts and traces.

652   │                 /*
653   │                  * First exec* syscall makes the log visible.
654   │                  */
655   │                 tcp->flags &= ~TCB_HIDE_LOG;
656   │                 /*
657   │                  * Check whether this exec* syscall succeeds.
658   │                  */
659   │         /// XXX this one        tcp->flags |= TCB_CHECK_EXEC_SYSCALL;
660   │                 break;
661   │         }
662   │     }

Trace git master will also work if you recompile it manually after modifying NOMMU_SYSTEM in the src/defs.h. This will use the old non-SEIZED-based method of tracing and then all is well. Do you want to try my changes?

Nice! Regarding GET_SYSCALL_INFO - this reminded me that I also had a patch for this, https://reviews.freebsd.org/D28212; I guess we should try merging our changes.

There's some activity right now regarding Linuxulator signal delivery, https://reviews.freebsd.org/D30675; I wonder if it's related?

Nice! Regarding GET_SYSCALL_INFO - this reminded me that I also had a patch for this, https://reviews.freebsd.org/D28212; I guess we should try merging our changes.

There's some activity right now regarding Linuxulator signal delivery, https://reviews.freebsd.org/D30675; I wonder if it's related?

Great! Your GET_SYSCALL_INFO work looks really similar to mine, I think that would work if you have no objection.
Regarding the Linuxulator signal delivery, I think this is work in the right direction, but instead of messing with wait() it's clear that SIGKILL should behave as normal regardless of a wait or not, so it looks to be tangential to this.?

What does tinderboxed mean?

Sorry for delay. I've just finished dusting off https://reviews.freebsd.org/D28212; hopefully it will hit the tree soon.

As for signals - I'm not sure, to be honest; I've only touched that code briefly.

As for tinderbox: "make tinderbox" builds both kernel and world, for all supported architectures. It's good habit to make sure it passes before pushing changes.