You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since the NUSE host backend embeds a network stack into a
single process, other processes have no access neither to the
process nor the network stack. As a result, we cannot benefit
to reuse standard configuration tools such as iproute2 and
iptables as DCE does.
Rump kernel seems a quite heavy dependency here. Is it possible to just
insert some execve("iptables ...") in between the syscalls of the hijacked application?
I think even putting invocations of iproute2/iptables in the static nuse.conf would set up the network stack nicely for most of applications. And that would only require some execve's during initialization and avoid any task scheduling.
The text was updated successfully, but these errors were encountered:
it's up to what the 'rump kernel' is but I didn't use the entire rumpkernel code here: just reuse a function, system call proxy.
indeed, execve and co. would be possible but the reason of my initial choice is that I don't want to touch existing code (e.g., iproute2, iptables). these tools are not only used in the initialization, but also in the runtime for monitoring purpose for instance. an external process via rump kernel syscall proxy meets this requirement.
I just figured out why rumpkernel is used here:
Rump kernel seems a quite heavy dependency here. Is it possible to just
insert some execve("iptables ...") in between the syscalls of the hijacked application?
I think even putting invocations of iproute2/iptables in the static
nuse.conf
would set up the network stack nicely for most of applications. And that would only require some execve's during initialization and avoid any task scheduling.The text was updated successfully, but these errors were encountered: