Operációs rendszerek MS Windows NT (2000) bevezetés Történet 1988 új op. rendszer felvetése a MS-nál DOS elavult (egy felhaszn., 8-16 bites, nincs memória védelem, gyenge multitask és virtuális memória támogatás) OS/2 nem jó alternatíva (Intel 80286 spec. assembly) 1989 fejlesztés kezdete vezet! tervez!k DEC VAX csapatból 1993 NT els! kiadása Intel x86, MIPS, DEC Alpha proc. 100 emberévnyi fejlesztés 1994 NT 3.51 PowerPC támogatás 2
Tervezési elvek Kiterjeszthet!ség moduláris, objektum alapú struktúra dinamikusan betölthet! device driverek kliens-szerver process kommunikáció Hordozhatóság kód nagyrésze C, C++, csak hardverközeli rész assembly Skálázhatóság multiprocesszor támogatás nagy memória kezelés 3 Tervezési elvek (folyt.) Integrálhatóság elosztott rendszerek kialakításához hálózati képességek együttm"ködés más op. rendszerekkel Megbízhatóság és robusztusság védelem a bels! hibák ellen op. rendszer védett módban memória védelem jelszavas felhasználó beléptetés jogosultsági rendszer a fájlrendszer elemeihez fájlrendszer védelme véletlen hibák ellen (konzisztencia meg!rzése) 4
Tervezési elvek (folyt.) Kompatibilitás korábbi MS op. rendszerekkel régi szoftverek futtatása Biztonsági tanúsítvány DoD C2 jelszavas felhasználó beléptetés, memória védelem, felhasználónkénti jogosultság kiosztás, er!forrás kvóták Jó teljesítmény gyorsaság (válaszid!k) 5 Tervezési megoldások Operációs rendszer család hardverek széles skáláján, munkaállomások és szerverek Moduláris felépítés Különböz! környezeti API-k MS-DOS, Win 32, POSIX Többféle fájlrendszer FAT, NTFS, ISO9660 Több processzoros rendszerek Natív UNICODE (és ANSI) 6
Szerkezeti felépítés Página 4 de 34 7 The executive builds on lower-level facilities provided by the kernel. For instance, the mechanics of storing and resuming thread contexts is a kernel function, but the creation of new processes and threads is managed by the executive. The kernel is also responsible for dispatching interrupts and exceptions to the appropriate part of the executive and for managing basic synchronization primitives. The interface provided by the kernel is private, used only by the higher-level executive functions; see Figure 27.2. The kernel itself interacts with the physical machine through the hardware abstraction layer (HAL) which abstracts the aspects of the system which are machine dependent, for example how to interact with an interrupt controller or how to communicate between CPUs in a multiprocessor machine. Rendszer komponensek Figure 27.2. System interfaces. Executive operációs rendszer funkciók privilégizált üzemmód objektum menedzsment Kernel The executive is invoked from user mode through a system call interface. However, applications alacsony szint" szolgáltatások objektum kezelés file://c:\documents and Settings\Administrador\Configurações locais\temp\~hhdecb... 3/6/2010 dispatcher, event, mutex, thread, process, timer control objects: asynch. procedure call, interrupt, profile 8
Rendszer komponensek (folyt.) Hardware Abstraction Layer (HAL) hardver különbségek elfedése (portabilitás) virtuális gép interfész több processzor (szimmetrikus multiprocesszálás) interrupt rendszer I/O driverek elérhetik direkt módon a hardvert Védett alrendszerek programozási API-k megvalósítása kliens-szerver vagy linkelhet! könyvtár microkernel és könyvtár-kerjesztés or. filozófia are expected to use a further level of indirection through protected subsystems that implement kombinációja conventional programming APIs in terms of these system calls. The figure illustrates three such subsystems, providing OS/2, Win32 and POSIX environments to their respective client processes. These subsystems can either be structured using a client server model or as shared libraries with which clients link. In practice, a combination of both mechanisms is used so that the subsystem can retain control over system-wide data structures (for example the POSIX subsystem records parent child relationships between the processes that it manages) while allowing more direct access where such protection is not required, for instance translating between file descriptors used by a POSIX process and the underlying identifiers exported by the executive. This represents a limited combination of the microkernel and library extensible operating systems that we saw in Chapter 26. Executive komponensek 27.2.1 Executive components Object Manager In this section we describe the major components of the executive. Página 5 de 34! The object manager creates and deletes executive objects, as shown in Figure 27.3. A system call to create any specific type of executive object results in a call from the component of the executive that manages objects of that type to the object manager. objektumok létrehozása, megszüntetése Object management is the uniform underlying mechanism for the representation and management of resources and the object manager is involved in all generic operations. In Chapter 24 we saw how UNIX processes used file descriptors as a way of identifying the jogosultság ellen!rzés endpoints. objektumok: er!források reprezentációja, Figure 27.3. Creating executive objects. menedzselése resources that they were using. Executive object handles are a more general mechanism: they can identify entities such as processes and threads in addition to communication 9 10! The security reference monitor provides runtime protection for objects and, being involved in object manipulation, can audit their use. The consistent use of object handles
Executive komponensek (folyt.) Securiy Reference Monitor objektumok futási idej" védelme Process Manager folyamatok, szálak kezelése folyamatonként min. 1 szál szál: ütemezett elem folyamatok: er!források foglalása Local Procedure Call kliens-szerver kommunikációs mechanizmus 11 Executive komponensek (folyt.) Virtual Memory Manager folyamatok védett memória címterének kialakítása lapozás I/O System eszköz független I/O fájl kezelés hálózati puffer kezelés 12
Az objektum modell Az objektumok egységes csomagolást nyújtanak az er!forrásoknak elnevezések: rendszer er!források elnevezése emberi használathoz megosztás: er!források és meta adataik megosztása folyamatok között védelem: jogosulatlan hozzáférés megakadályozása 13 Executive objektumok process thread section file port access token event event pair semaphore mutant timer object directory symbolic link profile key 14
close model which is familiar from filing systems. Here objects ma dynamic, needed only for the duration of a program execution, like objects a create operation implies an open operation as well. Per use in the usual way. Objektumok használata A hierarchical object naming scheme is provided via directory obje is visible to all processes. This will be discussed in more detail belo aware that an object must have a name to be opened, shared and open-use-close modell A process that knows the name of an object may open the object access control check is made and, if the process is authorized to u an object handle is returned. A security descriptor is attached subsequent calls on the open object can be checked. We have: perzisztens és dinamikus objektumok általános használati séma handle result open (object-name, mode) service (handle, arguments) A process acquires handles for all its open objects and these are a threads. Sharing between processes is also facilitated in that proce The use of objects is as described in general terms in Section 2.7 and follows the open use close model which is familiar from filing systems. Here objects may persistent, like files, or have a handle for it. The system can note the number of handles a dynamic, needed only for the duration of a program execution, like threads. For dynamic objects a create operation implies an open operation as well. Persistent objects are opened for object is no longer use in in the use. usual way. Note that this generalizes UNIX's use of table which contains A hierarchical handles object naming for scheme files, is provided devices via directory and objects pipes. and the object UNIX namespace pip is visible to all processes. This will be discussed more detail below. Here we need only be which are not named in this kind of naming graph. A process that knows the name of an object may open the object for some mode of use. 15 An access control check is made and, if the process is authorized to use the object in that mode, an object handle is returned. A security descriptor is attached to the open object so that subsequent calls on the open object can be checked. We have: 27.3.2 The structure of an object Every object has a type which determines its data and the native s A process acquires handles for all its open objects and these are available for use by its applied to it. An object threads. Sharing has between a header processes is also and facilitated a in body; that processes see sharing Figure an object each 27.4 have a handle for it. The system can note the number of handles and determine when the open object is no longer in use. Note that this generalizes UNIX's use of the per-process open file standard data (or attributes) which controlled by the object man table which contains handles for files, devices and pipes. UNIX pipes would be dynamic objects which are not named in this kind of naming graph. Objektumok executive by means of generic szerkezete object services. These services a public service interface 27.3.2 The which structure can of object be invoked from either user mod Figure 27.2. header attribútumok (meta adatok) object service-k használják body típus specifikus adatok, object manager nem használja aware that an object must have a name to be opened, shared and protected. handle result open (object-name, mode) service (handle, arguments) Every object has a type which determines its data and the native system services that can be applied to it. An object has a header and a body; see Figure 27.4. The header contains standard data (or attributes) which is controlled by the object manager component of the executive by means of generic object services. These services are the system calls in the public service interface which can be invoked from either user mode or privileged mode; recall Figure 27.2. Figure 27.4. Contents of an object Figure 27.4. Contents of an object header. In more detail, the standard object header attributes are: Página 8 de 34 16 file://c:\documents and Settings\Administrador\Configurações locais\temp\~hhdecb... 3/6/2010
Object services Megnyitott objektumokon végezhet!k close duplicate query object query security set security wait for single object wait for multiple objects 17 Objektum típusok type object: a típushoz tartozó objektumok közös konstans attribútumai Página 10 de 34 a típushoz tartozó objektumok összeláncolása The type-object contains the following: 18! object type name name for objects of this type, such as 'process';
Objektumok és interfészeik Página 11 de 34 Página 11 de 34 27.3.4 Object names and directories Objects are named to achieve identification, location and sharing. Object names are unique within a single system and the object namespace is visible to all processes; see Figure 27.7. Subject to the security reference monitor, Win32 and other subsystems as well as components of the executive can create directory hierarchies since these are simply nested structures comprising directory objects. Figure 27.7. Object name hierarchy. Objektumok elnevezése 19 Página 12 de 34 Objektumok azonosítása egyedi nevekkel Hierarchikus névtér 27.3.4 Object names and directories directory object-ek fája domain-ek Objects are named to achieve identification, location and sharing. Object names are unique within a single system and the object namespace is visible to all processes; see Figure 27.7. The naming graph has domains superimposed on it; for example, a subtree of the hierarchy Subject to the security reference monitor, Win32 and other subsystems as well as components that contains file objects and their directories will be managed by the filing subsystem; see of the executive can create directory hierarchies since these are simply nested structures Figure 27.9. Files are persistent objects and the task of locating a given file from a directory entry is a function of file management. We have seen how this may be done in general in comprising directory objects. Chapter 6 and in UNIX systems in Chapters 24 and 25. Figure 27.7. Object name hierarchy. Object names are supplied to the create and open services; as for all objects, handles are used to access open directories. Once a thread has opened a handle to an object directory (with write access) it can create other objects and place them in the directory; see Figure 27.8. The query service scans the list of names and obtains the corresponding location information. Figure 27.8. An object directory object. Figure 27.9. Object naming domains. Object names are supplied to the create and open services; as for all objects, handles Locating are a dynamic object, that exists only for the duration of a program execution, from a used to access open directories. Once a thread has opened a handle to an object directory directory (with entry is a simpler matter: all that is needed is a pointer to an in-memory object; write access) it can create other objects and place them in the directory; see Figure 27.8. therefore The different executive components are responsible for different portions of the graph. 20 query service scans the list of names and obtains the corresponding location information. Symbolic links are implemented as objects. The type-specific attributes include the substitute pathname string and the time of creation. The namespace design allows for extension to Figure 27.8. An object directory object. external objects in a distributed system. For example, at some point in a pathname an external file://c:\documents and Settings\Administrador\Configurações device name may locais\temp\~hhdecb... be detected and network services invoked; see 3/6/2010 Section 27.8.
Objektumok és folyamatok Minden folyamatnak van egy objektumtáblája handle-k nyílvántartására helyigény miatt 3 szintes fa Página 13 de 34 21 27.3.6 Type-specific object methods The object manager component of the executive exploits the similarities of objects across all types to manage them uniformly. The OM also allows each executive component which is an object type manager to register with it type-specific object methods. OM calls these at welldefined points, such as on create, open, close, delete and when an object is modified. An example is that the filing system (and not OM) should check whether an object to be closed is holding any locks. For the directory services query, parse and security, methods are called if the object exists in a secondary domain; for example, the first few components of a pathname may be in the domain of the object manager. At some point pathname components from a Objektumok védelme secondary domain are reached. At this point the OM will call the parse method for the appropriate secondary domain, such as a filing system, and pass the rest of the pathname to it for resolution. 27.3.7 Protecting objects Access token object Class C2 security requires secure login, discretionary access control, auditing and memory protection. After an authenticated login an access token object is permanently attached to the user's process and serves as an official identifier for authorization and accounting purposes. ACL (access control list) ACE (access control entry) Figure 27.11 shows an example of an access token where user JMB belongs to four example groups named LECT, OPERA, WIC and SSC. A default access control list (ACL) is shown as a number of chained access control entries (ACE). If the user does not supply an ACL on creating an object and there is no arrangement to inherit one from other objects then this default ACL is used. Figure 27.11. An access token object. Página 14 de 34 file://c:\documents and Settings\Administrador\Configurações locais\temp\~hhdecb... [ Team LiB ] [ Team LiB ] 3/6/2010 22