cargo test finally timed out about proot-rs

[imlk0]

The timeout is caused by this test case:

proot-rs/src/register/regs.rs

Lines 403 to 445 in 7d537c0

	fn test_push_regs_void_sysnum_sleep_test() {
	let mut sleep_exit = false;
	fork_test(
	"/",
	// expecting a normal execution
	0,
	// parent
	|tracee, _| {
	if tracee.regs.get_sys_num(Current) == NANOSLEEP {
	// NANOSLEEP enter stage
	tracee.regs.set_restore_original_regs(false);
	tracee.regs.save_current_regs(Original);
	// we cancel the sleep call by voiding it
	tracee
	.regs
	.cancel_syscall("cancel sleep for push regs test");
	tracee.regs.push_regs().expect("pushing regs");
	// the new syscall will be nanosleep's exit (with a sys num equal to 0)
	sleep_exit = true;
	} else if sleep_exit {
	// NANOSLEEP exit stage
	tracee.regs.set_restore_original_regs(true);
	tracee.regs.set(SysResult, 0, "simulate successful sleep");
	tracee.regs.push_regs().expect("pushing regs");
	return true;
	}
	false
	},
	// child
	|| {
	// calling the sleep function, which should call the NANOSLEEP syscall
	execvp(
	&CString::new("sleep").unwrap(),
	&[CString::new(".").unwrap(), CString::new("9999").unwrap()],
	)
	.expect("failed execvp sleep");
	},
	);
	}

It can be reproduced by:

cargo test -- --nocapture register::regs::tests::test_push_regs_void_sysnum_sleep_test

[imlk0]

fixed in #14

[imlk0]

It seems that /bin/sleep uses syscall CLOCK_NANOSLEEP

while the code capture syscall NANOSLEEP only:

proot-rs/src/register/regs.rs

Line 412 in 7d537c0

if tracee.regs.get_sys_num(Current) == NANOSLEEP {

Therefore, the process will not exit until 9999 seconds.

[imlk0]

Another issue is that cancel_syscall() is implemented by set SysNum to VOID

proot-rs/src/register/regs.rs

Lines 268 to 272 in 7d537c0

	/// Little utility method to quickly void the syscall number.
	#[inline]
	pub fn cancel_syscall(&mut self, justification: &'static str) {
	self.set(SysNum, VOID, justification);
	}

while the VOID is defined as 0

proot-rs/src/register/regs.rs

Line 11 in 7d537c0

const VOID: Word = 0;

which is exactly is the system call number of READ system call in x86_64 linux:

It seems that there is no way to cancel a syscall using ptrace.
Another way is to use an unused system call number(e.g. u64::MAX). In this case, the system call will fail.