Bug#474648: seccomp is zero runtime overhead - Debian

This is a discussion on Bug#474648: seccomp is zero runtime overhead - Debian ; Hello, The story about seccomp is that as long as there are users CPUShare will support it because it's a more efficient and more secure computing model. About the seccomp overhead, that is zero. It adds zero overhead to the ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Bug#474648: seccomp is zero runtime overhead

  1. Bug#474648: seccomp is zero runtime overhead

    Hello,

    The story about seccomp is that as long as there are users CPUShare
    will support it because it's a more efficient and more secure
    computing model.

    About the seccomp overhead, that is zero. It adds zero overhead to the
    fast path of the scheduler. It never added any overhead on x86-64. For
    x86 I added a tsc_disable feature that wasn't zero overhead initially
    and so that was used as argument against seccomp (despite it really
    had little to do with the seccomp core), it is zero overhead now that
    I optimized that little tsc_disable feature.

    So you can always enable seccomp on x86-64 without performance
    worries (I guess it only adds an hundred byte of .text).

    On x86 you can enable seccomp as safely as on x86-64 if you find a
    TIF_NOTSC implemented in your x86 32bit kernel. TIF_NOTSC is zerocost
    and so after implementing TIF_NOTSC, I changed seccomp to use it to
    avoid any overhead in all archs.

    In the latest kernels the only overhead generated by seccomp is a bit
    larger .text image, everything else is false or obsolete.



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. Bug#474648: seccomp is zero runtime overhead

    On Thu, Apr 10, 2008 at 04:53:16AM +0200, Andrea Arcangeli wrote:
    > Hello,
    >
    > The story about seccomp is that as long as there are users CPUShare
    > will support it because it's a more efficient and more secure
    > computing model.
    >
    > About the seccomp overhead, that is zero. It adds zero overhead to the
    > fast path of the scheduler. It never added any overhead on x86-64. For
    > x86 I added a tsc_disable feature that wasn't zero overhead initially
    > and so that was used as argument against seccomp (despite it really
    > had little to do with the seccomp core), it is zero overhead now that
    > I optimized that little tsc_disable feature.
    >
    > So you can always enable seccomp on x86-64 without performance
    > worries (I guess it only adds an hundred byte of .text).
    >
    > On x86 you can enable seccomp as safely as on x86-64 if you find a
    > TIF_NOTSC implemented in your x86 32bit kernel. TIF_NOTSC is zerocost
    > and so after implementing TIF_NOTSC, I changed seccomp to use it to
    > avoid any overhead in all archs.
    >
    > In the latest kernels the only overhead generated by seccomp is a bit
    > larger .text image, everything else is false or obsolete.


    What about non-x86 architectures, well i guess ia64 and
    powerpc/powerpc64 are the most interesting candidates.

    Friendly,

    Sven Luther



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  3. Bug#474648: seccomp is zero runtime overhead

    On Thu, Apr 10, 2008 at 09:28:24AM +0200, Sven Luther wrote:
    > What about non-x86 architectures, well i guess ia64 and
    > powerpc/powerpc64 are the most interesting candidates.


    It should be zero cost there too if it has been implemented
    correctly. The only feature that initially generated a minimum
    overhead to the scheduler was present on x86 (the TIF_NOTSC removed
    that overhead from the fast path completely). This is because
    disabling the tsc was mostly an issue for Intel hyperthreading and not
    for anything else so all other archs should have seccomp
    implementations that have always been zero cost like in x86-64.



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread