On Sat, 1 Sep 2001, Greg KH wrote: > On Sat, Sep 01, 2001 at 07:25:03PM -0400, jmjonesat_private wrote: > > > > I had not thought this was the "policy", at this point, but rather had > > believed that SGI was reviewing "some authoritative" and had responded > > positively to a limitted application. > > > > If it's a complete "NO", I will procede forward based on that. > > Come on people. We went over this months ago. I was very surprised to > see it come up again at the BOF meeting, which I interpreted as Crispin of > WireX giving SGI the benefit of the doubt. Since neither of them have > really talked about it since then on the list, I don't see any reason > why we would change the proposed plan that I thought we had all agreed > upon. > Yes, we did discuss it a long time ago. Since then, several (imho "brave") souls have continued to bring it up again and again. That suggests to me the "final discussion" is still to be entertained. To be perfectly clear: I do NOT (NOT NOT NOT) believe that restrictive_only is NOT (NOT NOT NOT) the way to go. What I know is: 1) it doesn't work for ME (hey, who am I but a PITA on this list.) 2) there have been convincing opinions that haven't, imho, been argued to the ground about authoritative hooks. 3) There has not yet been any "official" acceptance of any compromise, because the issue has not been totally and thoroughly discussed to a consensus. I DO know there are several people/concerns that are deeply concerned about this condition, including me. I DO know that many have proposed compromise solutions that have been rejected APPARENTLY "out-of-hand", and I responded to only one of YOUR rejections. I don't think this issue is dead. Perhaps there is still an opening to start a new thread "Authoritative Concerns VS. The Current Restrictive_Only policy", which may include mechanisms to circumvent the necessity of authoritative hooks, but I *do* think we need to explore this idea to the logical conclusion... Crispin? Any way you might allow this without rocking the boat? > > I'd think that a mechanism to init blobs reliably without conflict would > > be a consideration if this support was to be applied. I admit I haven't > > looked "very closely" at the patch with this regard... our prototypes > > assume that a NULL is an un-allocated blob and don't deal with locking. > > That's a good assumption to make :) > But you really should consider locking things when modifying them if > another processor could be modifying them at that same moment also (like > within your same function.) How? If the "blob" is not allocated and the module gets it, how do I lock it prior to one of the threads allocating and starting it flying? If it's allocated, I have concerns about who allocated it before my module got loaded. Perhaps a means for LSM to allocate these structures on initialization might be useful, and to deallocate them when a new module is loaded; perhaps simply a "recommended" technique published to this list might suffice. Perhaps, a function that handles the locking might be useful. If the NULL is the lock, I'm all for that. Can we agree, as a group, to maintain this lock condition and evaluate where it needs to be enforced? I stongly doubt it. I recommend this: modules keep a pointer list of the places they've poked an allocated structure and, on exit, replace those points with NULL. When allocating a new structure that is "hanged" off a kernel structure, they require the pointer to be NULL immediately before assignment and employ some kernel structure locking (lock_kernel?) to prevent multiple assignment... This is (exceptionally, since tasks may disappear) not the perfect solution, but is there another "hard" suggestion that will serve this purpose? If nobody HAS a solution, let's ignore it... since it's not fixable. When a prior module is loaded, should it not be required to deallocate all structures and return their pointers to NULL? > > > We DID see locking as a consdir-able issue and hoped it would get more > > discussion. > > I'd be glad to talk about it if anyone has any questions. Locking > problems are something that I like to mess with. There are lots of > different ways to implements locks in the Linux kernel, depending on > your requirements. Okay, query: if there are tasks and inodes and other kernel structures that have unallocated sub-structures when a module initializes... what is your advice with regard to how to allocate that structure in the "new" module paradigm? > > thanks, > > greg k-h > J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Sat Sep 01 2001 - 17:49:59 PDT