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 Página 5 de 34 –kliens-szerver vagy linkelhet! könyvtár • microkernel és könyvtár-kerjesztés or. filozófia kombinációja
are expected to use a further level of indirection through protected subsystems that implement 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.
9
Executive komponensek
27.2.1 Executive components
In this section we describe the major components of the executive.
• Object Manager !
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. 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 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 endpoints.
–objektumok létrehozása, megszüntetése –jogosultság ellen!rzés –objektumok: er!források reprezentációja, Figure 27.3. Creating executive objects. menedzselése
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.
A hierarchical object naming scheme is provided via directory obje Objektumok használata 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 –perzisztens és dinamikus objektumok
•
an object handle is returned. A security descriptor is attached subsequent calls on the open object can be checked. We have: általános használati séma handle result
open (object-name, mode) service (handle, arguments) Página 8 de 34
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 be 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 longeruseinin the use. Note that this generalizes UNIX's use of usual way. table which contains handles forscheme files, devices and A hierarchical object naming is provided via directory objects pipes. and the objectUNIX namespacepip is visible to all processes. This will be discussed in more detail below. Here we need only be which are not named in anthis kind naming graph. aware that object must have of a name to be opened, shared and protected. 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 handle result
open (object-name, mode) service (handle, arguments)
Every object has aA type which determines its data and the native s process acquires handles for all its open objects and these are available for use by its threads. Sharing processes is also facilitated that processes sharingFigure an object each27.4 applied to it. An object hasbetween a header and a inbody; see 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 is 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. executive by means of generic object services. These services a 27.3.2 The structurecan of an object public service interface which be invoked from either user mod Every object has a type which determines its data and the native system services that can be Figure 27.2. applied to it. An object has a header and a body; see Figure 27.4. The header contains
Objektumok szerkezete • header
–attribútumok (meta adatok) –object service-k használják
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.
• body –típus specifikus adatok, object manager nem használja
In more detail, the standard object header attributes are:
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: !
object type name
name for objects of this type, such as 'process';
18
Objektumok és interfészeik
Página 11 de 34
Página 11 de 34
27.3.4 Object names and directories
19
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.
Objektumok elnevezése Figure 27.7. Object name hierarchy.
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 The naming graph has domains superimposed on it; for example, a subtree of the hierarchy within a single system and the object namespace is visible to all processes; see Figure 27.7. that contains file objects and their directories will be managed by the filing subsystem; see Subject to the security reference monitor, Win32 and other subsystems as well as components Figure 27.9. Files are persistent objects and the task of locating a given file from a directory of the executive can create directory hierarchies since these are simply nested structures entry is a function of file management. We have seen how this may be done in general in comprising directory objects.
Figure 27.7. Object name hierarchy.
Chapter 6 and in UNIX systems in Chapters 24 and 25.
Figure 27.9. Object naming domains.
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.
Object names are supplied to the create and open services; as for all objects, handlesLocating are a dynamic object, that exists only for the duration of a program execution, from a directory used to access open directories. Once a thread has opened a handle to an object directory (withentry is a simpler matter: all that is needed is a pointer to an in-memory object; 20 therefore write access) it can create other objects and place them in the directory; see Figure 27.8. The different executive components are responsible for different portions of the graph. query service scans the list of names and obtains the corresponding location information.
Figure 27.8. An object directory object.
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 external objects in a distributed system. For example, at some point in a pathname an external device name may be detected and network services invoked; see Section 27.8.
file://C:\Documents and Settings\Administrador\Configurações locais\Temp\~hhDECB.... 3/6/2010
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 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.
Objektumok védelme
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)
Página 14 de 34
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.
• ACE (access control entry)
Figure 27.11. An access token object.
22
file://C:\Documents and Settings\Administrador\Configurações locais\Temp\~hhDECB.... 3/6/2010 [ Team LiB ] [ Team LiB ]
