Skip to content

Emulate vsyscalls without patching #2940

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

Open
rocallahan opened this issue Jul 22, 2021 · 2 comments
Open

Emulate vsyscalls without patching #2940

rocallahan opened this issue Jul 22, 2021 · 2 comments

Comments

@rocallahan
Copy link
Collaborator

Currently we "support" vsyscalls by patching the vsyscall call site to do a regular syscall (via syscallbuf if possible). This only works when the call site matches the known patch template. In issue #2939 it seems that IFUNC tricks are used to make time@plt select the vsyscall as the implementation function, which means we can't safely recognize and patch the actual call site. In issue #2929 we seem to have a function making a direct vsyscall, but with code that doesn't match the template. For the latter case we probably can (and probably should) simply add a new template that matches that code. To handle the former case, we could emulate vsyscalls in rr, which is what this issue is about. (This would also fix #2929 but it would be unnecessarily slow during recording.)

There are three vsyscalls: gettimeofday, time, and getcpu. (See Linux arch/x86/entry/vsyscall/vsyscall_64.c.) Basically we would AutoRemoteSyscall the required syscall, write appropriate syscall entry/exit records to the trace (with the right recorded-memory records), and fix up tracee registers to match the results of executing the vsyscall (i.e. including the implied ret after the syscall).

One special case is if the tracee's seccomp policy disallows the syscall. Linux handles this case, but for us to handle it would be extra work, and tricky too. Probably we can just ignore it since no sane sandboxing policy would block any of those syscalls.

@khuey
Copy link
Collaborator

khuey commented Jul 23, 2021

8a15f2a may have obviated the need for this.

@rocallahan
Copy link
Collaborator Author

Yeah in practice it probably does but I'll leave this open since someone could still have written code that does vsyscalls we can't patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants