jss@sjuvax.UUCP (J. Shapiro) (12/18/85)
>>me: > Bob Mabee of Charles River Data Systems Concerning TLB entry invalidation: >>...Some other process goes and invalidates the page, >>and the consequent TLB flush will cause the TLB to be properly >>maintained. > >That isn't good enough. Reasonable systems may require invalidating a page >within one process, rather than whenever a page-scrounging daemon runs. >Consider exec, or suppose that sbrk is actually implemented to give back >memory. Also, if you have multiple processors there is not necessarily a >process exchange on this CPU every time the scrounger takes away a page. > Intel does not have a clear TLB instruction *or* pin, and as such, if one processor robs another of a page belonging to the running process you are in deep dip. If sbrk needs to allocate and validate a new page as existing, there is no problem. The problem is invalidating an old page. Since the 80386 provides no way to flush the TLB without doing a process exec, this isn't possible. Besides, on a real system one wants sbrk to be a priviledged system call, and doing a gateway call on the 80386 looks to me like it amounts to doing a process invocation, however temporarily. Exec is a system call - I certainly wouldn't want a nonpriviledged process to perform it. Similarly fork. Both of these calls require a swap out while we go set up the process table, because a secure system cannot assume that the process can be trusted to do it non-maliciously. Much of this, of course, does not apply in a system which assumes cooperating processes, but the 80386 architecture seems to encourage the protection notion. I got into trouble by drawing too sketchy a picture. -- Jonathan S. Shapiro Haverford College "It doesn't compile pseudo code... What do you expect for fifty dollars?" - M. Tiemann
kds@intelca.UUCP (Ken Shoemaker) (12/26/85)
> > Intel does not have a clear TLB instruction *or* pin, and as such, if > one processor robs another of a page belonging to the running process > you are in deep dip. If sbrk needs to allocate and validate a new > page as existing, there is no problem. The problem is invalidating an > old page. Since the 80386 provides no way to flush the TLB without > doing a process exec, this isn't possible. Besides, on a real system > Er, as I have said before, to flush the TLB, all one needs do is reload CR3, which is the page table base pointer. If you load it with the same value (which you can get, since it is also readable), then you have flushed the TLB without changing the address map. -- remember, if you do it yourself, sooner or later you'll need a bigger hammer Ken Shoemaker, Santa Clara, Ca. {pur-ee,hplabs,amd,scgvaxd,dual,qantel}!intelca!kds ---the above views are personal.
radzy@calma.UUCP (Tim Radzykewycz) (01/01/86)
In article <2659@sjuvax.UUCP> jss@sjuvax.UUCP (J. Shapiro) writes: >Intel does not have a clear TLB instruction *or* pin, and as such, if >one processor robs another of a page belonging to the running process >you are in deep dip. With a reasonable multi-processor design, whenever one processor runs the page scrounging demon, and it finds a page to scrounge, then that processor can cause a "special" interrupt on all of the processors. This would cause each of the other processors to perform a context switch, which would clear the TLB. The "special" interrupt wouldn't really do anything except cause the double context switch. This is a rather poor way of designing the system, because this method of invalidating a page is very costly, but at least it is possible to design a multi-processor system around the 286 if that is a design goal. >... Besides, on a real system >one wants sbrk to be a priviledged system call, .... >Exec is a system call - I certainly wouldn't want a nonpriviledged >process to perform it. Similarly fork. This is krock. It sounds to me like J. Shapiro doesn't want *any* process that isn't SUID ROOT to do *any* system call. Totally unrealistic. begin :-) mode Or maybe he means that if the process is "priviledged" to run on the system, it can do a system call. end :-) mode -- Tim (radzy) Radzykewycz, The Incredible Radical Cabbage. calma!radzy@ucbvax.ARPA {ucbvax,sun,csd-gould}!calma!radzy