Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 28 Nov 2017 10:50:14 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Wasm support patch 2 (static syscalls)

On Tue, Nov 28, 2017 at 04:08:06PM +0100, Szabolcs Nagy wrote:
> * Nicholas Wilson <nicholas.wilson@...lvnc.com> [2017-11-28 14:53:58 +0000]:
> > I think LTO would be required - but I might be missing something
> > in your scheme? I'm considering the cases like __setxid and
> > pthread_cancel, where the compiler can't work out which syscall
> > numbers are possible (because the numbers come from another
> > translation unit). In these cases, there's no way to eliminate any
> > of the branches in your switch statement.
> > 
> > In particular, getuid() is such a common library call that I think
> > we do want to be able to support it on Wasm, without having Musl
> > link in everything. I mean, it's not an obscure piece of
> > functionality, so it's worth a small refactor to make it usable
> > with Wasm.
> 
> getuid is not affected, only __setxid and cancellable syscalls are.
> 
> __setxid is not that important and can be worked around in generic code,
> but i don't see an easy solution for syscall_cp except that wasm
> probably don't need cancellation at all so it can be just defined
> to syscall.

I don't think calling __setxid even makes sense in wasm code. Do you
actually have a multiuser model with a privileged user who can change
uid to other users?

Cancellation is actually hard to do via an approach like this, since
you need some mechanism for determining the point at which the syscall
has atomically succeeded versus being blocked with no side effects
yet. Implementing it would probably require doing something similar to
what midipix does, but for now it can probably just be omitted.

Rich

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