Re: Locking task->security

From: richard offer (offerat_private)
Date: Thu Aug 30 2001 - 17:33:25 PDT

  • Next message: Seth Arnold: "Re: Locking task->security"

    * frm gregat_private "08/30/01 15:39:29 -0700" | sed '1,$s/^/* /'
    * On Thu, Aug 30, 2001 at 02:47:22PM -0700, richard offer wrote:
    *> \begin{A non-kernel person stupid question}
    *> I have my own blob in current->security, it comprises a bunch of data
    *> that I think I need to lock access to.
    *> My naive options appear to be :-
    *>     1) lock the whole task structure (very bad)
    *>     2) add a new security specific lock to the task to protect access to
    *> the security blob
    *>     3) add a lock inside the structure hanging off security (bad)
    *>     4) add a global policy specific lock (bad)
    * Do either #1 or #3, but do it _within_ your module.  Since the
    * ->security blob is only being touched by your module, only you know what
    * kind of lock you need, and when you need it.  So hang it off of the
    * security blob, or have a static lock in your module that you use.
    Wouldn't a static lock be 4) (that was what I meant by 4)) ?
    * Remember, there are a lot of different kinds of locks, all for different
    * things, picking any one of them as the "security" lock in the LSM code
    * would not work for everyone.
    See...if only there was only one lock it would be easy :-) Having a void *
    security_lock member in the task struct would provide enough mechanism for
    2) without setting policy.
    * Does that help?
    From Chris's explanation it seems that I shouldn't need to lock
    current->security only the contents of current->security is that true ?
    Assuming the worst case scenario, is there no way that current->security
    (not the contents) can be accessed from multiple locations simmultaniously
    ? Is it possible for a single process to call two system calls at the same
    time ? My guess is no, not with the current threading model (n-to-1) ?
    Are there any plans to re-do the threading to provide a n-to-m type model ?
    Wouldn't that sort of be something needed to get Linux to scale to higher
    CPU counts (in terms of usefulness to applications) ? 
    * thanks,
    * greg k-h
    Richard Offer                     Technical Lead, Trust Technology, SGI
    "Specialization is for insects"
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Thu Aug 30 2001 - 17:34:48 PDT