Live data from Hacker News

Show HN: TARDIS – Warp a process's perspective of time by hooking syscalls

github.com

1–10 of 31 posts

Re: Show HN: TARDIS – Warp a process's perspective of time by hooking syscalls

#2
It's worth mentioning that libfaketime [1] is a more mature alternative with macOS support and more complete coverage of the relevant system calls. Nothing against the current project but that might be a better choice for many people.

[1] - https://github.com/wolfcw/libfaketime

Re: Show HN: TARDIS – Warp a process's perspective of time by hooking syscalls

#6

There's people that did this to cheat on our games. But using server time exclusively can help mitigate this.

It's also used in virus and malware detection. Lots of stuff lays low for a week or two to help hide the attack vector.

Re: Show HN: TARDIS – Warp a process's perspective of time by hooking syscalls

#8
post #2

It's worth mentioning that libfaketime [1] is a more mature alternative with macOS support and more complete coverage of the relevant system calls. Nothing against the current project but that might be a better choice for many people. [1] - https://github.com/wolfcw/libfaketime

Also you can google the name to figure out how to use it.

Re: Show HN: TARDIS – Warp a process's perspective of time by hooking syscalls

#9
There was some similar commercial implementation like this called "time machine" (I think) that sold like hotcakes during the Y2K prep work...had versions for all the various RISC vendors, Linux, etc.

Edit: Yep, still exists. Was $2000 per server back then. Wonder if the price was some sort of inside joke... $2k to prepare for Y2K? https://www.cnet.com/news/new-tool-tests-for-y2k-compliance/

Re: Show HN: TARDIS – Warp a process's perspective of time by hooking syscalls

#10
Nice Implementation! I built something similar a while ago to warp time in video games (for training reinforcement learning agents).

Some issues off the top of my head (that I ran into): VDSO censoring is a lot harder than just symbol overriding, it has to actually be removed from the aux vector (third thing on the process stack when the process launches after arguments and environment variables. The EHDR entry is what you need to remove.

Gist for censoring EHDR: https://gist.github.com/machinaut/a08b581c921775263cf0e20ccc...

Some libc's (notably glibc) are really good at finding/using EHDR even if you do that symbol overriding, so dumping EHDR is the most assured way of making sure it's gone.

ptrace overhead is HUGE -- because you're debugging a userspace program with another program every time call now results in 4 context switches (to/from your debugging program at every time call entry/exit), even pinning both to the same CPU this is not fast.

This is where my least favorite part of the linux kernel comes in handy: SECCOMP-BPF. Instead of firing _every_ syscall, you can write a syscall packet filter rules list that only matches certain time-based syscalls with certain arguments. This greatly improves the performance (but for me, still not fast enough to play video games live).

At the end of the day I ended up reviving a >10 year old patch someone sent to the linux kernel to add these parameters (time offset and time warp) to thread structs and do the warping in the kernel (much faster -- dont pay the context overhead, etc). Sadly even this didn't work because our end application needed to run on multiple clouds in docker, and we'd need to have access to the host kernel to do these operations.

I'd like to have an affine time warp as part of the cgroups, and then maybe extend it through runc so anyone can run time-warped docker containers, but maybe that's wishful thinking.

Overall I think this is great work, and super happy you posted it. I'd love to chat about it sometime.

(P.S. most ironic to me was my version of this was called 'timelord' :)

Post reply on HN