‹#›/45
PB153
OPERAČNÍ SYSTÉMY
A JEJICH ROZHRANÍ
Principy výstavby OS
04

‹#›/45

lExistuje řada přístupů a implementací
●jedno velké monolitické jádro
●modulární, hierarchický přístup
●malé jádro a samostatné procesy
lStruktura mnoha OS je poznamenána historií OS a původními záměry, které se mohou od současného
stavu radikálně lišit
VNITŘNÍ STRUKTURA OS
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

PŘÍKLAD: MS-DOS
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ
application program
resident system program
MS-DOS device drivers
ROM BIOS device drivers

‹#›/45

lPři programování pro OS MS-DOS využíváme služeb
●spuštěných rezidentních programů
●např. ovladač myši (poskytuje služby na INT 33h)
●operačního systému
●např. přístup k souborům (INT 21h)
●BIOSu
●např. nastavení grafického režimu (INT 10h)
●přímo HW
●např. přímo zápis do videopaměti pro zobrazení dat
PŘÍKLAD MS-DOS (2)
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lZměna fontů v textovém režimu (bez využití služeb BIOSu, OS, přímo HW)
●asm cli;
●outport(0x3c4,0x0402);
●outport(0x3c4,0x0704);
●outport(0x3ce,0x0204);
●outport(0x3ce,0x0005);
●outport(0x3ce,0x0406);
●for(i=0;i<=254;i++)
●{ for(j=0;j<=15;j++)
●{p=MK_FP(0xa000,32*i+j);
●*p=font[y]; y++; } }
●outport(0x3c4,0x0302);
●outport(0x3c4,0x0304);
●outport(0x3ce,0x0004);
●outport(0x3ce,0x1005);
●outport(0x3ce,0x0e06);
●asm sti;
●
PŘÍKLAD MS-DOS (3)
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lHlavní cíl návrhu
●maximální možná funkcionalita v co nejmenším prostoru
lVýsledek
●modulová architektura není aplikovaná
●i když MS-DOS má jistou strukturu, jeho rozhraní a jednotlivé komponenty nejsou důsledně
separovány a uspořádány
●
PŘÍKLAD MS-DOS (4)
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lTaké omezen hardwarem
●vznik v polovině 70. let
lOS Unix sestává ze 2 částí
●systémové programy
●jádro
●vše, co se nachází pod rozhraním volání systému a nad fyzickým hardware
●obstarává plnění funkcí z oblastí systému souborů, plánování CPU, správy paměti, …
●vrstvová architektura sice existuje, ale hodně funkcí je na jedné úrovni
PŘÍKLAD UNIX
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

PŘÍKLAD UNIX (2)
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ
(the users)
shells and commands
compilers and interpreters
system libraries
signals terminal
handling
character I/O system
terminal drivers
file system
swapping block I/O
system
disk and tape drivers
CPU schelduling
page replacement
demand paging
virtual memory
system-call interface to the kernel
kernel interface to the hardware
terminal controllers
terminals
device controllers
disks and tapes
memory controllers
physical memory

‹#›/45

PŘÍKLAD: UNIX (3)
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lV roce 1979 koupil Microsoft licenci na  Unix verze 7 od AT&T.
lV roce 1987 předal Microsft Xenix firmě SCO.
lKoncem 80. let byl Xenix pravděpodobně nejrozšířenějším OS unixového typu podle počtu strojů, na
kterých běžel
XENIX
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ
Ms_xenix

‹#›/45

PŘÍKLAD OS/2
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ
application
application
application
application-programming interface
API extension
subsystem
subsystem
subsystem
system
kernel
• memory management
• task dispatching
• device management
device driver
device driver
device driver
device driver

‹#›/45

lOS se dělí do jistého počtu vrstev (úrovní)
lKaždá vrstva je budována na funkcionalitě nižších vrstev
lNejnižší vrstva (0) je hardware
lNejvyšší vrstva je uživatelské rozhraní
lPomocí principu modulů jsou vrstvy vybírány tak, aby každá používala funkcí (operací) a služeb
pouze vrstvy n – 1
HIERARCHICKÁ VRSTVOVÁ ARCHITEKTURA
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

HIERARCHICKÁ ARCHITEKTURA
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ
new
operations
existing
operations
hidden
operations
layer M
layer M - 1

‹#›/45

lŘeší problém přílišné složitosti velkého systému
●Provádí se dekompozice velkého problému na několik menších zvládnutelných problémů
lKaždá úroveň řeší konzistentní podmnožinu funkcí
lNižší vrstva nabízí vyšší vrstvě „primitivní“ funkce (služby)
lNižší vrstva nemůže požadovat provedení služeb vyšší vrstvy
lPoužívají se přesně definovaná rozhraní
●Jednu vrstvu lze uvnitř modifikovat, aniž to ovlivní ostatní vrstvy – princip modularity
HIERARCHICKÁ STRUKTURA
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lVýhodou je modularita OS
lNevýhodou je především vyšší režie a tím pomalejší vykonávání systémových volání
lProtože efektivita hraje v jádře OS významnou roli je třeba volit kompromis
●pouze omezený počet úrovní pokrývající vyšší funkcionalitu
●příklad: první verze Windows NT měli hierarchickou strukturu s řadou vrstev, avšak pro zvýšení
výkonu OS bylo ve verzi NT 4.0 rozhodnuto přesunout více funkcionality do jádra a sloučit některé
vrstvy
HIERARCHICKÁ STRUKTURA
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

PŘÍKLAD: LINUX
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ
Linux_kernel_map

‹#›/45

lKlasický OS (non-process kernel OS)
●OS je prováděn jako samostatná entita v privilegovaném režimu
●procesy – jen uživatelské programy
lSlužba se provádí jako součást jádra
lSlužba se provádí v rámci procesů
●obecně lze celý OS provádět v kontextu uživatelského procesu
●Leží v jeho adresovém prostoru
●přerušení (volání služby OS) vyvolává implicitně pouze přepnutí režimu procesoru (z uživatelského
do privilegovaného), ne změnu kontextu
●k přepínání kontextu procesů dochází jen tehdy, je-li to nutné z hlediska plánování
●pro volání procedur v rámci jádra se používá samostatný zásobník
●program a data OS jsou ve sdíleném adresovém prostoru a sdílí je všechny uživatelské procesy
PROVÁDĚNÍ SLUŽEB V KLASICKÉM OS
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lOS je souhrnem systémových procesů
lJádro tyto systémové procesy separuje,
ale umožňuje jim synchronizaci a komunikaci
lSnaha o provádění co nejmenší části kódu
v privilegovaném režimu procesoru
lV krajním případě je jádro pouze ústředna
pro přepojování zpráv
lTakové řešení OS je snadno implementovatelné
na multiprocesorových systémech
lMalé jádro - mikrojádro
SLUŽBY V PROCESOVĚ KONSTRUOVANÉM OS
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lMicrokernel System Structure
lMalé jádro OS plnící pouze několik málo nezbytných funkcí
●primitivní správa paměti (adresový prostor)
●komunikace mezi procesy – Interprocess communication (IPC)
lVětšina funkcí z jádra se přesouvá do „uživatelské“ oblasti
●ovladače HW zařízení, služby systému souborů, virtualizace paměti …
●mezi uživatelskými procesy se komunikuje předáváním zpráv
STRUKTURA S MIKROJÁDREM
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lVýhody mikrojádra
●snadná přenositelnost OS, jádro je malé
●vyšší spolehlivost (moduly mají jasné API a jsou snadněji testovatelné)
●vyšší bezpečnost  (méně kódu OS běží v režimu jádra)
●flexibilita (jednodušší modifikace, přidání, odebrání modulů)
●všechny služby jsou poskytovány jednotně (výměnou zpráv)
●
lNevýhoda mikrojádra
●zvýšená režie
●volání služeb je nahrazeno výměnou zpráv mezi procesy
STRUKTURA S MIKROJÁDREM (2)
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

MIKROJÁDRO A MONOLITICKÉ JÁDRO
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ
Unix Server
Application
IPC
Device
Driver
File Server
Application
Basic IPC. Virtual Memory, Schelduling
Device Drivers, Dispatcher, …
Scheduler,  Virtual Memory
IPC, File System
VFS
user
mode
kernel
mode
Hardware
Hardware
Monolithic Kernel based Operating System
Microkernel based Operating System
System Call

‹#›/45

lKlasickým příkladem OS s mikrojádrem je Mach vytvořený v 80. letech
lNa přístupu Mach je založen např. Tru64 UNIX nebo realtimový OS QNX
lWindows NT používají hybridní strukturu
●jádro má vrstevnou strukturu a zajišťuje komunikaci aplikace se „servery“
●pro jednotlivé typy aplikací (Win32, OS/2, POSIX) existují „servery“ běžící v uživatelském režimu
MACH
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

PŘÍKLAD: WINDOWS NT
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ
kernel
WIN32
application
WIN32
server
OS/2
server
POSIX
server
OS/2
application
POSIX
application

‹#›/45

lDalší vývoj těchto subsystémů
●OS/2 subsystém naposled ve Windows 2000
●POSIX subsystém je v novějších Windows (ne variantách Home apod.) k dispozici ve formě „Subsystem
for Unix-based Applications“ (SUA)
●Win32 se nyní jmenuje Windows API
●A zahrnuje také API na 64bitových systémech
PŘÍKLAD: WINDOWS NT (pokr.)
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lDo linuxového jádra můžeme při běhu přidávat kód – moduly
●LKM – Loadable Kernel Module
lPřesto je Linuxové jádro monolitické
●Moduly běží stejně jako zbytek jádra v privilegovaném režimu
●Jde o modularitu kódu jádra ne o modulární architekturu jádra (mikrojádro)
LINUX: MODULARITA
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lLKM umožňují:
●Přidávat funkčnost za běhu
●Např. připojení nového USB zařízení
●Snižují paměťové nároky jádra
●Nahráváme jen moduly, které potřebujeme
●Oproti speciálně zkompilovanému jádru však mají vyšší režii
●
LINUX: MODULARITA
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

linsmod, rmmod, lsmod, modinfo, depmod, modprobe
LINUX: MODULARITA
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lLinux moduly obvykle nepodepisuje
lAle všímá si licence …
l
LINUX: MODULARITA
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

Podepisování modulů v Linuxu
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lPodepisování k dispozici od roku 2004
●Ale nevyužíváno často a nebylo součástí standardního jádra do verze 3.7
lProsazuje RedHat (Fedora)
●Aby umožnil tzv. Bezpečný Boot (Secure Boot)
l2 základní režimy
Podepisování modulů v Linuxu
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

l/dev/kmem
●Možnost přímo číst/měnit paměť jádra za běhu
●Přístupné pouze pro administrátora, přesto nebezpečné
●V řadě distribucí už /dev/kmem nenajdeme
lLKM
●Běží v privilegovaném režimu procesoru jako zbytek jádra
●Možnost změny chování jádra
●Rootkity
LINUX: MODIFIKACE JÁDRA ZA BĚHU
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lNejjednodušší způsob jak implementovat rootkit je modifikovat tabulku rutin obsluhujících
systémová volání (sys_call_table) a navázat se na volání jako open, readdir, …
lSnaha omezit možnost LKM modifikovat tabulku systémových volání
lDnes není tento symbol exportován a není tak možné ho v LKM přímo použít a získat tak ukazatel na
tabulku
LINUX: TABULKA SYSTÉMOVÝCH VOLÁNÍ
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lDo jádra Windows můžeme za běhu vkládat ovladače
lTy běží v privilegovaném režimu jádra
l
WINDOWS: MODULARITA
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

WINDOWS: MODULARITA (PŘ.)
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

OVLADAČE VE WINDOWS XP
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

OVLADAČE A NOVĚJŠÍ WINDOWS
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

