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.

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

next steps with rseq #1814

Open
2 of 9 tasks
mihalicyn opened this issue Apr 19, 2022 · 5 comments
Open
2 of 9 tasks

next steps with rseq #1814

mihalicyn opened this issue Apr 19, 2022 · 5 comments
Assignees
Labels
enhancement no-auto-close Don't auto-close as a stale issue testing

Comments

@mihalicyn
Copy link
Member

mihalicyn commented Apr 19, 2022

Thread to cover the next steps with rseq support improvements:

  • tests for all architectures (right now we have ZDTM tests only for x86_64)
  • move all rseq related code into a separate file (?)
  • improvement support of built-in rseq for non-Glibc libraries
  • detect built-in rseq support dynamically as Mathieu proposed
  • pre-dump tests (?)
  • leave-running tests (?)
  • crfail test
  • fault injection test (?)
  • threaded test

https://criu.org/Rseq

@mihalicyn mihalicyn self-assigned this Apr 19, 2022
@mihalicyn mihalicyn added enhancement testing no-auto-close Don't auto-close as a stale issue labels Apr 19, 2022
@mihalicyn mihalicyn mentioned this issue Apr 19, 2022
10 tasks
@fweimer-rh
Copy link
Contributor

Regarding rseq registration detection, could you fork and obtain the details from the new process using ptrace? That would be library-agnostic. (I don't think self-ptrace works, but it might.) My concern here is not just other libraries, but quite selfishly glibc with a backport of internal rseq functionality (for sched_getcpu) without the public symbols.

@mihalicyn
Copy link
Member Author

Hi Florian,

Regarding rseq registration detection, could you fork and obtain the details from the new process using ptrace?

yes, we can. But I've concerns about performance, because we will need to add extra O(process_tree_size) complexity to the restore.

My concern here is not just other libraries, but quite selfishly glibc with a backport of internal rseq functionality (for sched_getcpu) without the public symbols.

Ugh. I had some idea. We can try to detect that *libc is used rseq by default by forking stub process and check if rseq is registered using ptrace. If yes then go to the expensive option of doing ptrace syscall for each process that we clone in CRIU.

@mihalicyn
Copy link
Member Author

mihalicyn commented Apr 22, 2022

Our friends from https://github.com/containers/podman met the problem containers/podman#13958

It looks related to this ABI change:
https://sourceware.org/pipermail/libc-alpha/2022-February/136024.html

Mathieu already suggested to use dlsym to get rseq __rseq_offset dynamically:
https://github.com/compudj/librseq/blob/170f840b498e1aff068b90188727a656111bfc2f/src/rseq.c#L109

But at the moment I don't know how to get "symbol size" using dlsym. I will read dl* implementation for getting more information.

Upd: okay it looks like dladdr1(..., RTLD_DL_SYMENT) is what we need.

@mihalicyn
Copy link
Member Author

#1937

@mihalicyn
Copy link
Member Author

Threaded test is implemented in a scope of
#2147
by @mclapinski

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement no-auto-close Don't auto-close as a stale issue testing
Projects
None yet
Development

No branches or pull requests

2 participants