With a little word wrap readability edits...
grendel@vip.net.pl (Grendel)
> ** On Mar 27, Linda Walsh scribbled:
>> Grendel wrote:
>>> The clearance levels can be equivalent to the process privilege levels -
>>> in respect to memory usage - so that the processes of the most privileged
>>> users can be ruled out of the 'kill on OOM' pool - simply marked "non
>>> killable".
>> ---
>> Problem comes when you have two sensitivity labels that are not
>> able to be hierarchically compared. They may be at equal sensitivity
>> levels but may be in disparate categories that have no ordering -- like
>> say, you have the "Harvard University" category and the "Yale University"
>> category that have no intrinsic comparable value (other than of the
>> attendees or proponents of such :-)). They both have the same sensitivity
>> level (say "Faculty" vs. say "Undergrad"). But kernel can't determine a
>> hierarchy for the categories.
> Yup, that's definitely a problem. And one that probably requires human
> intervention, or a temporary and arbitrary shuffling of priorities within
> the same group when the system detects such situation. Somebody earlier
> mentioned that in such situation IRIX goes to a deadlock - is it a sensible
> behavior?
The deadlock mentioned is usually cleared by memory scheduling activity
among batch/interactive jobs. I have seen it under UNICOS, but I don't know
if it is available under IRIX.
>>> In a word the processes are guaranteed not to be killed in such situation.
>>> If the compartmented mode is to be completely secure, the machine should
>>> use separate _hardware_ for every clearance level, or guaranteed
>>> separation of VMs, am I correct?
>> ---
>> Separate hardware may be the ideal. It might be that researchers
>> at Harvard and Yale might both wish to have a 256P machine, but the
>> reality is that both schools might not be able to afford such a machine
>> and but might be able to 'copurchase' such a machine but still want secure
>> separation for their research. Covert channels as referred to by Alan C.
>> and Jesse P. may have acceptably low bit rates (say <10 bits/second) if what
>> they are working on are Gigabit datasets. Obviously, we'd like to know
>> what covert channels are possible and what the maximum bit rate of each
>> is, so Harvard and Yale can decide if those are acceptable. Their
>> requirements might be different than say if Caltech U. and Stanford U. were
>> to share a machine.
> Now that I think about it, the compartmented mode on our average PC is quite
> improbable :)), but with a cluster of PCs it can be quite possible to do and
> very flexible. But what if the Linux kernel supported full virtualization of
> all of its sharable resources? That is, it would create full VMs with
> virtual network cards, CPUs, pure virtual memory, block devices?
If it is valid in a cluster it must also be valid in the node that controls
the cluster. On each node in the cluster it must be valid, although only
3 levels might be active at one time:
SYSHIGH and SYSLOW are always present - the user level might be different
at different times, but a node could be dedicated to that level, and
most likely that user for the duration of the job. This would lead to
more efficent execution on a per-node basis.
The control node must support all levels: I assume that this is also the
one to do the accounting, job start, load balancing...).
I would like to have a trusted system so that I can communicate with other
systems at a trusted level. I'm not holding my breath yet:)
I think the "full VMs with virtual network cards, CPUs, pure virtual memory,
block devices" is overkill. A full MLS kernel includes IPSec for network
security, and uses the ESP (extented security packet) information to
carry the security labels.
>>> Combining the clearance levels, appropriate capabilities (as you
>>> proposed before) and memory access priorities could guarantee that
>>> mr. President won't run out of memory :)
>> ---
>> Ok, zap forward to future. US and Euro countries decide to band
>> together to buy a 256GP machine -- to predict the weather, among other
>> things.
>> Now we have incomparable entities (unless you want to start a squabble).
>> Mr. Pres is at the same priority level as other country leaders, but is
>> 'incomparable' to them. We can't prioritize memory within that group. If
> Not automatically, no.
Why not? Most systems give interactive jobs a higher scheduling priority
than batch jobs, why shouldn't memory scheduling be done too. This is what
usually breaks memory deadlocks anyway.
>> there ia memory shortage, Mr. Prez can lobby congress and the other Euro
>> nations for more memory on the 256Giga-processor machine. But he won't
>> be running along and have his vi session killed out from under him (though
>> the concept is a bit amusing...:-)).
> Heh :)))), yeah - that's a bit of a comedy :)). But, what if the Mr. Prez's
> process isn't killed but simply put on hold and Mr. Prez sees a nice cute
> box popping up on his screen saying "We're sorry - a temporary shortage of
> memory caused your process to stop. Please wait patiently." The process is
> put on the wait queue until the memory becomes available. To prevent
> starvation, the system should be preemptive, of course. The processes in
> separate priority groups would be serviced in parallel mode until memory
> comes short, then the higher priorities win of course. The processes in the
> same priority group would have to be serialized for the access to memory if
> the need arises. How about that scenario? No killing, some patience
> sometimes :))
Entirely acceptable by me.
-------------------------------------------------------------------------
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:22 EST