Curtis Yarvin, Richard Bukowski, and Thomas Anderson. Anonymous RPC: Low-Latency Protection in a 64-Bit Address Space. In Proceedings of the Summer 1993.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....user code to execute inside the operating system kernel: the system needs to guard against excessive execution time, privileged instructions, exceptions and random memory references. There has been extensive work in the operating system and language communities that addresses the above problems [10, 23, 20, 7, 28]. FLAME leverages these techniques to satisfy our security needs. Bounding Execution Time. A simple method for bounding execution time is eliminating backward jumps [11, 18] This has the advantage of providing us with an upper bound for the execution time: linear in the length of the program. ....

Curtis Yarvin, Richard Bukowski, and Thomas Anderson. Anonymous rpc: Low-latency protection in a 64-bit address space. In Proceedings of 1993.

....by hiding relies on probabilistic, rather than absolute, protection guarantees. It does not assume separate virtual address spaces for each process, but rather a single global address space. Using a system quite similar to Anonymous RPC as originally proposed by Yarvin, Bukowski and Anderson [1], contiguous memory elements are randomly placed in the space. Any process can physically generate any address, but the sparseness of the space makes it essentially impossible to accidently or maliciously find an arbitrary region. For example, consider a 128 bit address space supporting a ....

Yarvin, Bukowski and Anderson. Anonymous RPC: Low-Latency Protection in a 64-bit Address Space. Proc. Summer USENIX Conference, 1993, pp. 175-186.

....reducing the number of such crossings [Bogle 94] Condict 94] The problem is projected to get worse as hardware optimizations such as pipelining and caching increase the cost of context switches. Some researchers have proposed hardware support [Carter 94] and new software constructs [Banerji 94] Yarvin 93] to decrease context switch overhead. Drush 93] came up with a cross domain data sharing scheme in order to reduce data transfer costs during domain crossings. In the recent past, several software alternatives to hardware based protection have been proposed. Software Fault Isolation, one such ....

....built as the service, so the number of invocations depends on the density of the primes. tdbm i, tdbm f, tdbm d Three benchmarks involve our tdbm database, a small in memory database based on the Berkeley UNIX ndbm library. It is a slight modification of the sdbm library released by Ozan Yigit [Yarvin 93] and is based on the 1978 dynamic hashing algorithm by Paul Larson [Enbody 88] The changes avoid unnecessary copying and remove file dependence. The tests involve insertion of N words from an extended version of usr dict words, random fetch of N 2 words, and deletion of N 2 words. For tdbm i, ....

C. Yarvin, et. al., Anonymous RPC: Low Latency Protection in a 64-bit Address Space, Proc. USENIX Summer Conference, USENIX, 1993.

....to guess the identifier. Even in the face of a distributed attack of say one millions of hosts, it will take about 127 20 = 2 107 probes per host to guess a private trigger. We note that the technique of using random identifiers as probabilistic secure capabilities was previously used in [28, 37]. Furthermore, end points can periodically change the private triggers associated with a flow. Another alternative would be for the receiver to associate multiple private triggers to the same flow, and the sender to send packets randomly to one of these private triggers. The alternative left to a ....

YARVIN, C., BUKOWSKI, R., AND ANDERSON, T. Anonymous rpc: Low-latency protection in a 64-bit address space. In Proc. of USENIX (June 1993), pp. 175--186.

....of the memory in a protection domain [7] Some capability systems meet the different and revoke requirements by performing an indirect lookup on each capability use [13, 29] which adds considerable run time overhead. Large sparse address spaces provide an opportunity for probabilistic protection [35], but this strategy violates the revoke and different requirement. Permissions Table PLB Domain ID Perm Table Base MEMORY lookup refill Sidecars Address Regs CPU Figure 2: The major components of the Mondrian memory protection system. On a memory reference, the processor checks ....

C. Yarvin, R. Bukowski, and T. Anderson. Anonymous RPC: Low-latency protection in a 64-bit address space. In USENIX Summer, pages 175--186, 1993.

....A B C A B C U U A B C K K A B C C C C A B C Figure 1: FLAME Architecture against excessive execution time, privileged instructions, exceptions and random memory references. There has been extensive work in the operating system and language communities that addresses the above problems (c.f. [25, 9, 31]) FLAME leverages these techniques to satisfy our security needs. Bounding Execution Time. A simple method for bounding execution time is eliminating backward jumps. This has the advantage of providing us with an upper bound for the execution time: linear in the length of the program. However, ....

C. Yarvin, R. Bukowski, and T. Anderson. Anonymous rpc: Low-latency protection in a 64-bit address space. In Proceedings of the 1993.

....user code to execute inside the operating system kernel: the system needs to guard against excessive execution time, privileged instructions, exceptions and random memory references. There has been extensive work in the operating system and language communities that addresses the above problems [10, 25, 21, 7, 30]. FLAME leverages these techniques to satisfy our security needs. Bounding Execution Time. A simple method for bounding execution time is eliminating backward jumps [11, 19] This has the advantage of providing us with an upper bound for the execution time: linear in the length of the program. ....

C. Yarvin, R. Bukowski, and T. Anderson. Anonymous rpc: Low-latency protection in a 64-bit address space. In Proceedings of

....user code to execute inside the operating system kernel. The system needs to guard against excessive execution time, privileged instructions, exceptions and random memory references. There has been extensive work in the operating system and language communities that addresses the above problems [17, 38, 30, 11, 44]. FLAME leverages these techniques to satisfy our security needs. Bounding Execution Time. A simple method for bounding execution time is eliminating backward jumps [21] This has the advantage of providing us with an upper bound for the execution time: linear to the length of the program. ....

Curtis Yarvin, Richard Bukowski, and Thomas Anderson. Anonymous rpc: Low-latency protection in a 64-bit address space. In Proceedings of 1993 Summer USENIX Conference, June 1993.

....techniques. Control of their address space layout allows applications to place sensitive state in arbitrary locations. This technique can be used for improved fault isolation by reducing the chance that a write or read can access this state; in a sense, the virtual address is a capability [24]. Such control can be used to allow applications to safely import untrusted code (or to guard against their own buggy algorithms) More efficient dynamic fault isolation. Since context identifiers are available to AVM systems, applications can create light weight fault isolation domains within ....

C. Yarvin, R. Bukowski, and T. Anderson. Anonymous RPC: Low-latency protection in a 64-bit address space. In Proceedings of the Summer 1993 USENIX Conference, June 1993.

....invoked saves the processor state and regenerates the function with the new CFG path. This is slow but may be valuable for frequently executed routines, because it converges on optimal code. For extremely large or offset jump tables we need to place the jump table in an anonymous section of memory [YBA93] and regenerate on page faults; this may require OS support. 3.4 Restoring Function Call Information QuaC s analysis is intraprocedural. We need to be able to recognize function calls and work around them. To do this we require that the code we analyze follow an Algol style function model, with ....

Curtis Yarvin, Richard Bukowski, and Thomas Anderson. Anonymous RPC: Low-Latency Protection in a 64-Bit Address Space. In Proceedings of the 1993 Summer USENIX Conference, 1993.

....to be unified with primary storage and remove the need for pointer swizzling. Security and protection are a major problem with single address space systems, and current approaches either rely on hardware assistance (Opal and Mungi [204] software capabilities (Arias) or probabilistic algorithms [214]. SHARING DATA IN DISTRIBUTED SYSTEMS 2.3.3.2 Separate shared address spaces Another approach is to divide each process s address space into different fixed regions, some of which are private and not shared, and some of which are shared with some other processes. Ra, the Clouds kernel [22] ....

Curtis Yarvin, Richard Bukowski, and Thomas Anderson. Anonymous RPC: LowLatency Protection in a 64-Bit Address Space. In Proceedings of the USENIX Summer Technical Conference, pages 175--186, Cincinnati, Ohio, June 1993. USENIX Association.

....to be unified with primary storage and remove the need for pointer swizzling. Security and protection are a major problem with single address space systems, and current approaches either rely on hardware assistance (Opal and Mungi [196] software capabilities (Arias) or probabilistic algorithms [204]. 3.3.2 Separate shared address spaces Another approach is to divide each process s address space into different fixed regions, some of which are private and not shared, and some of which are shared with some other processes. Ra, the Clouds kernel [21] takes this approach using O, P , and K ....

Curtis Yarvin, Richard Bukowski, and Thomas Anderson. Anonymous RPC: Low-Latency Protection in a 64-Bit Address Space. In Proceedings of the USENIX Summer Technical Conference, pages 175--186, Cincinnati, Ohio, June 1993. USENIX Association.

....92] suggests MMU hardware that uses the current value of the PC to determine memory access permissions. Druschel Peterson 92] points out that shared segments can be protected from accidental error and even malicious use by hiding them in the large address space. This idea is generalized in [Yarvin et al. 93] to allow an untrusted thread to operate on protected data with intra domain anonymous protected calls (ARPC) at lower cost than RPC calls across a hardware enforced protection boundary. ARPC and the Opal model are complementary, if Opal s implementation assigns segment addresses randomly (our ....

Yarvin, C., Bukowski, R., and Anderson, T. Anonymous RPC: Low latency protection in a 64-bit address space. In Proceedings of the Summer USENIX Conference, June 1993.

....from the global pointer (GP) register. This has certain advantages: it is efficient, the static data can be addressed from multiple domains, and one domain can even maintain multiple instances of the data, e.g. to execute multiple disjoint processes in the same hardware protection domain [Yarvin et al. 93] However, each domain in our prototype can attach only one application module that defines private static data, because of the difficulty of coordinating the GP offsets. 2) It can increase the cost of making a private copy of shared data. In our prototype, initial values for a code segment s ....

