Incomplete type of user struct during compilation?

[danergo]

During compilation on aarch64 target, I got an incomplete type for user struct:

ptrace.h:62:17: error: field ‘user’ has incomplete type
   62 |     struct user user;

Are you aware of any resolution for this?

[jerome-pouiller]

Not directly related to your issue, but reredirect is not compatible with aarch64.

[jerome-pouiller]

From ptrace() man page: _PTRACE_GETREGS and PTRACESETREGS are not present on all architectures. I guess it is not available on aarch64 and it's why struct user does not exist. I do not see easy way to make it works.

[jerome-pouiller]

See also #3

[danergo]

But for some strange reason I could comple reptyr for aarch64.

It also includes user.h and seems working fine, but reredirect fits better to my purposes.

Can we check it somehow? It seems reptyr have been refactored since you forked from it.

Thank you!

On Tue, 21 Dec 2021, 16:06 Jérôme Pouiller, @.***> wrote:

See also #3 https://github.com/jerome-pouiller/reredirect/issues/3

— Reply to this email directly, view it on GitHub https://github.com/jerome-pouiller/reredirect/issues/15#issuecomment-998853180, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACZKPOEYQLL5GK7LF2NEPSDUSCJXHANCNFSM5KNU53XQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

[danergo]

Cross-compilation of reptyr:

Cross-compilation of reredirect (after adding aarch64.h from reptyr and modifying the ptrace IFDEF ladder:

After a few mods, I'm now at this compile error:

[danergo]

So, reptyr compiles fine, and works, but not as nice as rerepeat. So I really love to compile rerepeat for aarch64, but I can't solve that issue above with the missing __NR_* functions. I guess some includes are still missing, because reptyr also having those.

[jerome-pouiller]

Indeed, evolved since the last time I have watched it. Especially, ptrace.h now contains:

#ifdef __linux__
#ifdef __arm__
    struct user_regs regs;
#elif defined(__powerpc__)
    struct pt_regs regs;
#else
    struct user_regs_struct regs;
#endif
#elif defined(__FreeBSD__)
    struct reg regs;
#endif

I have to check that carefully, but I think that updating ptrace.h and importing platform/linux/arch/aarch64.h could be sufficient to make reredirect works (PR are welcome :-) ).

[danergo]

Actually I have made it compiling, but doesn't work, nothing is piped, original pty remains active. I'll share more details later, and I hope we would figure it out :)

[danergo]

Here is my patch file: make_aarch64_working.zip

You also have to add "aarch64.h" from reptyr.

But this is not working, here is the output:

reredirect -o $FIFO_OUT 1873
[-] Unable to open the file in the child.
# Previous state saved. To restore, use:
reredirect -N -O -1 -E -1 1873

And the 1873 process is still writing to its original FDs. I guess this is because I had to change open to openat syscalls, and that might require something else too. If you could look into it, you might be able to spot if faster than me, as I don't really have too much experience on this level of PTYs.

Cheers, D.

[jerome-pouiller]

Indeed, you have to keep do_syscall(child, open, ...) and do_syscall(child, dup, ...). I think you can just:

• add SC(open) and SC(dup) in default-syscalls.h
• add long nr_open and long nr_dup to struct syscall_numbers

[danergo]

I thought on that too, but it results another error:

In file included from ptrace.c:99:
arch/default-syscalls.h:1:31: error: ‘__NR_open’ undeclared here (not in a function)
    1 | #define SC(name) .nr_##name = __NR_##name
      |                               ^~~~~
arch/default-syscalls.h:4:5: note: in expansion of macro ‘SC’
    4 |     SC(open),
      |     ^~
make: *** [<builtin>: ptrace.o] Error 1

Removing SC(open) from default-syscalls.h results a successful build, but I think it won't work properly.

[jerome-pouiller]

It seems that open() is not available on all architecture. I think the change bellow could allow to use openat() instead of open().

diff --git i/attach.c w/attach.c
index 8d3e334..a1f5aee 100644
--- i/attach.c
+++ w/attach.c
@@ -100,8 +100,8 @@ int child_open(struct ptrace_child *child, child_addr_t scratch_page, const char
         return child->error;
     }

