PRoot v3.0

[Cédric VINCENT]

Release v3.0
============

New features
------------

* PRoot can now use the kernel feature named "seccomp-filter", a.k.a
  "seccomp mode 2", to improve its own performance significantly.  For
  examples, the tables below show the time overhead induced by PRoot
  compared to a native execution, on my workstation:

  - when generating the Perl 5.16.1 package:

    ===============  ===========  ==========
    command          seccomp off  seccomp on
    ===============  ===========  ==========
    ./configure.gnu          75%         25%
    make -j4                 70%         45%
    make -j4 check           25%          9%
    ===============  ===========  ==========

  - when generating the Coreutils 8.19 package:

    ===============  ===========  ==========
    command          seccomp off  seccomp on
    ===============  ===========  ==========
    ./configure              80%         33%
    make -j4                 75%         33%
    make -j4 check           80%          8%
    ===============  ===========  ==========

* It is now possible to explicitly not dereference the guest location
  of a binding by specifying ``!`` as the first character.  For
  instance::

      proot -b /bin/bash:!/bin/sh

  will not overlay ``/bin/dash`` when this latter is pointed to by
  ``/bin/sh`` (it's typically the case on Ubuntu and Debian).

Fix
---

* The initial command is not search in $PATH anymore when it starts
  with ``/`` or ``./``, and it doesn't exist.  For instance::

      $ rm test
      $ proot ./test
      proot warning: './test not found (root = /, cwd = /usr/local/cedric/git/proot)
      proot error: see `proot --help` or `man proot`.

Thanks
------

Many thanks to Will Drewry and Indan Zupancic, who made possible to
accelerate PTRACE_SYSCALL with seccomp-filter.  Also, thanks to Paul
Moore for his valuable set of seccomp tools.

Notes
-----

* Unlike what I said, this release is not shipped with a ptrace
  emulator.  It's planned for the next one, though.

* Seccomp-filter was first introduced in Linux 3.5 a year ago, it was
  also officially back-ported to Ubuntu 12.04 (Linux 3.2).  To know if
  PRoot is actually using this accelerator on your system, check the
  verbose output.  For instance::

    $ proot -v 1 true
    ...
    proot info: ptrace acceleration (seccomp mode 2) enabled
    ...

  But first, be sure it was built with this support::

    $ proot -V
    ...
    built-in accelerators: process_vm = yes, seccomp_filter = yes
    ...

[Gabriel Grant]

This is great, thanks so much!

--
 
---
You received this message because you are subscribed to the Google Groups "PRoot" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proot_me+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Cédric VINCENT]

On Mon, Jun 3, 2013 at 6:17 PM, Gabriel Grant <mem...@gmail.com> wrote:
> This is great, thanks so much!

Thanks :)

[hhm]

> New features
> ------------
>
> * PRoot can now use the kernel feature named "seccomp-filter", a.k.a
> "seccomp mode 2", to improve its own performance significantly. For
> examples, the tables below show the time overhead induced by PRoot
> compared to a native execution, on my workstation:
>

Similarly, uprobes (http://lwn.net/Articles/499190/) was merged in
kernel 3.5; maybe PRoot can use it. (Since it does some of what ptrace
does, to be activated by code calls.)

not sure if it would help at all, though...

Also, maybe userns
(https://plus.google.com/107605112469213359575/posts/1DmdEWxDD1y) can
similarly be used as an accelerator for PRoot (example: path
translation via mount namespaces, -0 via user namespaces)?


And thanks for the new release of PRoot!

[Cédric VINCENT]

On Wed, Jun 5, 2013 at 6:14 AM, hhm <heeh...@gmail.com> wrote:
> Similarly, uprobes (http://lwn.net/Articles/499190/) was merged in
> kernel 3.5; maybe PRoot can use it. (Since it does some of what ptrace
> does, to be activated by code calls.)
>
> not sure if it would help at all, though...

Sadly, it's not possible to change process registers (i.e. syscall
parameters) with uprobes. Also, uprobes requires to disassemble
objets files to find the expected addresses (i.e. syscall traps for
PRoot), which would be possible for self modifying code (like in JIT
compilers).

> Also, maybe userns
> (https://plus.google.com/107605112469213359575/posts/1DmdEWxDD1y) can
> similarly be used as an accelerator for PRoot (example: path
> translation via mount namespaces, -0 via user namespaces)?

Yes, it is planned :)

Sadly, as of Linux 3.10-rc4, support for userns is not enable by
default because XFS does not fully support it yet:

https://github.com/torvalds/linux/blob/v3.10-rc4/init/Kconfig#L1102

With this PRoot accelerator, the overhead should be closed to 0%!

> And thanks for the new release of PRoot!

You're welcome :)

Cédric.

[mark.c...@smorg.co.uk]

On Wednesday, 5 June 2013 08:40:41 UTC+1, Cédric VINCENT wrote:

On Wed, Jun 5, 2013 at 6:14 AM, hhm <heeh...@gmail.com> wrote:

With this PRoot accelerator, the overhead should be closed to 0%!

Do you mean with this release, v3.0, that overhead will be close to 0%?

Thanks!