Messages in this thread |  | | | Date | Mon, 27 Mar 2000 09:47:07 -0600 (CST) | | From | Jesse Pollard <> | | Subject | Re: Endless overcommit memory thread. |
| |
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/
|  |