-    child_fd = do_syscall(child, open, scratch_page,
-                          O_RDWR | O_CREAT, 0666, 0, 0, 0);
+    child_fd = do_syscall(child, openat, -1, scratch_page,
+                          O_RDWR | O_CREAT, 0666, 0, 0);
     if (child_fd < 0) {
         error("Unable to open the file in the child.");
         return child_fd;

[danergo]

Hi, thank you. Unfortunately this is still not working:

# reredirect 8616 -m /tmp/fifo
Unable to attach to pid 8616: Invalid argument

[danergo]

Oh,, and btw, have a Merry Christmas :)

[jerome-pouiller]

Can you test the patch below (it works on my workstation):

From 627cfa95648d971f4b8e3a80fdcc576f6fc91cb6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Pouiller?= <jerome.pouiller@silabs.com>
Date: Tue, 28 Dec 2021 11:51:56 +0100
Subject: [PATCH] Replace open() by openat()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
---
 arch/amd64.h            | 2 +-
 arch/default-syscalls.h | 2 +-
 attach.c                | 4 ++--
 ptrace.h                | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/amd64.h b/arch/amd64.h
index bb81a29..c174c2d 100644
--- a/arch/amd64.h
+++ b/arch/amd64.h
@@ -77,7 +77,7 @@ struct syscall_numbers arch_syscall_numbers[2] = {
         .nr_wait4   = 114,
         .nr_signal  = 48,
         .nr_rt_sigaction = 173,
-        .nr_open    = 5,
+        .nr_openat  = 295,
         .nr_close   = 6,
         .nr_ioctl   = 54,
         .nr_dup2    = 63,
diff --git a/arch/default-syscalls.h b/arch/default-syscalls.h
index 756887b..bf43168 100644
--- a/arch/default-syscalls.h
+++ b/arch/default-syscalls.h
@@ -23,7 +23,7 @@
      .nr_signal = -1,
 #endif
     SC(rt_sigaction),
-    SC(open),
+    SC(openat),
     SC(close),
     SC(ioctl),
     SC(dup2),
diff --git a/attach.c b/attach.c
index 8d3e334..33f90f2 100644
--- a/attach.c
+++ b/attach.c
@@ -100,8 +100,8 @@ int child_open(struct ptrace_child *child, child_addr_t scratch_page, const char
         return child->error;
     }

-    child_fd = do_syscall(child, open, scratch_page,
-                          O_RDWR | O_CREAT, 0666, 0, 0, 0);
+    child_fd = do_syscall(child, openat, AT_FDCWD, scratch_page,
+                          O_RDWR | O_CREAT, 0666, 0, 0);
     if (child_fd < 0) {
         error("Unable to open the file in the child.");
         return child_fd;
diff --git a/ptrace.h b/ptrace.h
index 4953ca6..21970cb 100644
--- a/ptrace.h
+++ b/ptrace.h
@@ -74,7 +74,7 @@ struct syscall_numbers {
     long nr_wait4;
     long nr_signal;
     long nr_rt_sigaction;
-    long nr_open;
+    long nr_openat;
     long nr_close;
     long nr_ioctl;
     long nr_dup;
-- 
2.34.1

[danergo]

Thank you. On aarch64 it is still the same as before: "Unable to attach to pid".

[danergo]

Hi! Happy New Year!

How did you test this patch? I mean on which architecture? AMD64?

Because your patch contains some diff in amd64.h which in my case is not compiled at all into the binary on aarch64 platform.

[danergo]

Hi! I just got back to here, and willing to solve this. Thanks a lot for your help, if we could look into it again I'd appreciate that, otherwise I'll try to solve this, hopefully I could succeed at some point :)

Thanks!

[danergo]

Partial success:

Using gdb I can attach to a running process and can redirect its output to a file with this command:

(gdb) p (int)dup2((int)open("/tmp/process_stdout", 1089, 0777), 1)

This led me to these conclusions:

1. open syscall is available and callable
2. redirection can work, gdb is a proof-of-concept