Yarvin, C., Bukowski, R., and Anderson, T. Anonymous RPC: Low latency protection in a 64-bit address space. In Proceedings of the Summer USENIX Conference, June 1993.

....The client will only be granted service if the server accepts the check field in the sparse capability. Arguments and results for the call can be passed through data segments shared between the client and the server. 3. 3 Anonymous RPC Protection in Anonymous RPC, developed by Yarvin et al. [24], is based on the very small probability of finding a mapped segment because segment ranges are assigned or loaded at random. High efficiency is obtained because all applications are executed in the same protection domain, so no context switching is needed to make an RPC. When a client and a ....

Curtis Yarvin, Richerd Bukowski, and Thomas Anderson. Anonymous RPC: Low-latency protection in a 64bit address space. In Proc. of the 1993 Summer Usenix Conference, Cincinnatti, June 1993. To appear.

....Web developments, addresses the latter issues and can be adapted to ODBMS needs. For the remainder, servers need assurances that clients cannot bypass server mandated access control policies once the data reaches the client. To guard against disclosure even to superusers, several research projects [CLFL94, YBA] are investigating hardware and operating system level security measures for providing enhanced protection with small performance penalties. Given such low level support, client applications can be prevented from accidentally or maliciously violating the access control policy by encapsulating the ....

Curtis Yarvin, Richard Bukowski, and Thomas Anderson. Anonymous RPC: Low-latency protection in a 64-bit address space. Technical report, University of California at Berkeley.

....code. Our approach allows code written in any programming language to be safely encapsulated (or rejected if it is not safe) and then executed at near full speed by the operating system. Anonymous RPC exploits 64 bit address spaces to provide low latency RPC and probabilistic fault isolation [YBA93] Logically independent domains are placed at random locations in the same hardware address space. Calls between domains are anonymous, that is, they do not reveal the location of the caller or the callee to either side. This provides probabilistic protection it is unlikely that any domain ....

Curtis Yarvin, Richard Bukowski, and Thomas Anderson. Anonymous RPC: Low Latency Protection in a 64-Bit Address Space. In Proceedings of the Summer USENIX Conference, June 1993.

No context found.

Curtis Yarvin, Richard Bukowski, and Thomas Anderson. Anonymous RPC: Low-Latency Protection in a 64-Bit Address Space. In Proceedings of the Summer 1993.

No context found.

Curtis Yarvin, Richard Bukowski, and Thomas Anderson. Anonymous rpc: Lowlatency protection in a 64-bit address space. In Proceedings of 1993 Summer USENIX Conference, June 1993. Appendix A - Module code Packet train module code: { struct ip *iphdr = (struct ip *) (pkt + 14); static struct in_addr tr_src, tr_dst; if ((iphdr->ip_src.s_addr == tr_src.s_addr) &&

No context found.

Curtis Yarvin, Richard Bukowski, and Thomas Anderson. Anonymous RPC: Lowlatency protection in a 64-bit address space. In Proceedings of the 1993 Summer USENIX Conference, June 1993.

No context found.

YARVIN, C., BUKOWSKI, R., AND ANDERSON, T. Anonymous rpc: Low-latency protection in a 64-bit address space. In Proc. of USENIX (June 1993), pp. 175--186.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC