Stack clearing device and method

Details Stack clearing device and method Stack clearing device and method

2000-02-03

2003-04-15

Dam, Tuan Q. (Department: 2122)

Data processing: software development, installation, and managem

Software program development tool

Translation of code

C717S154000, C717S130000

Reexamination Certificate

active

06550058

ABSTRACT:

CROSS-REFERENCE TO RELATED APPLICATIONS (CLAIMING BENEFIT UNDER 35 U.S.C. 120)
None.
FEDERALLY SPONSORED RESEARCH AND DEVELOPMENT STATEMENT
This invention was not developed in conjunction with any Federally sponsored contract.
MICROFICHE APPENDIX
Not applicable.
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention pertains to the arts of computer program technologies, program execution methods, and multitask program management techniques. More particularly, this invention relates to program stack management for computer program operating systems and computer program compilers.
2. Description of the Related Art
A computer program process may “call” another process or subroutine to be executed on the same or by the same processor which is executing the “calling” process. When the “call” operation or instruction is executed, the execution of the “calling” process is halted at the point of the “call” instruction, and the “called” process or subroutine is initialized and executed.
In order to allow the “called” process or subroutine to fully utilize all or part of the processor's computing resources, including the processor's registers, and in order to preserve the context of the “calling” process, a program stack is used. A stack in a computer system is a data structure disposed in a computer-readable memory which dynamically stores variable and processor state information between process calls and returns.
The stack has a “first-in-last-out” (“FILO”) structure. As data is placed into it, or “pushed onto the stack”, older data is pushed further into the structure. As shown in
FIG. 1
, a processor (
1
) has a bi-directional data bus (
3
) to the stack memory (
2
). Often, the stack memory and bi-directional data bus is integrated into the processor microchip itself.
At the assembly language level, most processors have a “push” operation which will copy data from a processor register or memory location to the top of the stack, and will adjust the top-of-stack pointer appropriately. Conversely, a “pop” operation will copy data from the top of the stack into a processor register or memory location, and will adjust the top-of-stack pointer. Some processors implement the stack in an incrementing address fashion, such that “pushes” result in increases in the stack pointer value, and “pops” result in decreases in the stack pointer value. Other processors may take the opposite approach, but achieve identical functionality, including adding data to the bottom of the stack rather than the top of stack. These variations of conventions for stack handling and construction are well understood in the art.
When the processor executes a “call” operation, an automatic “push” of the contents of the program counter register is made, thereby storing the return address of the calling process on the stack. When the called operation or subroutine executes a “return” operation, an automatic “pop” of the top of the stack contents is made to the program counter, which restores the program counter to the return address of the calling process or routine.
When a function call is made from a high-level language (“HLL”), such as “C”, the compiler generates assembly language representing the higher-level statements in the HLL to implement the source code into assembly code. When a function or routine call includes arguments to be passed to and returned from the function or routine, the compiler injects not only the assembly “call” opcode into the assembly language, but also a block of code to store the argument values on the stack, as well. This block or sequence of assembly language instructions may include several “pushes”, or special write or store operations, to the stack. Also, in typical HLL compilers, the processor context may be stored on the stack as part of the function or subroutine call operation. The context of the processor typically includes volatile processor register values, such as interrupt control registers, indirect addressing registers and other control registers. A processor-specific example of a volatile register which is stored as part of the context save is the ECX register of an Intel x86 processor.
When a subroutine is initialized as the result of a “call” operation, it typically sets up a local stack frame for data variables which are local to the subroutine. These local variables are usually addressed by an offset from the beginning of the local stack frame, commonly stored in a “base” register, such as BP or EBP on an Intel x86 processor. In addition, sometimes temporary or transient values are stored on the stack dynamically within the subroutine, rather than including them as part of the local stack frame.
As shown in
FIG. 2
, if executing Process A (
20
) calls Process B, the return address and context of the processor for Process A is pushed (
21
) onto the stack, and the pointer for the top of the stack is moved to the “top” of the memory containing the Process A context data (
203
). Further, space is created on the “top” of the stack for Process B's local variables and the top of stack is adjusted (
204
). Execution of Process B then takes place (
22
), until Process B calls Process C. At this time, the processor pushes the processor context onto the stack for Process B's current state (
23
), and moves the top of stack pointer appropriately (
205
) then the top of stack is adjusted to make room for process C's local variables (
206
) to make room for Process C's local variables.
When Process C completes its execution, it will typically execute a “return” operation, which causes the processor to move the top of stack pointer down to Process B's area (
202
), and to “pop” or read the processor register values from the stack area for Process B (
25
). The register values are restored to B's state, and the software for Process B is resumed execution (
22
) from the point of the “call” operation in Process B's instruction code. When Process B completes its execution, a similar “return” operation is made, the top of stack pointer is moved downward (
202
), and the context for Process A is restored (
26
) so that Process A's execution (
20
) can resume and the point of the “call” instruction in Process A's code. This type of general stack operation is well known within the art.
It well known within the art that the stack can be implemented in computer memory in linear, contiguous memory space, or it may be implemented as a distributed linked list of sections of memory space, while still providing the same functionality as described supra. Additionally, some computer systems “push” data onto the stack in incrementing address values (which results in “pops” decreasing the address values), while other systems “push” data onto the stack in decrementing address values (and “pops” increase the address value). Further, systems which run operating systems may contain the stack management functionality in operating system modules in order to free the application software from stack management, which in simpler systems, stack management may be handled directly by the application software modules. These variations of the pointer management do not affect the FILO operation of the stack, and are merely alternate implementations of the same structure.
Upon closer examination of this type of stack management process, a potential operation and security problem is apparent. When an application starts execution, the memory used for the stack segment is typically initialized to all zeros. However, after some period of execution, there is stale or non-zero data on the unused portion of the stack Table 1 shows a example calling sequence to be used to illustrate the problem.
TABLE 1
Sample Calling Sequence
Proc A
Call Proc B(parms);
Call Proc C(parms);
Proc B
Call Proc C(parms);
Call Proc D(parms);
Proc C
Call Proc B(parms);
Call Proc D(parms);
Proc D
no calls;
In this example, if Proc A calls Proc B, which then calls Proc C, which then returns to Proc B, and which then returns to Proc A, there is stale information on the unused po

Affiliated with

Also associated with

Rating

Stack clearing device and method does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Stack clearing device and method, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Stack clearing device and method will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3080740