PODPISY VYŽADOVÁNY U 64BITOVÝCH SYSTÉMŮ
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lU Windows nejde při podepisování o čistotu jádra či licence
lJde především o
●Spolehlivost systému – tj. kvalitu kódu běžícího v privilegovaném režimu
●A s tím související bezpečnost jádra/systému
●DRM (!)
lUser mode drivers – snaha snížit množství kódu běžící přímo v jádře
PODPISY OVLADAČŮ
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lTradičně býval OS napsaný v symbolickém strojovém jazyku (assembleru)
lOS se stále častěji píší v běžných programovacích jazycích vysoké úrovně (obvykle C/C++)
●lze naprogramovat rychleji
●výsledek je kompaktnější
●OS je srozumitelnější a lze ho snadněji ladit
●je snadněji přenositelný na jinou architekturu
IMPLEMENTACE SYSTÉMU
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lOperační systém je navržen tak, aby mohl běžet na jisté třídě architektur / sestav počítače
lOS musí být konfigurovatelný na konkrétní sestavu
lProgram SYSGEN
●Získává informace týkající se konkrétní konfigurace konkrétního hardwarového systému
lBootování
●Spuštění činnosti počítače zavedením jádra a předáním řízení
na vstupní bod jádra pro spuštění činnosti
lBootstrap program
●Program uchovávaný v ROM, který je schopný naleznout jádro, zavést ho do paměti a spustit jeho
provedení
SYSTEM GENERATION (SYSGEN)
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lŘídí BIOS
●provede se inicializace HW komponent
●na základě uložené konfigurace zjistíme z kterého zařízení se má OS zavést
●v případě pevného disku se spustí kód uložený
v Master Boot Recordu (MBR)
●tento kód například zjistí, která partition je aktivní a spustí boot sektor této partition. Kód
uložený v boot sektoru načte soubory s jádrem OS do paměti
●nebo např. LILO/Grub umožní interaktivně vybrat který OS bude zaveden (bootsektor které partition
se má spustit?; kde je soubor s jádrem OS?)
●tento kód může být delší než je délka MBR, musí pak být uložen v jiné oblasti disku
BOOTOVÁNÍ IBM PC
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lBIOS kontroluje HW
lZ vybraného zařízení se získá a spustí zavaděč („boot loader“)
●Např. se z pevného disku přečte prvních 512 bajtů
(tzv. MBR) a spustí se tento „kód“ (fáze 1).
●
●
PŘÍKLAD: BOOTOVÁNÍ LINUXU (IBM PC)
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

HLAVNÍ ZAVÁDĚCÍ ZÁZNAM
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ
Struktura MBR
Adresa
Popis
Délka
v bajtech
Hex
Oct
Dec
0000
0000
0
  Kód zavaděče
440
(max 446)
01B8
0670
440
  Volitelná délka disku
4
01BC
0674
444
  Obvykle nuly; 0x0000
2
01BE
0676
446
  Tabulka primárnách oddílů
  (4 položky po 16 bajtech, IBM schéma oddílů)
64
01FE
0776
510
55h
Signatura MBR;
0xAA55
2
01FF
0777
511
Aah
Celková délka MBR: 446 + 64 + 2 =
512

‹#›/45

lSpuštění zavadeče
●Ve volitelné fázi 1.5 se zavede kód pro přístup k disku (BIOS nemusí plně umět).
●Ve fázi 2 se zavede zbytek kódu zavaděče.
lVýběr OS a parametrů
●GRUB je schopen pracovat s ext2, ext3, ext4 souborovými systémy
●LILO souborové systémy nezná a pracuje s přímými adresami souborů na disku
PŘÍKLAD: BOOTOVÁNÍ LINUXU (IBM PC) - POKRAČOVÁNÍ
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

VÝBĚR OS - GRUB
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ
GrubMenu00

‹#›/45

