Method and system usable in sensor networks for handling memory faults

• US 20070156951A1
• Filed: 12/26/2006
• Published: 07/05/2007
• Est. Priority Date: 01/03/2006
• Status: Active Grant

• Current Assignee: NEC Corporation
• Original Assignee: NEC Laboratories America Inc (NEC Corporation)
• Inventors: Nagaraja, Kiran, Chakradhar, Srimat, Sultan, Florin, Rengaswamy, Ram
• Granted Patent: US 7,581,142 B2
• Time in Patent Office: Days
• US Class Current: 711/103
• CPC Class Codes: G06F 11/1044 with specific ECC/EDC distribution
• CPC Class Codes: G06F 11/1438 Restarting or rejuvenating

Abstract

A method and system usable in sensor networks for handling memory faults is disclosed. In order to protect the operating system of a sensor node, coarse-grained memory protection is provided by creating and enforcing an application fault domain in the data memory address space of the sensor node. The data memory accessed by the application modules is restricted to the region (which defines the application fault domain) within the data memory address space. The application modules are prevented from accessing memory outside the application fault domain through software-based run-time checks. The state belonging to the operations system is maintained outside of the application fault domain, and is thus protected from memory corruption from any application module. In order to ensure that an application module does not operate on a corrupted state, fine-grained error detection and recovery is provided within the application fault domain. Any corruption of memory within the application fault domain is detected by a run-time memory integrity verifier implemented in the operating system kernel. Recovery involves purging the corrupted state and restarting only the affected application module to operate on an uncorrupted state.

Claims

1. A method comprising:

executing multiple application modules which access memory in a single memory address space;

prior to a memory access to an application state by an application module, detecting whether the state of the application module is corrupted; and

when the state of the application module is corrupted, micro-rebooting the application module.

2. The method of claim 1, further comprising:

when the state of the application module is not corrupted, permitting the memory access by the application module.

3. The method of claim 1, wherein said step of detecting whether a state of the application module is corrupted is performed prior to execution of the application module.

4. The method of claim 1, wherein each of the application modules is allocated at least one block of memory in said single data memory space, and said step of detecting whether a state of the application module is corrupted comprises:

calculating a memory integrity code (MIC) for the at least one block of memory allocated to the application module as a function of content stored in the at least one block of memory allocated to the application module;

comparing the calculated MIC with a stored MIC for the at least one block of memory allocated to the application module;

when the calculated MIC is identical to the stored MIC for the at least one block of memory allocated to the application module, determining that the state of the application module is not corrupted; and

when the calculated MIC is not identical to the stored MIC for the at least one block of memory allocated to the application module, determining that the state of the application module is corrupted.

5. The method of claim 4, wherein said step of calculating a memory integrity code (MIC) comprises:

calculating said MIC using a checksum function.

6. The method of claim 4, further comprising:

when the state of the application module is not corrupted, permitting the application module to access the at least one block of memory allocated to the application module up to completion of a current execution of the application module, recalculating the MIC for the at least one block of memory allocated to the application module immediately after the execution of the application module, and replacing the stored MIC for the at least one block of memory allocated to the application module with the recalculated MIC for the at least one block of memory allocated to the application module.

7. The method of claim 1, wherein said step of micro-rebooting the application module having the corrupted state comprises:

restarting the application module and restoring the state of the application module to an uncorrupted state.

8. The method of claim 1, wherein said step of micro-rebooting the application module having the corrupted state comprises:

unloading the application module; and

reloading the application module.

9. The method of claim 1, further comprising:

preventing the application modules from writing to memory locations outside of an application fault domain defined within said single data memory space;

maintaining a state of an operating system kernel in a portion of said single data memory space outside of said application fault domain.

10. The method of claim 9, further comprising:

dynamically allocating memory locations associated with program modules to a first range of contiguous memory addresses and memory locations associated with an operating system kernel to a second range of contiguous memory addresses, wherein said first and second ranges of contiguous memory addresses do not overlap; and

defining said first range of contiguous memory addresses as said application fault domain.

11. The method of claim 10, wherein said step of preventing the application modules from writing to memory locations outside of an application fault domain comprises:

tracking boundaries of said first range of memory addresses;

comparing a target memory address of an application module with said boundaries of said first range of memory addresses;

when the target memory address is within said boundaries of said first range of memory addresses, permitting the application module to write to the target memory address; and

when the target memory address is not within said boundaries of said first range of memory addresses, preventing the application module from writing to the target memory address.

12. The method of claim 1, further comprising:

when the state of the application module is corrupted, identifying one or more suspect application modules suspected of corrupting the state of the application module.

13. A computer readable medium storing computer program instructions for handling memory faults, said computer program instructions defining the steps comprising:

executing multiple application modules which access memory in a single memory address space;

prior to a memory access to an application state by an application module, detecting whether the state of the application module is corrupted; and

when the state of the application module is corrupted, micro-rebooting the application module.

14. The computer readable medium of claim 13, wherein the computer program instructions defining the step of detecting whether a state of the application module is corrupted comprise computer program instructions defining the step of:

detecting whether a state of the application module is corrupted prior to execution of the application module.

15. The computer readable medium of claim 13, wherein each of the application modules is allocated at least one block of memory in said single data memory space, and the computer program instructions defining the step of detecting whether a state of the application module is corrupted comprise computer program instructions defining the steps of:

calculating a memory integrity code (MIC) for the at least one block of memory allocated to the application module as a function of content stored in the at least one block of memory allocated to the application module;

comparing the calculated MIC with a stored MIC for the at least one block of memory allocated to the application module;

when the calculated MIC is identical to the stored MIC for the at least one block of memory allocated to the application module, determining that the state of the application module is not corrupted; and

when the calculated MIC is not identical to the stored MIC for the at least one block of memory allocated to the application module, determining that the state of the application module is corrupted.

16. The computer readable medium of claim 15, wherein the computer program instructions defining the step of calculating a memory integrity code (MIC) comprise computer program instructions defining the step of:

calculating said MIC using a checksum function.

17. The computer readable medium of claim 15, further comprising computer program instructions defining the step of:

when the state of the application module is not corrupted, permitting the application module to access the at least one block of memory allocated to the application module up to completion of a current execution of the application module, recalculating the MIC for the at least one block of memory allocated to the application module immediately after the execution of the application module, and replacing the stored MIC for the at least one block of memory allocated to the application module with the recalculated MIC for the at least one block of memory allocated to the application module.

18. The computer readable medium of claim 13, wherein the computer program instructions defining the step of micro-rebooting the application module having the corrupted state comprise computer program instructions defining the step of:

restarting the application module and restoring the state of the application module to an uncorrupted state.

19. The computer readable medium of claim 13, wherein the computer program instructions defining the step of micro-rebooting the application module having the corrupted state comprise computer program instructions defining the steps of:

unloading the application module; and

reloading the application module.

20. The computer readable medium of claim 13, further comprising computer program instructions defining the steps of:

preventing the application modules from writing to memory locations outside of an application fault domain defined within said single data memory space;

maintaining a state of an operation system kernel in a portion of said single data memory space outside of said application fault domain.

21. The computer readable medium of claim 20, further comprising computer program instructions defining the steps of:

dynamically allocating memory locations associated with program modules to a first range of contiguous memory addresses and memory locations associated with an operating system kernel to a second range of contiguous memory addresses, wherein said first and second ranges of contiguous memory addresses do not overlap; and

defining said first range of contiguous memory addresses as said application fault domain.

22. The computer readable medium of claim 21, wherein the computer program instructions defining the step of preventing the application modules from writing to memory locations outside of an application fault domain comprise computer program instructions defining the steps of:

tracking boundaries of said first range of memory addresses;

comparing a target memory address of an application module with said boundaries of said first range of memory addresses;

when the target memory address is within said boundaries of said first range of memory addresses, permitting the application module to write to the target memory address; and

when the target memory address is not within said boundaries of said first range of memory addresses, preventing the application module from writing to the target memory address.

23. The computer readable medium of claim 13, wherein the computer program instructions are implemented in an operating system kernel installed on a sensor node.

24. The computer readable medium of claim 23, wherein said operating system comprises Sensor Operating System (SOS).

25. The computer readable medium of claim 13, further comprising computer program instructions defining the step of:

when the state of the application module is corrupted, identifying one or more suspect application modules suspected of corrupting the state of the application module.

26. An apparatus, comprising:

means for executing multiple application modules which access memory in a single data memory space;

means for detecting whether a state of an application module is corrupted prior to a memory access of the state by the application module; and

means for micro-rebooting the application module in response to a detection of a corrupted state.

27. The apparatus of claim 26, wherein each of the application modules is allocated at least one block of memory in said single data memory space, and said means for detecting whether a state of an application module to be executed is corrupted by another application module comprises:

means for calculating a memory integrity code (MIC) for the at least one block of memory allocated to the application module as a function of content stored in the at least one block of memory allocated to the application module; and

means for comparing the calculated MIC with a stored MIC for the at least one block of memory allocated to the application module.

28. The apparatus of claim 26, wherein said means for micro-rebooting the application module comprises:

means for restarting the application module and restoring the state of the application module to an uncorrupted state.

29. The apparatus of claim 26, wherein said means for micro-rebooting the application module comprises:

means for unloading the application module; and

means for reloading the application module.

30. The apparatus of claim 26, further comprising:

means for preventing the application modules from writing to memory locations outside of an application fault domain defined within said single data memory space;

means for maintaining a state of an operation system kernel in a portion of said single data memory space outside of said application fault domain.

31. The apparatus of claim 26, further comprising:

means for dynamically allocating memory locations associated with program modules to a first range of contiguous memory addresses and memory locations associated with an operating system kernel to a second range of contiguous memory addresses, wherein said first and second ranges of contiguous memory addresses do not overlap; and

means for defining said first range of contiguous memory addresses as said application fault domain.