Secure partitioning of shared memory based multiprocessor...

Details Secure partitioning of shared memory based multiprocessor... Secure partitioning of shared memory based multiprocessor...

1999-02-23

2002-11-12

Nguyen, Hiep T. (Department: 2187)

Electrical computers and digital processing systems: memory

Storage accessing and control

Shared memory area

C711S173000, C710S317000

Reexamination Certificate

active

06480941

ABSTRACT:

FIELD OF THE INVENTION
This invention relates to the field of shared memory based multiprocessor systems. More specifically, the invention relates to an apparatus that is capable of partitioning a shared memory based multiprocessor system into independent, fault contained computing domains.
BACKGROUND OF THE INVENTION
Modern computer systems are increasingly comprised of shared memory based multiprocessor systems (SMP). At the same time computing has witnessed a sheer outburst in different types of applications, from user oriented desktop applications, such as word processing, to more enterprise oriented tasks such as web servers, databases and electronic mail services. Each type of such applications can carry significantly different importance and criticality as well as technical maturity. It, therefore, makes sense to group applications with similar reliability, availability and serviceability (RAS) requirements into an independent domain and ensure that faults are contained within that domain, i.e. fault in one domain do not affect applications executing in another domain. Traditionally, such domains were located in different physically separate computing systems, each executing its own distinct operating system image. With the availability of shared memory based multiprocessors systems, the necessity of assigning domains to physically separate computing systems seems to vanish. Instead it is desirable to locate several domains onto the same shared memory multiprocessor and have them share the resources. In order to present to each domain the illusion of an isolated dedicated machine as well as for reasons of fault containment, the resources of the shared-memory based multiprocessor system must then be partitioned among the several operating systems executing on these partitions.
Shown in
FIG. 1
is the general architecture of a shared memory based multiprocessor system in its most common architecture, a symmetric multiprocessor system (SMP). The backbone of the system is the system but (
100
) to which a set of CPUs (
101
) is attached. Also attached to the system bus is the memory controller (
110
) which interfaces the system to the memory subsystem (
111
). Furthermore, a set of I/O controllers (
102
) is attached to the system bus. The system controllers snoop for I/O requests on the bus and forward the request to the I/O subsystem (
120
,
130
) which is attached to its associated I/O bus (
121
, [
130
]
131
) attached to which are the various I/O devices (
122
,
123
,
132
,
133
) serviced by the system.
In principle, one can identify four classes of resources: (a) memory space, (b) I/O space, (c) interrupts and (d) CPUs. Due to reasons described below, it is very difficult to partition a commodity based shared memory based multiprocessor without modification of hardware and system software.
Simple memory partitioning requires that the physical memory range be separated into several memory partitions which are assigned to the various partitions. A single memory partition does not necessarily have to be contiguous. It is even conceivable that there are memory ranges that are shared among partitions, for instance, for the implementation of communication channels that carry additional protocols such as TCP/IP (Transmission Control Protocol/Internet Protocol) or VIA (Virtual Interface Architecture). However, this model still relies on each operating system (OS) or its applications to address only the physical memory that was assigned to its partition. For example, a malicious or a faulty OS can corrupt another partition by gaining access to the other partition's memory space. This can happen in two different ways:
The operating system executes in real non-translated mode and addresses memory that has not been assigned to its partition.
An application's translation table (i.e. page table), as prepared by the OS is corrupted and refers to memory that has not been assigned to its partition.
Both of these cases must be prevented to ensure proper, secure, and fault contained partitioning of shared memory multiprocessors. In particular, a method is required that:
Restricts processors executing as part of a particular partition to access only the physical memory in that partition's memory.
Dependent of the possibility of changes to the operating system, various solutions to this problem known in the prior art are possible. When OS kernel changes are possible, memory access problems can be limited, but not fully eliminated. For instance, code controlling the updates to the translation tables can be very carefully crafted and augmented with verification checks. In particular, changes to the translation tables can be required to be in real-mode and the pages backing the translation tables are never mapped anywhere in any translation table themselves. This can be accomplished by introducing a special privileged processor mode, to update the page tables. This avoids accidental wild writes by an OS that otherwise operates in a translated mode. Alternatively, one can require that all updates to the translation table must be made in a translated mode, and all pages backing the page tables have their write protection enabled or are write protected in by the memory controller. Then, the general protection fault that accompanies a translation table update can be analyzed, verified, and emulated. Unfortunately, wild writes can still cause a problem: in the case where special purpose registers are used to point to the current address table (e.g. Intel-IA32, Dec-Alpha) one cannot catch illegally generated “update-translation-table” instructions, which point to translation tables outside the designated translation table memory range. In contrast, when the OS kernel(s) can not be modified, it is possible to execute the operating system at a lower privileged level, then trap on privileged instructions and emulate them. In particular, updates to translation tables must be verified. However, this case still requires that one trusts the emulation code. Furthermore, this solution comes at a price, namely, the emulation of privileged instructions can introduce a runtime overhead. Even worse, licensing issues of commodity operating systems often prohibit such deployment.
Neither of the above solutions for secure memory partitioning is appropriate when commodity processors, commodity memory and commodity operating systems are used, which is the case for a large quantity of today's computing systems. For instance, many operating systems assume so called “
0
-based” real-memory, where real memory is defined to be the range of memory addresses generated by the general translation mechanism of the processor architecture. In an un-partitioned system, one assumes that real addresses equal physical addresses, i.e., the addresses with which the memory is actually fetched. To fulfill the “
0
-based real memory” model (as required by many commodity operating systems) in a partitioned system the real-memory addresses cannot be semantically equal to the physical memory addresses. Hence, an additional mapping from real to physical addressing is required. Though the remapping idea is not new by itself (PowerPC), it had been typically provided as a part of the processor core, so the address that is pushed onto the memory bus is already translated into physical addresses. What is needed in a system based on commodity processor technology, is a method for remapping real addresses outside the processor core. Unfortunately, due to very tight timing constraints that govern modern system buses, such remapping devices can not be located between the processor and the bus but must be located close to or within the memory controller. The issuing processor-ID, which can be identified by the bus grant signal, is used to select the correct partition based remapping.
However, placing a remapping device with the memory controller, rather than the processor core, creates a cache coherence problem, due to the fact that two partitions can put the same real memory address out on the system bus, yet f

Affiliated with

Also associated with

Rating

Secure partitioning of shared memory based multiprocessor... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Secure partitioning of shared memory based multiprocessor..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Secure partitioning of shared memory based multiprocessor... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2924822