Signal delivery to kernel threads/processes?

From: Robert Watson (rwatson_at_FreeBSD.org)
Date: 01/16/04

  • Next message: Eivind Eklund: "Re: Request for Comments: libarchive, bsdtar" 
    Date: Fri, 16 Jan 2004 14:00:56 -0500 (EST)
To: arch@FreeBSD.org

    Bill Paul raised an interesting question with me recently -- he observed
    that a userspace process running with root privileges could deliver a
    signal to a kthread, and that this might produce undesired behavior. I
    was sure that, at some point, we had a check disallowing this, but I don't
    see it in either RELENG_4 or HEAD. Do we rely on the ability to
    send/receive signals to interrupt kthreads, that we know of? While the
    signal delivery itself doesn't make sense, waking up a tsleep() with
    PCATCH could well be useful behavior. Should a kthread have to declare if
    it wants to receive interruptions? Given plans, at some point, to make
    kthreads be real threads, and be part of a kernel process, that would
    raise some challenges for code relying on the ability to be interrupted
    with a signal in kernel space, as signals generated by kill() are
    targetted at processes, not threads.

    Any thoughts? It's tempting simply to add the following to cr_cansignal()
    to at least disallow sourcing the signals in userspace:

            if (p->p_flag & P_SYSTEM)
                    return (EPERM);

    But I don't have a broad enough view of what goes on in the kernel to
    reason about what disasters this might cause if signalling is relied on.

    Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
    robert@fledge.watson.org Senior Research Scientist, McAfee Research

    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Eivind Eklund: "Re: Request for Comments: libarchive, bsdtar"

    Relevant Pages