Re: Endless overcommit memory thread.

From: Jesse Pollard (pollard@tomcat.admin.navo.hpc.mil)
Date: Mon Mar 27 2000 - 10:47:07 EST


Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > >a single fixed memory pool on a compartmented mode system or processes can
> > >signal across the security boundary using out of memory as indications.
> >
> > Only on overcommited systems.
>
> Wrong. Think about it
>
> > Not really.. all it takes is a guaranteed memory allocation. No overcommitting
> > memory. Thats the way it works with UNICOS, and I believe that is the same
> > for trusted HP/UX and trusted Solaris. I have seen it with trusted IRIX.
>
> If that is the case and there is no other checking then I think they all need
> stripping of their security level. Guaranteed memory allocation makes the
> signalling easier
>
> I malloc 160Mb and see if it failed. If it failed then the big batch job in
> the other compartment is running which means the battle sim is running.

The only time it would fail is if you exceeded your memory quota. Not because
someone else is using memory. If login limits are also used then you would not
have been able to login to start a measure (also applies to cron/batch).

> The failed allocation gave me information about another compartment.

Went through this during UNICOS MLS class -
1) An allocation can only fail if it is over the users quota, therefore no
   information other than "over quota".
2) If you are not over quota and you fail then the system is overcommitted.
   (This is where UNICOS allows a deadlock rather than allow the abort, I think
   IRIX does the same, but I haven't worked with trusted IRIX enough to know)
3) A covert channel only exists if there are a limited number of processes
   active in the overcommitted system and some of those processes are at an
   elevated security level. After that, the noise level rises reducing the
   bit transfer rate to something that has been considered acceptable and is
   monitored ("considered accptable" is defined by local management).

#1 is the key to eliminating the covert channel.
#2 allows the covert channel, but allowing deadlock of all lower security
   level processes eliminates all information but "somthing ran".
#3 is the covert channel you are referring to, and the noise level rises
   rapidly as the total number of processes exceeds 30-50.

BTW, there are more covert channels (and faster ones too) than memory signals -
Process counts
CPU load - this is a really hard one to close.
I/O rates - only closed by not allowing the rates to be visible
network bandwith
Batch job counts
context switching rates
disk capacity/file sizes/access times

Have I overlooked something?

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:19 EST