lSpuštění jádra
●Z disku je přečten obraz jádra
●Tento obraz se dekomprimuje
●Provede se základní inicializace (např. tabulka stránek paměti)
●Spustí se jádro (volá se funkce start_kernel())
lJádro
●Nastaví systém (ovladače přerušení, inicializace zařízení a ovladačů zařízení) a spustí plánovač.
●Vytvoří proces Init (číslo procesu 1) – např. /sbin/init
BOOTOVANÍ LINUXU (IBM PC)
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

lMBR je limitován velikostí disku 2TB
●32 bitů pro počet sektorů x 512 bitů na sektor
lIntel vyvinul nový standard GUID partition table
●GPT
●Redundance: tabulka na začátku a konci disku
●Chránící MBR položka (oddíl EEh přes celý disk)
●Minimálně 128 položek pro oddíly
lPodporováno na většině dnešních OS
●GPT nepodporuje Win XP (32 + 64 bit) a Win Server 2003 (32 bit)
GPT
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ

‹#›/45

GUID jednotlivých oddílů
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ
Zdroj:
Wikipedia (GPT)

‹#›/45

lSnaha o bezpečné zavedení OS
●Ochrana samotného zavedení OS
●Prevence rootkitu (bootkitu)
lSoučást tzv. bezpečného bootu
●Bezpečnost i dalších komponent (už. programů)
●
l
Bezpečný boot (secure boot)
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ
Secure Boot is a technology where the system firmware checks that the system boot loader is signed
with a cryptographic key authorized by a database contained in the firmware. With adequate
signature verification in the next-stage boot loader(s), kernel, and, potentially, user space, it
is possible to prevent the execution of unsigned code.
Zdroj: Fedora 18. UEFI Secure Boot Guide

‹#›/45

Bezpečný boot ve Windows 8
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ
http://blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00
-00-01-57-25-metablogapi/6332.clip_5F00_image002_5F00_574CC934.jpg
Zdroj: MSDN

‹#›/45

Bezpečný boot ve Fedora Linux (18+)
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ
•Shim: This is signed by the UEFI signing service. We do not have control over this key. The shim
contains the Fedora Boot CA public key.
•GRUB: This is signed by the "Fedora Boot Signer" key, which chains off the Fedora Boot CA key.
GRUB doesn't contain any keys, it calls into shim for its verification.
•Kernel: This is also signed by the Fedora Boot Signer. The kernel contains the public key used to
sign kernel modules.
•Kernel Modules: These are signed with a private key generated during build. This key is not saved,
a new key is used with each kernel build.
Zdroj: Fedora 18. UEFI Secure Boot Guide
lPostupné zavádění komponent
●Shim, Grub, jádro, moduly jádra

‹#›/45

Bezpečný boot – boj proti malware?
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ
LINUX VENDOR Red Hat will pay Verisign to sign Fedora 18 so it can work with Microsoft's UEFI
Secure Boot.
Microsoft has ordered all PC makers shipping Windows 8 PCs to have its UEFI Secure Boot feature
enabled, which poses a significant hurdle for users should they want to install a different
operating system. Now the Red Hat sponsored Fedora project has said it intends to pay Verisign $99
to sign its software.
Microsoft's intention with UEFI Secure Boot is to only allow trusted software to interact with PC
hardware, including bootloaders and drivers. However many observers have pointed out that the
company can also use this requirement to make it extremely difficult for users to install
alternative operating systems.
…
While Verisign will be receiving $99 from Fedora and presumably the Ubuntu project and other Linux
distributions, it is Microsoft that is the real winner, so far, since it is clear that UEFI Secure
Boot will hurt not just Linux distributions but any operating systems that don't have the resources
to sign everything to meet Microsoft's unilaterally imposed security regime.
Zdroj:
http://www.theinquirer.net/inquirer/news/2181774/red-hat-pay-verisign-sign-fedora-microsofts-uefi-s
ecure-boot

‹#›/45
Výukovou pomůcku zpracovalo
Servisní středisko pro e-learning na MU
http://is.muni.cz/stech/
PB 153 OPERAČNÍ SYSTÉMY A JEJICH ROZHRANÍ