Code and thread differential addressing via multiplex page maps

• US 7,073,173 B1
• Filed: 07/26/2001
• Issued: 07/04/2006
• Est. Priority Date: 12/04/2000
• Status: Expired due to Fees

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Willman, Bryan M.
• Primary Examiner(s): An, Meng-Al T.
• Assistant Examiner(s): Tang, Kenneth
• Application Number:
  US09/915,628
• Time in Patent Office: 1,804 Days
• Field of Search: 718/1, 718100-108, 711/2, 711/6
• US Class Current: 718/1
• CPC Class Codes: G06F 12/0284 Multiple user address space allocation, e.g. using different base addresses interprocessor communication G06F15/163
• CPC Class Codes: G06F 12/145 the protection being virtual, e.g. for virtual blocks or segments before a translation mechanism
• CPC Class Codes: G06F 12/1491 in a hierarchical protection system, e.g. privilege levels, memory rings
• CPC Class Codes: G06F 9/468 Specific access rights for resources, e.g. using capability register

Abstract

Described is a system and method whereby processes may have multiple memory maps associated therewith to provide curtained memory and overcome other memory-related problems. Multiple maps are used to restrict memory access of existing code such as drivers, without changing that code, and without changing existing microprocessors. A thread of a process is associated with one memory map at a time, which by mapping to different memory locations, provides memory isolation without requiring a process switch. Memory isolation may be combined with controlled, closed memory map switching performed only by trusted code, to ensure that some protected memory is inaccessible to all but the trusted code (curtained memory). Map switching among multiple maps eliminates the need to change a process in order to access different memory, thereby allowing expanded memory addressing in a single process and isolating untrusted code run in process from certain memory of that process.

Claims

1. In a computer-system, a method comprising:

receiving a request via a process thread having a first memory map associated therewith;

changing a privilege level to a level that allows a memory map change;

performing the memory map change to associate a second memory map with the process thread, the second memory map providing different memory access with respect to the first memory map;

restoring the privilege level to a level that does not allow a memory map change; and

wherein the first and second memory maps each include a mapping that maps a virtual memory address to a physical memory address that is larger than the largest possible virtual memory address that an entity is allowed to address, wherein the first and second memory maps each include a mapping that maps a virtual memory address to a physical memory address that is the same, wherein the virtual memory address that maps to a physical memory address that is larger is in user mode addressable space, and wherein the physical memory address that is the same is in kernel mode addressable space.

2. The method of claim 1 wherein receiving a request comprises receiving an application programming interface call at an operating system component.

3. The method of claim 1 wherein receiving a request comprises, receiving at an operating system a call from a kernel mode component.

4. The method of claim 3 wherein the kernel mode component comprises an installable driver.

5. The method of claim 1 wherein changing a privilege level comprises calling a call gate.

6. The method of claim 1 wherein changing a privilege level comprises changing to a ring 0 privilege level.

7. The method of claim 1 wherein performing the map change comprises writing to a register.

8. The method of claim 1 wherein the second memory map accesses protected memory, and further comprising, executing trusted code while the second memory map is associated with the process thread.

9. The method of claim 8 further comprising, performing a second map change to re-associate the first map with the process thread.

10. The method of claim 8, wherein executing trusted code includes entering a function at a predefined entry point.

11. The method of claim 10 wherein entering the function comprises making an application programming interface call.

12. The method of claim 10 wherein the function allocates memory.

13. The method of claim 10 wherein the function deallocates memory.

14. The method of claim 10 wherein the function allocates an object.

15. The method of claim 14 wherein the object comprises a handle.

16. The method of claim 14 wherein the object comprises a synchronization object.

17. The method of claim 14 wherein the object comprises a process.

18. The method of claim 14 wherein the object comprises a thread.

19. The method of claim 10 wherein the function performs a trust-privileged operation.

20. The method of claim 19 wherein the trust-privileged operation comprises signaling a synchronization object.

21. The method of claim 19 wherein the trust-privileged operation comprises deleting a timer.

22. The method of claim 19 wherein the trust-privileged operation comprises closing a handle.

23. The method of claim 1 wherein the first and second memory maps each map a virtual memory address to a physical memory address that is common to both maps.

24. The method of claim 1 wherein the second map maps to memory that is invalid in the first map.

25. The method of claim 1 wherein the second map maps to memory that has different access rights in the first map.

26. In a computing device, a system comprising:

a process having at least one thread;

a first memory map associated with the at least one thread and having data therein that maps virtual memory addresses to physical memory;

a second memory map having data therein that maps virtual memory addresses to physical memory, the second memory map providing different memory access with respect to the first memory map;

a protection mechanism, the protection mechanism configured to allow changing of a map; and

trusted code, the trusted code configured to invoke the protection mechanism to change the at least one thread from being associated with the first map to be being associated with the second map, and wherein the trusted code further includes a function that performs at least one trust-privileged operation from among a set of trust-privileged operations, the set including;

signaling a synchronization object, deleting a timer, and closing a handle.

27. The system of claim 26 wherein the second memory map has more access rights to virtual memory addresses than the first memory map.

28. The system of claim 26 wherein the protection mechanism comprises a call gate configured to change privilege levels.

29. The system of claim 26 wherein the trusted code includes a thunk configured to re-vector a function call directed to one set of code to another set of code.

30. The system of claim 26 wherein the function allocates memory to the process.

31. The system of claim 26 wherein the function deallocates memory.

32. The system of claim 26 wherein the function allocates an object.

33. The system of claim 32 wherein the object comprises a handle.

34. The system of claim 32 wherein the object comprises a synchronization object.

35. The system of claim 32 wherein the object comprises a process.

36. The system of claim 32 wherein the object comprises a thread.

37. The system of claim 26 wherein only the trusted code is executed while the second memory map is in use.

38. The system of claim 26 wherein the trusted code executes in response to a call from the process.

39. The system of claim 38 wherein the trusted code comprises an operating system component, and wherein the trusted code executes in response to an application program interface call from the process to an operating system component.

40. The system of claim 26 wherein the protection mechanism comprises a call gate.

41. The system of claim 26 wherein the trusted code changes the thread from being associated with the fire map to be being associated with the second map by writing to a register.

42. The system of claim 26 wherein the trusted code changes the thread from being associated with the first map to be being associated with the second map by instructing a hardware component to select a different subset of a translation look-aside buffer.

43. The system of claim 26 wherein the trusted code performs a second map change to re-associate the first map with the process thread, and invokes the protection mechanism to not allow map changing.

45. The system of claim 26 wherein the first and second memory maps each include a mapping that maps a vital memory address to a physical memory address larger than the largest possible virtual memory address that an entity is allowed to specify.

46. The system of claim 45 wherein the virtual memory address that maps to a physical memory address that is larger is in user mode addressable space.

47. The system of claim 45 wherein the first and second memory maps each include a mapping that maps a virtual memory address to a physical memory address that is the same.

48. The system of claim 45 wherein the physical memory address that is the same is in kernel mode addressable space.

49. The system of claim 26 wherein the first and second memory maps each map a virtual memory address to a physical memory address that is common to both maps.

50. The system of claim 26 wherein the second map maps to memory that is invalid in the first map.

51. The system of claim 26 wherein the second map maps to memory that has different access rights in the first map.

52. The system of claim 26 wherein the second map shares a mapping of some virtual addresses to physical addresses common to the first map, and includes another mapping of virtual addresses to physical addresses that are not common to the first map.

44. The system of clam 43 wherein the protection mechanism changes a privilege level to not allow map changing.

53. A computer-implemented method, comprising:

associating first, second and third address maps with a process, wherein at least the second address map includes a mapping that maps a virtual address to a physical address that is larger than the largest possible virtual memory address and the third map includes a mapping that maps a virtual address to a physical address that is larger than the largest physical address mapped to by the second map;

receiving a request from a thread of the process to change from the first address map to the second address map;

changing the first address map to the second address map;

using the mapping to access data at a physical memory location having a physical address that is larger than the largest possible virtual memory address; and

switching to the third map to access data at the physical address that is larger than the largest physical address mapped to by the second map.

54. The computer-implemented method of claim 53 wherein the first and second address maps each map a virtual memory address to a physical memory address that is the same.

55. The computer-implemented method of claim 54 wherein each virtual memory address that maps to a physical memory address that is larger is in user mode addressable space, and wherein the physical memory address that is the same is in kernel mode addressable space.

56. The computer-implemented method of claim 53 wherein changing the first map to the second map includes calling the operating system to switch the maps.

57. In a computer-system, a method comprising:

receiving a request via a process thread having a first memory map associated therewith;

changing a privilege level to a level that allows a memory map change;

performing the memory map change to associate a second memory map with the process thread, the second memory map providing different memory access with respect to the first memory map and accessing protected memory;

restoring the privilege level to a level that does not allow a memory map change;

executing trusted code while the second memory map is associated with the process thread, including entering at a predefined entry point a function that performs at least one trust-privileged operation from among a set of trust-privileged operations, the set including;

signaling a synchronization object, deleting a timer, and closing a handle.

58. The method of claim 57 wherein receiving a request comprises receiving an application programming interface call at an operating system component.

59. The method of claim 57 wherein receiving a request comprises, receiving at an operating system a call from a kernel mode component.

60. The method of claim 59 wherein the kernel mode component comprises an installable driver.

61. The method of claim 57 wherein changing a privilege level comprises calling a call gate.

62. The method of claim 57 wherein changing a privilege level comprises changing to a ring 0 privilege level.

63. The method of claim 57 wherein performing the map change comprises writing to a register.

64. The method of claim 57 further comprising, performing a second map change to re-associate the first map with the process thread.

65. The method of claim 57 wherein entering the function comprises making an application programming interface call.

66. The method of claim 57 wherein the function allocates memory.

67. The method of claim 57 wherein the function deallocates memory.

68. The method of claim 57 wherein the function allocates an object.

69. The method of claim 68 wherein the object comprises an item of a set, the set comprising a handle, a synchronization object, a process and a thread.

70. The method of claim 57 wherein the first and second memory maps each include a mapping that maps a virtual memory address to a physical memory address that is larger than the largest possible virtual memory address that an entity is allowed to address.

71. The method of claim 70 wherein the virtual memory address that maps to a physical memory address that is larger is in user mode addressable space.

72. The method of claim 70 wherein the first and second memory maps each include a mapping that maps a virtual memory address to a physical memory address that is the same.

73. The method of claim 72 wherein the physical memory address that is the same is in kernel mode addressable space.

74. The method of claim 70 wherein the first and second memory maps each include a mapping that maps a virtual memory address to a physical memory address that is the same, wherein the virtual memory address that maps to a physical memory address that is larger is in user mode addressable space, and wherein the physical memory address that is the same is in kernel mode addressable space.

75. The method of claim 57 wherein the first and second memory maps each map a virtual memory address to a physical memory address that is common to both maps.

76. The method of claim 57 wherein the second map maps to memory that is invalid in the first map.

77. The method of claim 57 wherein the second map maps to memory that has different access rights in the first map.