As far as I can tell, this is the new implementation of clone in their libc, which does things like opening cur_pid_fd and new_pid_fd, duplicating addrspace of cur_pid_fd (Redox dup has an optional second argument), and writing to current-addrspace of new_pid_fd.
If I understand correctly, thisproc:current/open_via_dup is a magic path that opens a process descriptor to the current process? It then has the ability to duplicate mappings from one process descriptor to another? That’s very Mach-like. It’s a shame that they’ve built access to the current process descriptor on top of a global namespace, which makes it harder to move to a clean capability model, but the rest of it looks very elegant.
Is there any way to return the money? Just because it was anonymous doesn’t mean there isn’t.
It’s Tornado Cash, so no, there isn’t.
I’m curious about moving clone and exec into userspace. Does anyone have a link to the underlying system call interfaces that make this possible?
As far as I can tell, this is the new implementation of clone in their libc, which does things like opening cur_pid_fd and new_pid_fd, duplicating addrspace of cur_pid_fd (Redox dup has an optional second argument), and writing to current-addrspace of new_pid_fd.
If I understand correctly,
thisproc:current/open_via_dupis a magic path that opens a process descriptor to the current process? It then has the ability to duplicate mappings from one process descriptor to another? That’s very Mach-like. It’s a shame that they’ve built access to the current process descriptor on top of a global namespace, which makes it harder to move to a clean capability model, but the rest of it looks very elegant.