[lkml]   [2005]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: seccomp for 2.6.11-rc1-bk8
    On Fri, Jan 21, 2005 at 08:55:22PM +0100, Ingo Molnar wrote:
    > * Chris Wright <> wrote:
    > > * Rik van Riel ( wrote:
    > > > Yes, but do you care about the performance of syscalls
    > > > which the program isn't allowed to call at all ? ;)
    > >
    > > Heh, no, but it's for every syscall not just denied ones. Point is
    > > simply that ptrace (complexity aside) doesn't scale the same.
    > seccomp is about CPU-intense calculation jobs - the only syscalls
    > allowed are read/write (and sigreturn). UML implements a full kernel
    > via ptrace and CPU-intense applications run at native speed.

    Indeed. Performance is not an issue (in the short term at least, since
    those syscalls will be probably network bound).

    The only reason I couldn't use ptrace is what you found, that is the oom
    killing of the parent (or a mistake of the CPU seller that kills it by
    mistake by hand, I must prevent him to screw himself ;). Even after
    fixing ptrace, I've an hard time to prefer ptrace, when a simple,
    localized and self contained solution like seccomp is available.

    The reason I called it seccomp and not restricted syscalls, is that I'm
    not allowing Chris to choose which syscall to restrict. I restricted
    only the ones that are required to be able to compute securely, hence
    the name "seccomp" and not "restricted syscalls". Obviously I'm
    restricting certain number of syscalls to create this seccomp mode.

    I'm open to different solutions, I can even live with you forcing me to
    use the fixed version of ptrace, but you must be confortable to take the
    blame if it breaks ;). Personally I'm confortable to take the blame only
    if seccomp breaks, it's so simple that it can't break. And with break I
    don't mean 0xf00f, that's a minor issue that will be autodetected by the
    system. I mean breaking like killing the ptrace parent right now... That
    can be fixed up reasonably securely too, but it _can't_ be autodetected
    easily (I keep cross logs for everything so I can trace it, but it
    won't be an immediate/automated task like the 0xf00f or fcnlex).
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:09    [W:0.023 / U:30.712 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site