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 <tho...@m3y3r.de> 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
>
>
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
