Re: [PATCH] security_ops locking

jmjonesat_private

Okay, I've remained silent because I thought that "greater minds than mine
may be evaluating important stuff toward my objectives."

Would SOMEBODY please say this is a non-issue?  Based on the thread,
atomic pointer writes are assumed to be guarenteed by the architecture, is
that not so?  Since "comments/discussions" with the kernel developers seem
to suggest this is a linux kernel assumption, how can any "deeper
discussion" here provide anything but GREATER THAN protection for LSM
modules than any other kernel structures/interfaces?

Modules, most often, will insmod during boot-up and STAY THERE.  Removing
a module that supports hooks during operation is a fools game and I have a
lot of trouble seeing ANY admin doing this, without ding-dang-good reason. 
If he/she does... he's a fool (notice the politically correct twist
there.)

As far as module loads vs. boot-up: can anyone find a case where a module
is loaded asynchronously in a multi-CPU environment and could actually
TRIGGER this problem?

I think this is a "less than never" kind of problem that may affect other
parts of the kernel, as well, if it ever happens... and it never happens.
Introducing code that slows things down for a "never" case is foolish.  If
it's not a "never" case, then I withdraw my comments.

Is there ever a case, in any architecture, where this might be a valid
concern?

Sincerely,
J. Melvin Jones

*-------------------------------------------------------
* J. Melvin Jones                http://www.jmjones.com/
* Webmaster, System Administrator, Network Administrator
* ------------------------------------------------------

On Thu, 25 Jul 2002, Jesse Pollard wrote:

> ---------  Received message begins Here  ---------
> 
> > 
> > 
> > 
> > Chris Wright wrote:
> > 
> > > * James Morris (jmorrisat_private) wrote:
> > > 
> > > 
> > > Ok, this is the same thing I dug up.  Register size assignments are
> > > guaranteed atomic.
> > 
> > Well praise God for that; I originally wrote my code
> > assuming that. Greg KH's comment that they _aren't_
> > threw me for a loop (although it's very plausible -
> > so many things ARE different between architectures).
> > 
> > I'd like to document the assumption ("aligned pointer assignments
> > are atomic") as a comment in the code, with an
> > "authoritative as possible" source for this assertion.
> > Can anyone tell me WHERE they got that information, preferably
> > a very authoritative source?  Or at least, identify platforms
> > where they can be SURE it's true?
> > 
> > Conversely, can anyone (ESPECIALLY Greg KH!) tell me any
> > architecture this assumption is NOT true on, or where I could go
> > to find such?
> > 
> > Googling last night didn't really get me anywhere.
> > I could download every processor and bus spec, but that would
> > be a multi-year research project :-(.
> 
> Simple - it isn't true in any arch where the bus size is not equal to the
> pointer size (usually meaning "bus size is less than pointer size").
> 
> The VAX processor had quad sized data transfer, but a 32 bit
> pointer. Sometimes pointers would get hosed (usually for 64 bit pointer
> sets). I only read about problems when multiple CPUs were involved with shared
> memory (yet another size). alignment with one frame (32 bits) would not
> necessarily be aligned for cache transfer. The bus size on VAX arch varied
> from 16 bits to 64 bits, depending on the system.
> 
> I do agree that 99% of the current implementations ARE atomic at the
> "aligned" 32 bit level. However... newer systems are now doing 64, and
> 128 bit units, and this introduces potential "nonaligned" transfers that
> were not anticipated. I do wonder about the PDA bus though (and that IBM
> wrist watch computer).
> 
> I don't know of any system where this should be a problem at this time.
> -------------------------------------------------------------------------
> Jesse I Pollard, II
> Email: pollardat_private
> 
> Any opinions expressed are solely my own.
> _______________________________________________
> linux-security-module mailing list
> linux-security-moduleat_private
> http://mail.wirex.com/mailman/listinfo/linux-security-module
> 

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module