Unable to Share Analysis Data via Shared Memory

[Masazumi Azuma]

I am attempting to run two instrumentation processes using DynamoRIO and share their analysis data via shared memory. Specifically, I write the analysis data to shared memory from each process and aim to access it from the other.

However, I am currently unable to properly access the shared memory from the instrumented processes, and the data sharing fails.
Is there a recommended way to make shared memory work with DynamoRIO-instrumented processes? Or should I consider switching to a file-based approach instead?

Environment:
QEMU Debian 5.10.234-1 armv7l

Source Code:

Uninstrumented core.cpp:

```cpp
int main()
{
  int fd = open("/dev/shm/hoge", O_CREAT | O_TRUNC, 0666);
  ftruncate(fd, 96);
  auto p = (hoge_struct *)mmap(nullptr, SHM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);

  // Initialize all 96 bytes to -1

  execv(drrun processA); // Arguments for DynamoRIO are correct
  execv(drrun processB);
  wait();
}
```

Process A and B (same logic; currently testing only with Process A):
```cpp
dr_client_main(client_id_t id, int argc, const char *argv[])
{
  int fd = open("/dev/shm/hoge", O_RDWR, 0666);
  auto p = (hoge_struct *)mmap(nullptr, SHM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);

  // When inspecting the contents of 'p', all bytes are 0
}
```

Thank you very much for your support. I look forward to your advice.

Best regards,
Masazumi Azuma

[Derek Bruening]

Your approach works on my system and the -1 is visible but only if the client opens and maps read-only: if it opens writable the file is truncated to 0 size (with or without the original O_TRUNC).

Mapping read-write works before the exec.  So some kernel-varying exec behavior?  Presumably unrelated to DynamoRIO.

--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dynamorio-users/8d194d9d-9284-48aa-a8f7-9737ed2db45en%40googlegroups.com.

[Derek Bruening]

Ah, scratch that last bit: this (my truncation at least) is DR's fault.  -steal_fds 0 not affecting it threw me off: it turns out to not be from the fd dup.  I filed https://github.com/DynamoRIO/dynamorio/issues/7562 on this.  A temporary workaround is to s/open(/syscall(SYS_open, / (but that is not the best long term solution as it bypasses fd protection and so may fail on some apps).

[東政澄]

Dear Derek

Thank you for your response.
I tested the workaround and confirmed that it behaves as expected.
I'm glad the issue could be reported as a bug in DynamoRIO.
I hope it will be resolved in a future update.

2025年7月22日火曜日 13:08:38 UTC+9 Derek Bruening:

[Derek Bruening]

Note that the recommended approach is for your client to use dr_open_file and dr_map_file instead of open and mmap. Using syscalls that DR does not see can cause transparency and other issues.  Library isolation is attempted but is difficult and best-effort.

To view this discussion visit https://groups.google.com/d/msgid/dynamorio-users/5cc02069-7961-444f-9082-31f42223e1d0n%40googlegroups.com.