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. > JMJones was correct in labeling this issue "conditional": that is precisely what was decided at the BOF: SGI would demonstrate the viability of authoritative hooks as a solution to a variety of their problems by showing what additional patchwork would be needed to make the authoritative hooks "authoritative enough" to address their needs. If SGI did this, for some problematic cases, and the solution isn't too gross, then we'll go authoritative. Otherwise we revert to restrictive. > 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. > Exactly. > 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. > I too am still waiting to see the SGI response to the challenge, and if we never get one, we'll stay restrictive. But since the BoF was all of 2.5 weeks ago, I don't think it is yet a foregone conclusion that we're all-restrictive. >>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.) > Here I fully agree with Greg: if it is vitally important that your module manages all processes, including those that run before modules are loaded, then it is your problem to either walk the process table and do something about it, or opt to compile in your module. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html _______________________________________________ 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 : Sun Sep 02 2001 - 01:13:35 PDT