Skip to content
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

Alternative of rump server #18

Open
xlz opened this issue May 7, 2015 · 1 comment
Open

Alternative of rump server #18

xlz opened this issue May 7, 2015 · 1 comment

Comments

@xlz
Copy link

xlz commented May 7, 2015

I just figured out why rumpkernel is used here:

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.

@thehajime
Copy link
Member

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.

what do you think ?

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