Re: [uml-user] Could UML run via seccomp traps instead of ptrace?

[Dan K. <da...@wh...>]

The thinking is we'd add another SECCOMP_RET type, such that UML didn't
need to depend on ptrace.  Ptrace isn't the fastest mechanism, and beyond
that, if we can avoid it it's a lot easier to syscall firewall UML as a
whole (and freeze/restore it with CRIU).

On Sat, May 13, 2017 at 3:13 AM, Thomas Meyer <th...@m3...> wrote:

> Hello!
>>
>
> Hi,
>
>    So I've been spending some time in UML (among other virtualization
>> technologies).  There's some interesting security and performance models
>> it
>> possibly allows, even in this era of containers and hypervisors.  Ptrace
>> is
>> being something of a problem though; it's a little hairy and difficult to
>> scope.  It is unfortunately breaking many things I'm trying to do.
>>
>>     So I'm curious.  There is another option -- seccomp-bpf can trap on
>> arbitrary syscalls.  Is there a reason anyone sees why UML couldn't be
>> routed through it?
>>
>
> I had a look at this and I think it could work.
>
> But what mode would you suggest?
>
> a.) SECCOMP_RET_TRAP
> Each usermode process would receive an SIGSYS and forward it to the kernel
> process somehow? and continue afterwards.
>
> b.) SECCOMP_RET_TRACE
> the kernel process would still ptrace each usermode process and intercept
> all syscalls?
> What would be the difference to the current mode of operation? what would
> we gain here?
>
> with kind regards
> thomas
>
>
>
>