Patent Application
20070283113
The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein:
Like reference numerals are used to designate like parts in the accompanying drawings.
The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present example may be constructed or utilized. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.
Client device 105 may represent at least one of a variety of known computing devices, including a desktop personal computer (PC), workstation, mainframe computer, Internet appliance, set-top box, or gaming console, that is able to implement example technologies for a safe buffer. Client device 105 may further represent at least one device that is capable of being associated with network 125 by a wired and/or wireless link, including but not limited to a mobile telephone, personal digital assistant (PDA), and laptop computer. Further still, client device 105 may represent the client devices described above in various quantities and/or combinations thereof. “Other” device 115 may also be embodied by any of the above examples of client device 105.
Server device 110 may represent any device that is capable of providing any of a variety of data and/or functionality to client device 105 or “other” device 115 in accordance with at least one implementation for a safe buffer. The data may be publicly available or alternatively restricted, e.g., restricted to only certain users or only if an appropriate subscription or licensing fee is paid. Server device 110 may be at least one of a network server, an application server, a blade server, or any combination thereof. Typically, server device 110 may represent any device that may be a content source, and client device 105 may represent any device that may receive such content either via network 125 or in an off-line manner. However, according to the example implementations described herein, client device 105 and server device 110 may interchangeably be a sending node or a receiving node in network environment 100. “Other” device 115 may also be embodied by any of the above examples of server device 110.
“Other” device 115 may represent any further device that is capable of a safe buffer implementation 120 according to one or more of the example technologies described herein. These examples are not intended to be limiting in any way, and therefore should not be construed in that manner.
Network 125 may represent any of a variety of conventional network topologies and types, which may include wired and/or wireless networks. Network 125 may further utilize any of a variety of conventional network protocols, including public and/or proprietary protocols. Network 125 may include, for example, the Internet as well at least portions of one or more local area networks (LANs), such as an 802.11 system or, on a larger scale, a wide area network (WAN), or a personal area network (PAN), such as Bluetooth.
Computer architecture in at least one of devices 105, 110, and 115 has typically defined computing platforms in terms of hardware and software. Software for computing devices has been categorized into groups, based on function, which may include: a hardware abstraction layer (HAL), an operating system (OS), and applications.
A runtime execution environment may reside between an OS and an application, program, function, or other assemblage of code. The runtime execution environment may serve as a space in which the application, program, function, or other assemblage of code may execute specific tasks on any one or more of processing devices 105, 110, and 115. More particularly, a runtime execution environment may enhance the reliability of the execution of an application, program, function, or other assemblage of code on a growing range of processing devices 105, 110, and 105, including servers, desktop computers, laptop computers, and mobile processing/communication devices by providing a layer of abstraction and services for an application running on such devices, and by further providing the application, program, function, or other assemblage of code with capabilities including memory management and configuration thereof.
A runtime execution environment may serve as at least one of a programming and an execution platform. As a programming platform, a runtime execution environment may compile one or more targeted applications, programs, functions, or other assemblages of code, which may be written in one of multiple computing languages, into an intermediate language (IL) or bytecode. IL is typically independent of the platform, and the central processing unit (CPU) executes IL. In fact, IL is a higher level language than many CPU machine languages.
As an execution platform, a runtime execution environment may interpret compiled IL into native machine instructions. A runtime execution environment may utilize either an interpreter or a compiler to execute such instructions. Regardless, the native machine instructions may then be directly executed by the CPU. Since IL is CPU-independent, IL may execute on any CPU platform as long as the OS running on that CPU platform hosts an appropriate runtime execution environment.
Alternatively, at least portions of applications, programs, functions, or other assemblages of code may be precompiled and loaded as one or more native image files in the runtime execution environment, thus circumventing CPU consumption required for compilation. Effectively, the precompiled portions are software modules that are distributed in an IL format (e.g. assemblies, methods, or types) rather than in a native platform execution format. A source of such precompiled IL may be disposed in either of a non-managed execution environment or a separate implementation of a runtime execution environment on a same or separate one of devices 105, 110, and 115. The source may deploy the precompiled IL during or before install time for the application, program, method, function, or other assemblage of code to which the precompiled IL corresponds.
Regardless, examples of runtime environments, in which technologies for a safe buffer may be implemented, include: Visual Basic runtime environment; Java® Virtual Machine runtime environment that is used to run, e.g., Java® routines; or Common Language Runtime (CLR) to compile, e.g., Microsoft NET™ applications into machine language before executing a calling routine. However, this listing of runtime environments provides examples only. The example technologies described herein are not limited to just these managed execution environments. More particularly, the example implementations are not just limited to managed execution environments, for one or more examples may be implemented within testing environments and/or unmanaged execution environments.
An application, program, function, or other assemblage of code compiled into IL may be referred to as “managed code,” and that is why a runtime execution environment may be alternatively referred to as a “managed execution environment.” It is noted that code that does not utilize a runtime execution environment to execute may be referred to as a native code application.
Problems with accessing freed memory may occur when a write to a memory location occurs while the memory location is being freed. For example, a set function may be called to write a character to a memory location while a dispose function is being called to free the memory location. In this case, the write is being attempted at a memory location that may no longer be valid. In the presence of multiple threads, sometimes this memory location may be allocated by another thread, so the attempt to write to this location succeeds, even though the memory is not being used for its original purpose. Tracking down memory corruption in a multithreaded environment is often quite challenging.
In another example, consider the CLR, which enables interaction of managed code with unmanaged code. In this environment, unmanaged code (such as the Microsoftφ Windows® kernel) typically serves as a handle administrator, and therefore interacts with managed code to utilize resources. More particularly, a handle that is detected by the handle administrator as not being used, even though the handle is tentatively released or otherwise suspended, may be closed, disposed, or subjected to some other finalizing method for the purpose of memory management or resource recycling. For example, in the Microsoft® .NET platform, the managed method of “garbage collection” aggressively cleans up unused objects to reclaim memory. However, if garbage collection occurs prematurely on a type containing a handle and that type provides a finalizer that releases a memory source, the resource would be prematurely finalized (or disposed), and another thread could be attempting to write to an invalid memory location.
Garbage collection typically involves both a step to detect unused objects and a second pass called finalization, where some unused objects are given a chance to run their own cleanup code to free another resource. It is possible for malicious code to “resurrect” an object that garbage collection determined was unused, which causes an object that was previously considered “dead” available for future use or coming back to “life.” This “resurrection” may occur concurrently with running a finalizer and can be used to expose an object that is still usable, or one whose finalizer has completed, or one whose finalizer will run while you are manipulating the object. Depending on the type of resurrected object, this may open the door to correctness and/or security problems.
To solve these problems, safe buffer 200 is a handle to a protected memory resource that exploits methods to read and write to memory that ensure that reads and writes are to valid memory locations within buffer bounds.
An exemplary code implementation using the safe buffer class may be as follows:
Users may subclass the buffer class to provide an implementation of a safe resource wrapper for a resource. The example above presupposes a subclass of a safe buffer class, specialized for a particular string representation called a BSTR. The buffer class includes a length, which may be used to ensure that accesses do not exceed the length of the buffer. The Set function calls Write( ) to write the character to the proper memory location. The Dispose function may call a Virtual Free function to free the memory location if the memory location is not currently being accessed. The reference counter 215 may be used to determine whether to allow access to the memory resource and to ensure that the protected memory resource is not freed as it is being accessed. While the reference counter 215 is typically used within the safe buffer's memory management methods 220, it may optionally be made available to users directly to allow multiple accesses to memory to amortize the overhead of using the reference counter 215.
By implementing a safe resource wrapper for a memory resource, reads and writes to the memory resource may be performed in a safe manner. The safe buffer class may also serve as a building block for static analysis and verification.
At 310, a safe buffer object is created. For example, a runtime environment may recognize the need to create an instance of a subclass of a safe buffer. A safe buffer may be created for a runtime agent requiring a handle to access a resource upon which an operation is to be performed. Some runtime agents may create the safe buffer object before creating the underlying resource. At 320, a resource is created and a wrapper is wrapped around the resource. The wrapper may include memory management methods to ensure that accesses to memory are performed in a safe manner. The wrapper may include a counter that is set to one upon creation of the safe buffer object and decremented when the safe buffer object is disposed, such as through a finalizer or a dispose method.
At 330, a request is received to access the memory resource. At 340, a determination is made as to whether to allow access to the resource based at least in part on the value of the counter. For example, if the value of the counter is zero, this may indicate that the resource has been freed, so at 345, access may be denied. Access may be denied by throwing an exception, reporting an error, or via various other methods. Additionally, if the length of the safe buffer is tracked, then invalid accesses that exceed the length of the buffer may also be denied at 340.
If the value of the counter is greater than zero, then this may indicate that the resource may be safely accessed, so access may be allowed. At 350, the value of the counter is incremented, indicating that a thread is actively using the safe buffer's resource. Then, at 360, the resource may be accessed. After accessing the resource, at 370, the counter is decremented to indicate that one less thread is using the safe buffer. Separately, at 365, when the safe buffer is disposed, such as through a finalizer or a dispose method, then the counter is also decremented at 370.
At 380, the value of counter is checked to determine if it is zero. If the counter is nonzero, this may indicate that one or more threads are still using the safe buffer, so at 385, the resource is not freed. If the counter is zero, then this may indicate that no threads are currently using the safe buffer, and the safe buffer has been disposed, so the resource is freed at 390. By ensuring the resource is only freed when no other threads are using it in a thread-safe fashion, corruption problems due to malicious abuse of the resource, resurrection, or imperfect programming practices are prevented.
The above is one example of a process for implementing a safe buffer. It is understood that in other implementations, various other steps and runtime checks may be implemented to ensure safe accesses to memory.
For instance, in one alternative, the counter may represent the number of threads accessing the resource. When the counter is zero, this may indicate that no threads are accessing the resource. Therefore, access to the resource may be allowed. If the counter is nonzero, this may indicate that one or more threads are accessing the resource and the current request for access to the resource may be denied or postponed until another thread decrements the counter to zero. The decision to release the resource may be made based on the value of the counter and either additional state in the object or the lifetime of the safe buffer object. Various other implementations may also be used.
While the invention has been described in terms of several exemplary implementations, those of ordinary skill in the art will recognize that the invention is not limited to the implementations described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative instead of limiting.
