Re: [PATCH] rumpuser__errtrans_rump2host()

  • From: Robert Millan <rmh@xxxxxxxxxxx>
  • To: pooka@xxxxxx, rumpkernel-users@xxxxxxxxxxxxx
  • Date: Wed, 12 Aug 2015 22:03:35 +0200

Hi Antti,

El 11/08/15 a les 01:17, Antti Kantee ha escrit:

On 10/08/15 21:26, Robert Millan wrote:
If you want more, look at syscall compat (full, automated translation)

Please forgive my ignorance, but I'm not sure what you mean by syscall
compat. Could
you point me to some document and/or source file to look at?

Syscall compat is like COMPAT_FOO in NetBSD. It translates the args of FOO to NetBSD and
the results back. In the case of normal NetBSD, syscall compat allows running FOO
binaries on NetBSD. For rump kernels, it allows rump kernel system calls made from FOO
userland to work against rump kernels as-in, e.g. calling rump_sys_stat() with a host
"struct stat" will work. Substitute FOO for e.g. LINUX, and you probably get
the idea.

Look at libsys_* in src/sys/rump/kern/lib.

The only downside is that the semantics turned out to be really hard to figure
out. Currently, if you link a libsys_foo against a rump kernel, _local_ client
syscall will use the translation (linking multiple libsys_foo is bad). Remote
ones will not simply because we couldn't figure out sensible semantics. For
example, if a remote client automatically gets a syscall vector for its host,
what do you do if you want some remote client to make native calls not covered
by the compat vector (e.g. mount()). Would it be secure to allow for native
and non-native syscalls for the same process (talking about the rump kernel's
idea of a process, of course)? Notably, the previous is not a security issue
for local clients because, well, they're local. If you're really interested in
some specific, I might be able to find to more details of the semantics woes
from some old private emails with Arnaud (they predate the existence of this
list), but I don't want to spend effort for diggi
for a "yea sure why not".

Thanks for the detailed explanation. My goal is to return correct errnos for a
limited set of
syscalls with very standard semantics (open, read, write...).

So in this case errno translation is the only missing bit. Fortunately this can
be implemented
in a very generic/portable way (i.e. current errtrans facility). I looked at
the interface you
described, and it seems like using it would sacrifice portability as it intends
to be more
complete and hence inherently less portable (seems to me like you can't have

In summary, how would I go about writing portable host code which uses
rump_sys_open() and
its friends, while fixing the returned errno?

Robert Millan

Other related posts: