-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathAdvanced Operating Systems - Cheatsheet.tex
3592 lines (3305 loc) · 192 KB
/
Advanced Operating Systems - Cheatsheet.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
\documentclass[a4paper]{article}
\usepackage[ngerman]{babel}
\usepackage[utf8]{inputenc}
\usepackage{multicol}
\usepackage{calc}
\usepackage{ifthen}
\usepackage[landscape]{geometry}
\usepackage{amsmath,amsthm,amsfonts,amssymb}
\usepackage{color,graphicx,overpic}
\usepackage{xcolor, listings}
\usepackage[compact]{titlesec} %less space for headers
\usepackage{mdwlist} %less space for lists
\usepackage{pdflscape}
\usepackage{verbatim}
\usepackage[most]{tcolorbox}
\usepackage[hidelinks,pdfencoding=auto]{hyperref}
\usepackage{bussproofs}
\usepackage{fancyhdr}
\usepackage{lastpage}
\pagestyle{fancy}
\fancyhf{}
\fancyhead[L]{Advanced Operating Systems}
\fancyfoot[L]{\thepage/\pageref{LastPage}}
\renewcommand{\headrulewidth}{0pt} %obere Trennlinie
\renewcommand{\footrulewidth}{0pt} %untere Trennlinie
\usepackage{pifont}
\newcommand{\cmark}{\ding{51}}
\newcommand{\xmark}{\ding{55}}
\pdfinfo{
/Title (Advanced Operating Systems - Cheatsheet)
/Creator (TeX)
/Producer (pdfTeX 1.40.0)
/Author (Robert Jeutter)
/Subject ()
}
%%% Code Listings
\definecolor{codegreen}{rgb}{0,0.6,0}
\definecolor{codegray}{rgb}{0.5,0.5,0.5}
\definecolor{codepurple}{rgb}{0.58,0,0.82}
\definecolor{backcolour}{rgb}{0.95,0.95,0.92}
\lstdefinestyle{mystyle}{
backgroundcolor=\color{backcolour},
commentstyle=\color{codegreen},
keywordstyle=\color{magenta},
numberstyle=\tiny\color{codegray},
stringstyle=\color{codepurple},
basicstyle=\ttfamily,
breakatwhitespace=false,
}
\lstset{style=mystyle, upquote=true}
%textmarker style from colorbox doc
\tcbset{textmarker/.style={%
enhanced,
parbox=false,boxrule=0mm,boxsep=0mm,arc=0mm,
outer arc=0mm,left=2mm,right=2mm,top=3pt,bottom=3pt,
toptitle=1mm,bottomtitle=1mm,oversize}}
% define new colorboxes
\newtcolorbox{hintBox}{textmarker,
borderline west={6pt}{0pt}{yellow},
colback=yellow!10!white}
\newtcolorbox{importantBox}{textmarker,
borderline west={6pt}{0pt}{red},
colback=red!10!white}
\newtcolorbox{noteBox}{textmarker,
borderline west={3pt}{0pt}{green},
colback=green!10!white}
% define commands for easy access
\renewcommand{\note}[2]{\begin{noteBox} \textbf{#1} #2 \end{noteBox}}
\newcommand{\warning}[1]{\begin{hintBox} \textbf{Warning:} #1 \end{hintBox}}
\newcommand{\important}[1]{\begin{importantBox} \textbf{Important:} #1 \end{importantBox}}
% This sets page margins to .5 inch if using letter paper, and to 1cm
% if using A4 paper. (This probably isn't strictly necessary.)
% If using another size paper, use default 1cm margins.
\ifthenelse{\lengthtest { \paperwidth = 11in}}
{ \geometry{top=.5in,left=.5in,right=.5in,bottom=.5in} }
{\ifthenelse{ \lengthtest{ \paperwidth = 297mm}}
{\geometry{top=1.3cm,left=1cm,right=1cm,bottom=1.2cm} }
{\geometry{top=1.3cm,left=1cm,right=1cm,bottom=1.2cm} }
}
% Redefine section commands to use less space
\makeatletter
\renewcommand{\section}{\@startsection{section}{1}{0mm}%
{-1ex plus -.5ex minus -.2ex}%
{0.5ex plus .2ex}%x
{\normalfont\large\bfseries}}
\renewcommand{\subsection}{\@startsection{subsection}{2}{0mm}%
{-1explus -.5ex minus -.2ex}%
{0.5ex plus .2ex}%
{\normalfont\normalsize\bfseries}}
\renewcommand{\subsubsection}{\@startsection{subsubsection}{3}{0mm}%
{-1ex plus -.5ex minus -.2ex}%
{1ex plus .2ex}%
{\normalfont\small\bfseries}}
\makeatother
% Don't print section numbers
\setcounter{secnumdepth}{0}
\setlength{\parindent}{0pt}
\setlength{\parskip}{0pt plus 0.5ex}
% compress space
\setlength\abovedisplayskip{0pt}
\setlength{\parskip}{0pt}
\setlength{\parsep}{0pt}
\setlength{\topskip}{0pt}
\setlength{\topsep}{0pt}
\setlength{\partopsep}{0pt}
\linespread{0.5}
\titlespacing{\section}{0pt}{*0}{*0}
\titlespacing{\subsection}{0pt}{*0}{*0}
\titlespacing{\subsubsection}{0pt}{*0}{*0}
\begin{document}
\raggedright
\begin{multicols}{3}\scriptsize % multicol parameters % These lengths are set only within the two main columns %\setlength{\columnseprule}{0.25pt} \setlength{\premulticols}{1pt} \setlength{\postmulticols}{1pt} \setlength{\multicolsep}{1pt} \setlength{\columnsep}{2pt}
\section{Zusammenfassung}
\begin{itemize*}
\item Funktional: \textbf{was} ein (Software)-Produkt tun soll
\item Nichtfunktional: \textbf{wie} funktionale Eigenschaften realisiert werden
\item andere Bezeichnungen NFE: Qualitäten, Quality of Service
\end{itemize*}
\begin{description*}
\item[Laufzeiteigenschaften] zur Laufzeit eines Systems beobachtbar
\begin{itemize*}
\item Sparsamkeit und Effizienz
\item Robustheit, Verfügbarkeit
\item Sicherheit (Security)
\item Echtzeitfähigkeit, Adaptivität, Performanz
\end{itemize*}
\item[Evolutionseigenschaften] (Weiter-) Entwicklung und Betrieb
\begin{itemize*}
\item Wartbarkeit, Portierbarkeit
\item Offenheit, Erweiterbarkeit
\end{itemize*}
\end{description*}
Mobile und eingebettete Systeme (kleine Auswahl)
\begin{itemize*}
\item mobile Rechner-Endgeräte
\item Weltraumfahrt und -erkundung
\item Automobile
\item verteilte Sensornetze (WSN)
\item Chipkarten
\item Multimedia-und Unterhaltungselektronik
\end{itemize*}
\subsection{Betriebssysteme}
\subsubsection{Hardwarebasis}
\begin{itemize*}
\item Einst: Einprozessor-Systeme
\item Heute: Mehrprozessor-/hochparallele Systeme
\item neue Synchronisationsmechanismen erforderlich
\item[$\rightarrow$] unterschiedliche Hardware und deren Multiplexing
\end{itemize*}
\subsubsection{Betriebssystemarchitektur}
\begin{itemize*}
\item Einst: Monolithische und Makrokernel-Architekturen
\item Heute: Mikrokernel(-basierte) Architekturen
\item Exokernelbasierte Architekturen (Library-Betriebssysteme)
\item Virtualisierungsarchitekturen
\item Multikernel-Architekturen
\item[$\rightarrow$] unterschiedliche Architekturen
\end{itemize*}
\subsubsection{Ressourcenverwaltung}
\begin{itemize*}
\item Einst: Batch-Betriebssysteme, Stapelverarbeitung (FIFO)
\item Heute: Echtzeitgarantien für Multimedia und Sicherheit
\item echtzeitfähige Scheduler, Hauptspeicherverwaltung, Ereignismanagement, Umgang mit Überlast/Prioritätsumkehr ...
\item[$\rightarrow$] unterschiedliche Ressourcenverwaltung
\end{itemize*}
\subsubsection{Betriebssystemabstraktionen}
\begin{itemize*}
\item Reservierung von Ressourcen ( $\rightarrow$ eingebettete Systeme)
\item Realisierung von QoS-Anforderungen ( $\rightarrow$ Multimediasysteme)
\item Erhöhung der Ausfallsicherheit ( $\rightarrow$ verfügbarkeitskritisch)
\item Schutz vor Angriffen und Missbrauch ( $\rightarrow$ sicherheitskritisch)
\item flexiblen und modularen Anpassen des BS ( $\rightarrow$ hochadaptiv)
\item[$\rightarrow$] höchst diverse Abstraktionen von Hardware
\end{itemize*}
\subsubsection{Betriebssysteme als Softwareprodukte}
\begin{itemize*}
\item Betriebssystem: endliche Menge von Quellcode
\item besitzen differenzierte Aufgaben $\rightarrow$ funktionale Eigenschaften
\item Anforderungen an Nutzung und Pflege $\rightarrow$ Evolutionseigenschaften
\item können für Betriebssysteme höchst speziell sein
\item[$\rightarrow$] spezielle Anforderungen an das Softwareprodukt BS
\end{itemize*}
Grundlegende funktionale Eigenschaften von BS: Hardware-
\begin{description*}
\item[Abstraktion] Ablaufumgebung auf Basis der Hardware bereitstellen
\item[Multiplexing] Ablaufumgebung zeitlich/logisch getrennt einzelnen Anwendungen zuteilen
\item[Schutz] gemeinsame Ablaufumgebung gegen Fehler und Manipulation
\end{description*}
\subsection{Sparsamkeit und Effizienz}
\begin{itemize*}
\item Sparsamkeit: Funktion mit minimalem Ressourcenverbrauch %ausüben
\item Effizienz: Grad der Sparsamkeit %zu welchem ein System oder eine seiner Komponenten seine Funktion mit minimalem Ressourcenverbrauch ausübt
%\item $\rightarrow$ Ausnutzungsgrad begrenzter Ressourcen
\item Die jeweils betrachtete Ressource muss dabei spezifiziert sein
\item sinnvolle Möglichkeiten bei BS: Sparsamer Umgang mit Energie, Speicherplatz oder Prozessorzeit
\end{itemize*}
\begin{enumerate*}
\item Hardware-Ebene: %momentan nicht oder nicht mit maximaler Leistung benötigte Ressourcen in energiesparenden Modus bringen: abschalten, Standby,
Betriebe mit verringertem Energieverbrauch
\item Software-Ebene: neue Komponenten entwickeln, um
\begin{itemize*}
\item Bedingungen für energiesparen erkennen
\item Steuerungs-Algorithmen für Hardwarebetrieb% so zu gestalten, dass Hardware-Ressourcen möglichst lange in einem energiesparenden Modus betrieben werden
\item Energie-Verwaltungsstrategien%: energieeffizientes Scheduling zur Vermeidung von Unfairness und Prioritätsumkehr
\item Bsp: Festplatten-Prefetching, RR-Scheduling
\end{itemize*}
\end{enumerate*}
Sparsamkeit mit Speicherplatz
\begin{itemize*}
%\item Betrachtet: Sparsamkeit mit Speicherplatz mit besonderer Wichtigkeit für physisch beschränkte, eingebettete und autonome Geräte
\item Maßnahmen Hauptspeicherauslastung
\begin{enumerate*}
\item Speicherplatz sparende Algorithmen gleicher Strategien
\item Speicherverwaltung von Betriebssystemen
\begin{itemize*}
\item physische vs. virtuelle Speicherverwaltung
\item speichereffiziente Ressourcenverwaltung
\item Speicherbedarfdes Kernels
\item direkte Speicherverwaltungskosten
\end{itemize*}
\end{enumerate*}
\item Maßnahmen Hintergrundspeicherauslastung
\begin{enumerate*}
\item Speicherbedarf des Betriebssystem-Images
\item dynamische SharedLibraries
\item VMM-Auslagerungsbereich
\item Modularität und Adaptivität des Betriebssystem-Images
\end{enumerate*}
%\item Nicht betrachtet: Sparsamkeit mit Prozessorzeit
$\rightarrow$ 99\% Überschneidung mit NFE Performanz
\end{itemize*}
\subsection{Robustheit und Verfügbarkeit}
\begin{itemize*}
\item Robustheit: Zuverlässigkeit unter Anwesenheit externer Ausfälle
\item fault $\xrightarrow{aktiviert}$ error $\xrightarrow{breitet sich aus}$ failure
\item Korrektheit: Systemverhalten gemäß seiner Spezifikation
\item Verfügbarkeit: Anteil an Laufzeit, in dem Leistung erbracht
\end{itemize*}
Robustheit
\begin{itemize*}
\item Erhöhung durch Isolation: Verhinderung der Fehlerausbreitung
\begin{enumerate*}
\item Adressraumisolation: Mikrokernarchitekturen,
\item kryptografische HW-Unterstützung (Intel SGX)
\item Virtualisierungsarchitekturen
\end{enumerate*}
\item Behandlung von Ausfällen: Micro-Reboots
\end{itemize*}
Vorbedingung für Robustheit: Korrektheit
\begin{enumerate*}
\item Tests: nur Fehler aufspüren, keine Fehlerfreiheit garantiert
\item Verifizierung: komplex und umfangreich durch Modelle begrenzt
\end{enumerate*}
Verfügbarkeit
\begin{itemize*}
\item angesprochen: Hochverfügbare Systeme
\item Maßnahmen: Redundanz, Ausfallmanagement
\end{itemize*}
\subsection{Sicherheit}
\begin{itemize*}
\item Sicherheit: Schutz gegen Schäden durch zielgerichtete Angriffe, besonders Informationen (speichern, verarbeiten, kommunizieren)
\item Sicherheitsziele
\begin{enumerate*}
\item Vertraulichkeit (Confidentiality)
\item Integrität (Integrity)
\item Verfügbarkeit (Availability)
\item Authentizität (Authenticity)
\item Verbindlichkeit (Non-repudiability)
\end{enumerate*}
\item S.Ziele $\rightarrow$ Politik $\rightarrow$ Architektur $\rightarrow$ Mechanismen
\end{itemize*}
Security Engineering
\begin{description*}
\item[Politik] Regeln zum Erreichen eines Sicherheitsziels %\tiny{IBAC, TE, DAC, MAC}
\item[Mechanismen] Implementierung der Durchsetzung der Politik %\tiny{ACLs, SELinux}
\item[Architektur] Platzierung, Struktur und Interaktion von Mechanismen
\end{description*}
wesentlich: Referenzmonitorprinzipien
\begin{description*}
\item[RM1] Unumgehbarkeit $\rightarrow$ vollständiges Finden aller Schnittstellen
\item[RM2] Manipulationssicherheit $\rightarrow$ Sicherheit einer Sicherheitspolitik %selbst
\item[RM3] Verifizierbarkeit $\rightarrow$ wohlstrukturierte und per Design kleine TCBs
\end{description*}
\subsection{Echtzeitfähigkeit}
\begin{itemize*}
\item Echtzeitfähigkeit: auf eine Eingabe innerhalb spezifizierten Zeitintervalls korrekte Reaktion hervorbringen
%\item Maximum dieses relativen Zeitintervalls: Frist d
\end{itemize*}
\begin{enumerate*}
\item echtzeitfähige Scheduling-Algorithmen für Prozessoren
\item zentral: garantierte Einhaltung von Fristen
\item Probleme: Prioritätsumkehr, Überlast, kausale Abhängigkeit
\item echtzeitfähige Interrupt-Behandlung
\item zweiteilig: asynchron registrieren, geplant bearbeiten
\item echtzeitfähige Speicherverwaltung
\item Primärspeicherverwaltung, VMM (Pinning)
\item Sekundärspeicherverwaltung, Festplattenscheduling
\end{enumerate*}
\subsection{Adaptivität}
\begin{itemize*}
\item Adaptivität: gegebenes (breites) Spektrum NFEs zu unterstützen
\item Adaptivität komplementär und synergetisch zu anderen NFE
\end{itemize*}
\begin{description*}
\item[Exokernel] \{Adaptiv\}$\cup$\{Performant, Echtzeit, Wartbar, Sparsam\}
\item[Virtualisierung] \{Adaptiv\}$\cup$\{Wartbar, Sicherheit, Robust\}
\item[Container] \{Adaptiv\}$\cup$\{Wartbar, Portabel, Sparsam\}
\end{description*}
\subsection{Performanz und Parallelität}
\begin{itemize*}
\item Performanz: für korrekte Funktion benötigte Zeit minimieren
\item hier betrachtet: Kurze Antwort-und Reaktionszeiten
\item Mechanismen, Architekturen, Grenzen der Parallelisierung
\end{itemize*}
\begin{description*}
\item[Hardware] Multicore-Prozessoren, Superskalarität
\item[Betriebssystem] Multithreading, Scheduling, Synchronisation und Kommunikation, Lastangleichung
\item[Anwendung] Parallelisierbarkeit, Effizienz, Prozessoreneinsatz
\end{description*}
\subsection{Synergetische und konträre Eigenschaften}
\begin{itemize*}
\item eine NFE bei IT-Systemen meist nicht ausreichend
%\item Welche nichtfunktionalen Eigenschaften mit Maßnahmen erreichbar, die in gleiche Richtung zielen, bei welchen wirken Maßnahmen eher gegenläufig?
%\item Erstere sollen synergetische, die zweiten konträre (also in Widerspruch zueinander stehende) nichtfunktionale Eigenschaften genannt werden.
\item Zusammenhang nicht immer eindeutig und offensichtlich %wie z.B. bei: ,,Sicherheit kostet Zeit.'' (d.h. Performanz und Sicherheit sind nichtsynergetische Eigenschaften)
\item bestimmte Einsatzgebiete brauchen oft mehrere NFE gleichzeitig %- unabhängig davon, ob sich diese synergetisch oder nichtsynergetisch zueinander verhalten
%\item Echtzeit und Verlässlichkeit: ,,SRÜ''-Systeme an potentiell gefährlichen Einsatzgebieten
%\item Echtzeit und Sparsamkeit: Teil der eingebetteten Systeme
%\item Robustheit und Sparsamkeit: unter entsprechenden Umweltbedingungen eingesetzte autonome Systeme, z.B. smart-dust-Systeme
\end{itemize*}
Überblick: NFE und Architekturkonzepte
\begin{tabular}{r|c|c|c|c|c}
& Makrok. & Mikro. & Exok. & Virt. & Multik. \\\hline
Energieeff. & & & (\cmark) & \xmark & \xmark \\
Speichereff. & \xmark & (\cmark) & (\cmark) & & \xmark \\
Robustheit & \xmark & \cmark & \xmark & \cmark & \\
Verfügbarkeit & \xmark & (\cmark) & & (\cmark) & (\cmark) \\
Korrektheit & \xmark & \cmark & \xmark & \xmark & (\cmark) \\
Sicherheit & \xmark & \cmark & \xmark & \cmark & \\
Echtzeitfähig & (\cmark) & (\cmark) & \cmark & \xmark & \xmark \\
Adaptivität & \xmark & (\cmark) & \cmark & \cmark & (\cmark) \\
Wartbarkeit & \cmark & & \cmark & \cmark & \\
Performanz & (\cmark) & \xmark & \cmark & \xmark & \cmark
\end{tabular}
\cmark Ziel, (\cmark) synergetisch, \xmark Konträr
\pagebreak
\section{Sparsamkeit und Effizienz}
\begin{description*}
\item[Sparsamkeit] Funktion mit minimalem Ressourcenverbrauch ausüben $\rightarrow$ Effizienz bei Nutzung der Ressourcen
\item[Effizienz] Grad mit welchem System Sparsam ist
\end{description*}
\begin{itemize*}
%\item mobile Geräte: Sparsamkeit mit Energie
\item Sparsamkeit mit weiteren Ressourcen, z.B. Speicherplatz
\item Betriebssystem (Kernel + User Space): geringer Speicherbedarf
\item optimale Speicherverwaltung durch Betriebssystem zur Laufzeit
\item Baugrößenoptimierung (Platinen-und Peripheriegerätegröße)
%\item Kostenoptimierung (kleine Caches, keine MMU, ...)
%\item massiv reduzierte HW-Schnittstellen (E/A-Geräte, Peripherie)
\end{itemize*}
\subsection{Energieeffizienz}
zeitweiliges Abschalten momentan nicht benötigter Ressourcen
\begin{itemize*}
\item Dateisystem-E/A: energieeffizientes Festplatten-Prefetching
\item CPU-Scheduling: energieeffizientes Scheduling
\item Speicherverwaltung: Lokalitätsoptimierung
\item Netzwerk: energiebewusstes Routing
\item Verteiltes Rechnen: temperaturabhängige Lastverteilung
\end{itemize*}
\subsubsection{Energieeffiziente Dateizugriffe}
\begin{itemize*}
\item HDD etc. sparen nur bei relativ langer Inaktivität Energie
\item Aufgabe: kurze, intensive Zugriffsmuster $\rightarrow$ lange Inaktivität
\item HDD-Geräten: Zustände mit absteigendem Energieverbrauch
\begin{description*}
\item[Aktiv] einziger Arbeitszustand
\item[Idle] Platte rotiert, Elektronik teilweise abgeschaltet
\item[Standby] Rotation abgeschaltet
\item[Sleep] gesamte restliche Elektronik abgeschaltet
\end{description*}
\item ähnliche, noch stärker differenzierte Zustände bei DRAM
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-energiezustände-festplatte.png}
%\item durch geringe Verlängerungen des idle - Intervalls kann signifikant der Energieverbrauch reduziert werden
\end{itemize*}
\subsubsection{Prefetching-Mechanismus}
\begin{itemize*}
\item Prefetching (,,Speichervorgriff'', vorausschauend) \& Caching
\begin{itemize*}
\item Standard-Praxis bei moderner Datei-E/A
\item Voraussetzung: Vorwissen über benötigte Folge von zukünftigen Datenblockreferenzen
\item Ziel: Performanzverbesserung durch Durchsatzerhöhung und Latenzzeit-Verringerung
\item Idee: Vorziehen möglichst vieler E/A-Anforderungen an Festplatte + zeitlich gleichmäßige Verteilung verbleibender
\item Umsetzung: Caching dieser vorausschauend gelesenen Blöcke in ungenutzten PageCache
\end{itemize*}
%\item[$\rightarrow$] Inaktivität überwiegend sehr kurz $\rightarrow$ Energieeffizienz ...?
\item Zugriffs-/Festplattenoperationen
\begin{description*}
\item[access(x)] zugriff auf Inhalt von Block x im PageCache
\item[fetch(x)] hole Block x nach einem access(x) von Festplatte
\item[prefetch(x)] hole Block x ohne access(x) von Festplatte
\end{description*}
\item bisher Fetch-on-Demand-Strategie (kein vorausschauendes Lesen)
\item Traditionelles Prefetching
\begin{enumerate*}
\item Optimales Prefetching: Jedes \emph{prefetch} soll nächsten Block im Referenzstrom in Cache bringen, der noch nicht dort ist
\item Optimales Ersetzen: ersetzender \emph{prefetch} soll Block überschreiben, der weitesten in der Zukunft benötigt wird
\item ,,Richte keinen Schaden an'': Überschreibe niemals Block A um Block B zu holen, wenn A vor B benötigt wird
\item Erste Möglichkeit: Führe nie ein ersetzendes \emph{prefetch} aus, wenn dieses schon vorher hätte ausgeführt werden können
\end{enumerate*}
\item Energieeffizientes Prefetching: Länge der Disk-Idle maximieren
\begin{enumerate*}
\item Optimales Prefetching
\item Optimales Ersetzen
\item ,,Richte keinen Schaden an''
\item Maximiere Zugriffsfolgen: Führe immer dann nach einem \emph{fetch}/\emph{prefetch} ein weiteres \emph{prefetch} aus, wenn Blöcke für eine Ersetzung geeignet sind
\item Beachte Idle-Zeiten: Unterbrich nur dann eine Inaktivitätsperiode durch ein \emph{prefetch}, falls dieses sofort ausgeführt werden muss, um Cache-Miss zu vermeiden
\end{enumerate*}
\end{itemize*}
Allgemeine Schlussfolgerungen
\begin{enumerate*}
\item HW-Spez. nutzen: Modi, mit wenig Energieverbrauch
\item Entwicklung von Strategien, die langen Aufenthalt in energiesparenden Modi ermöglichen% und dabei Leistungsparameter in vertretbarem Umfang reduzieren
\item Implementieren dieser Strategien in BS zur Ressourcenverwaltung
\end{enumerate*}
\subsubsection{Energieeffizientes Prozessormanagement}
\begin{itemize*}
\item CMOS z.Zt. meistgenutzte Halbleitertechnologie für Prozessor
\item Energieverbrauch $P = P_{switching} + P_{leakage} + ...$
\end{itemize*}
Schaltleistung $P_{switching}$
\begin{itemize*}
\item $P_{switching}$: für Schaltvorgänge notwendige Leistung
\item Energiebedarf kapaz. Lade-/Entladevorgänge während Schaltens
\item Einsparpotenzial: Verringerung von Versorgungsspannung (quadratische Abhängigkeit) und Taktfrequenz
\item[$\rightarrow$] längere Schaltvorgänge, größere Latenz zwischen Schaltvorgängen
\item[$\Rightarrow$] Energieeinsparung nur mit Qualitätseinbußen
%\item Anpassung des Lastprofils (Zeit-Last? Fristen kritisch?)
%\item Beeinträchtigung der Nutzererfahrung (Reaktivität?)
\end{itemize*}
Verlustleistung $P_{leakage}$
\begin{itemize*}
\item $P_{leakage}$: Verlustleistung durch verschiedene Leckströme
\item Energiebedarf baulich bedingter Leckströme
\item Hardware-Miniaturisierung $\rightarrow$ zunehmender Anteil $P_{leakage}$ an P
\item[$\Rightarrow$] Leckströme kritisch für energiesparenden Hardwareentwurf
\end{itemize*}
Regelspielraum: Nutzererfahrung
\begin{itemize*}
%\item Nutzererwartung wichtigstes Kriterium durch Nutzer
\item Nutzererwartung bestimmt Nutzererfahrung
\item Typ einer Anwendung entscheidet über jeweilige Nutzererwartung
\begin{enumerate*}
\item Hintergrund (Compiler): Bearbeitungsdauer, Durchsatz
\item Echtzeit (Video-Player): Abspielen von Video, Musik
\item Interaktiv (Webbrowser): Reaktivität, keine Verzögerung
\end{enumerate*}
\item Insbesondere kritisch: Echtzeit-/interaktive Anwendungen
\item Reaktivität: Reaktion von Anwendungen; abhängig z.B. von
\begin{description*}
\item[Hardware] an sich
\item[Energieversorgung] der Hardware z.B. Spannungspegel
\item[Software-Gegebenheiten] z.B. Scheduling, Management
\end{description*}
\end{itemize*}
\subsubsection{Energieeffizientes Scheduling}
\begin{itemize*}
\item Probleme mit Energiesparen: Fairness \& Prioritätsumkehr
%\item Beispiel: Round Robin (RR) mit Prioritäten
%\begin{itemize*}
% \item $E_i^{budget}$ ... Energiebudget von $t_i$
% \item $E_i^{limit}$ ... Energielimit von $t_i$
% \item $P_{limit}$ ... maximale Leistungsaufnahme [Energie/Zeit]
% \item $T$ ... resultierende Zeitscheibenlänge
%\end{itemize*}
\end{itemize*}
\begin{description*}
\item[Problem 1] Unfaire Energieverteilung
%\item Beschränkung des Energieverbrauchs (durch Qualitätseinbußen, schlimmstenfalls Ausfall) ab einem oberen Schwellwert $E_{max}$
\item[Problem 2] energieintensive Threads behindern nachfolgende Threads gleicher Priorität
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-round-robin-unfair.png} \end{itemize*}
\item[Problem 3] energieintensive Threads niedrigerer Priorität behindern spätere Threads höherer Priorität
%\begin{itemize*}
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-prioritätsumkehr.png}
%\end{itemize*}
\end{description*}
\begin{itemize*}
\item RR Strategie 1: faire Energieverteilung (einheitliche E-Limits)
\begin{itemize*}
\item $E_i^{limit} = P_{limit}* T$ %(Abweichungen = Wichtung der Prozesse $\rightarrow$ bedingte Fairness)
\item gewichtete Aufteilung begrenzter Energie %optimiert Energieeffizienz
\item Problem: lange, wenig energieintensive Threads verzögern Antwort-und Wartezeiten kurzer, energieintensiver Threads
%\item Lösung im Einzelfall: Wichtung per $E_i^{limit}$
%\item globale Reaktivität $\rightarrow$ Nutzererfahrung?
\end{itemize*}
\item RR Strategie 2: maximale Reaktivität ( $\rightarrow$ klassisches RR)
\begin{itemize*}
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-energiebewusstes-rr-reaktivität.png}
\item Problem: sparsame Threads werden bestraft durch Verfallen des ungenutzten Energiebudgets
\item Idee: Ansparen von Energiebudgets $\rightarrow$ mehrfache Ausführung eines Threads innerhalb einer Periode
\end{itemize*}
\item RR Strategie 3: Reaktivität, dann faire Energieverteilung
%\begin{itemize*}
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-energiebewisstes-rr-2.png}
%\end{itemize*}
\end{itemize*}
Implementierungsfragen
\begin{itemize*}
%\item Kosten ggü. klassischem RR? (durch Prioritäten...?)
%\item Scheduling-Zeitpunkte?
%\item Datenstrukturen? Wo gelagert?
%\begin{itemize*}
% \item ... im Scheduler $\rightarrow$ Warteschlange(n)?
% \item ... im Prozessdeskriptor?
%\end{itemize*}
\item Pro
\begin{itemize*}
\item Optimierung der Energieverteilung nach Schedulingzielen
\item Berücksichtigung prozessspezifischer Verbrauchsmuster
\end{itemize*}
\item Kontra
\begin{itemize*}
\item sekundäre Kosten: Energiebedarf des Schedulers, Kontextwechsel, Implementierungskosten
\item Voraussetzung: Monitoring des Energieverbrauchs
\end{itemize*}
\item \textbf{Alternative:} energieintensive Prozesse verlangsamen $\rightarrow$ Regelung der CPU-Leistungsparameter
\end{itemize*}
\subsubsection{Systemglobale Energieeinsparungsmaßnahmen}
\begin{itemize*}
\item Traditionelle: zu jedem Zeitpunkt Spitzen-Performanz angestrebt
\begin{itemize*}
\item viele Anwendungen benötigen keine Spitzen-Performanz
\item viel Hardware-Zeit in Leerlaufsituationen bzw. keine Spitzen-Performanz erforderlich
\end{itemize*}
\item Konsequenz (besonders für mobile Systeme)
\begin{itemize*}
\item Hardware mit Niedrigenergiezuständen
\item Betriebssystem kann \textbf{Energie-Management} realisieren
\end{itemize*}
\end{itemize*}
\subsubsection{Hardwaretechnologien}
DPM: Dynamic Power Management
\begin{itemize*}
\item versetzt leerlaufende Hardware selektiv in Zustände mit niedrigem Energieverbrauch
\item Zustandsübergänge durch Power-Manager gesteuert, bestimmte \emph{DPM-}Strategie (Firmware) zugrunde, um gutes Verhältnis zwischen Performanz und Energieeinsparung zu erzielen
\item bestimmt, wann \& wie lange eine Hardware in Energiesparmodus
\end{itemize*}
\begin{description*}
\item[Greedy] Hardware-Komponente sofort nach Erreichen des Leerlaufs in Energiesparmodus, ,,Aufwecken'' durch neue Anforderung
\item[Time-out] Energiesparmodus erst nachdem ein definiertes Intervall im Leerlauf, ,,Aufwecken'' wie bei Greedy-Strategien
\item[Vorhersage] Energiesparmodus sofort nach Erreichen des Leerlaufs, wenn Heuristik vorhersagt, dass Kosten gerechtfertigt
\item[Stochastisch] Energiesparmodus auf Grundlage stochastischen Modells
\end{description*}
DVS: Dynamic Voltage Scaling
\begin{itemize*}
\item effizientes Verfahren zur dynamischen Regulierung von Taktfrequenz gemeinsam mit Versorgungsspannung
\item Nutzung quadratischer Abhängigkeit der dynamischen Leistung von Versorgungsspannung
\item Steuerung/Strategien: Softwareunterstützung notwendig
\item Ziel: Unterstützung von DPM-Strategien durch Maßnahmen auf Ebene von Compiler, Betriebssystem und Applikationen
\item \textbf{Betriebssystem} (prädiktives Energiemanagement)
\begin{itemize*}
\item kann Benutzung verschiedener Ressourcen beobachten
\item kann darüber Vorhersagen tätigen
\item kann notwendigen Performanzbereich bestimmen
\end{itemize*}
\item \textbf{Anwendungen} können Informationen über jeweils für sie notwendige Performanz liefern
\item[$\rightarrow$] Kombination mit energieefizientem Scheduling
\end{itemize*}
\subsection{Speichereffizienz}
\begin{itemize*}
\item ... heißt: Auslastung des verfügbaren Speichers
\item oft implizit: Hauptspeicherauslastung (memory footprint)
\item für kleine/mobile Systeme: Hintergrundspeicherauslastung
\item Maße zur Konkretisierung:
\begin{itemize*}
\item zeitlich: Maximum vs. Summe genutzten Speichers?
\item physischer Speicherverwaltung? $\rightarrow$ Belegungsanteil pAR
\item virtuelle Speicherverwaltung? $\rightarrow$ Belegungsanteil vAR
\end{itemize*}
\item Konsequenzen für Ressourcenverwaltung durch BS
\begin{itemize*}
\item Taskverwaltung (Accounting, Multiplexing, Fairness, ...)
\item Programmiermodell, API (dyna. Speicherreservierung)
\item Strategien virtueller Speicherverwaltung (VMM)
\end{itemize*}
\item Konsequenzen für Betriebssystem selbst
\begin{itemize*}
\item minimaler Speicherbedarf durch Kernel
\item minimale Speicherverwaltungskosten (obiger Aufgaben)
\end{itemize*}
\end{itemize*}
\subsubsection{Hauptspeicherauslastung}
%\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-speicherverwaltung.png}
Problem: externe Fragmentierung
\begin{itemize*}
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-externe-fragmentierung.png}
\item Lösungen: First Fit, Best Fit, WorstFit, Buddy, Relokation
\item Kompromissloser Weg: kein Multitasking
\end{itemize*}
Problem: interne Fragmentierung
\begin{itemize*}
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-interne-fragmentierung.png}
\item Lösung: Seitenrahmengröße verringern ABER dichter belegte vAR $\rightarrow$ größere Datenstrukturen für Seitentabellen
\item direkter Einfluss des Betriebssystems auf Hauptspeicherbelegung
\begin{itemize*}
\item[$\rightarrow$] Speicherbedarf des Kernels
\item statische (min) Größe des Kernels (Anweisungen+Daten)
\item dynamische Speicherreservierung durch Kernel
\item bei Makrokernel: Speicherbedarf von Gerätecontrollern
\end{itemize*}
\end{itemize*}
weitere Einflussfaktoren: Speicherverwaltungskosten
\begin{itemize*}
\item VMM: Seitentabellengröße $\rightarrow$ Mehrstufigkeit
\item Metainformationen über laufende Programme: Größe von Taskkontrollblöcken (Prozess-/Threaddeskriptoren ...)
\item dynamische Speicherreservierung durch Tasks
\end{itemize*}
\subsubsection{Hintergrundspeicherauslastung}
Einflussfaktoren des Betriebssystems
\begin{itemize*}
\item statische Größe des Kernel-Images, beim Bootstrapping gelesen
\item statische Größe von Programm-Images (Standards wie ELF)
\item statisches vs. dynamisches Einbinden von Bibliotheken
\item VMM: Größe des Auslagerungsbereichs (inkl. Teilen der Seitentabelle) für Anwendungen
\item Modularisierung (zur Kompilierzeit) des Kernels: gezielte Anpassung an Einsatzdomäne möglich
\item Adaptivität (zur Kompilier-und Laufzeit) des Kernels: gezielte Anpassung an sich ändernde Umgebungsbedingungen möglich
\end{itemize*}
\subsection{Architekturentscheidungen}
\begin{itemize*}
\item typische Einsatzgebiete sparsamer BS: eingebettete Systeme
\item eingebettetes System
\begin{itemize*}
%\item Computersystem, das in ein größeres technisches System, welches nicht zur Datenverarbeitung dient, physisch eingebunden ist
\item Wesentlicher Bestandteil größerer Systems
\item Liefert Ausgaben in Form von Informationen/Daten
\end{itemize*}
\item spezielle, anwendungsspezifische Ausprägung der Aufgaben
\begin{itemize*}
\item reduzierter Umfang von HW-Abstraktion, hardwarenah %-nähere Ablaufumgebung
\item begrenzte Notwendigkeit von HW-Multiplexing \& Schutz
\end{itemize*}
\item sparsame Betriebssysteme
\begin{description*}
\item[energieeffizient] geringe Architekturanforderungen an energieintensive Hardware
\item[speichereffizient] Auskommen mit kleinen Datenstrukturen
\end{description*}
\item[$\Rightarrow$] geringe logische Komplexität des Betriebssystemkerns
\item sekundär: Adaptivität des Betriebssystemkerns
\end{itemize*}
\subsubsection{Makrokernel (monolithischer Kernel)}
%\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-makrokernel.png}
\begin{itemize*}
\item User Space
\begin{itemize*}
\item Anwendungstasks
\item CPU im unprivilegierten Modus (Unix ,,Ringe'' 1...3)
\item Isolation von Tasks durch Programmiermodell/VMM
\end{itemize*}
\item Kernel Space
\begin{itemize*}
\item Kernel und Gerätecontroller (Treiber)
\item CPU im privilegierten Modus (Unix ,,Ring'' 0)
\item keine Isolation
\end{itemize*}
\item Vergleich
\begin{itemize*}
\item[\cmark] vglw. geringe Kosten von Kernelcode (Energie, Speicher)
\item[\cmark] VMM nicht zwingend erforderlich
\item[\cmark] Multitasking nicht zwingend erforderlich
\item[\xmark] Kernel (inkl. Treibern) jederzeit im Speicher
\item[\xmark] Robustheit, Sicherheit, Adaptivität
\end{itemize*}
\end{itemize*}
\subsubsection{Mikrokernel}
%\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-mikrokernel.png}
\begin{itemize*}
\item User Space
\begin{itemize*}
\item Anwendungstasks, Kernel- und Treibertasks
\item CPU im unprivilegierten Modus
\item Isolation von Tasks durch VMM
\end{itemize*}
\item Kernel Space
\begin{itemize*}
\item funktional minimaler Kernel ($\mu$Kernel)
\item CPU im privilegierten Modus
\item keine Isolation (Kernel wird in alle vAR eingeblendet)
\end{itemize*}
\item Vergleich
\begin{itemize*}
\item[\cmark] Robustheit, Sicherheit, Adaptivität
\item[\cmark] Kernelspeicherbedarf gering, Serverprozesse nur wenn benötigt ( $\rightarrow$ Adaptivität)
\item[\xmark] hohe IPC-Kosten von Serverprozessen
\item[\xmark] Kontextwechselkosten von Serverprozessen
\item[\xmark] VMM, Multitasking i.d.R. erforderlich
\end{itemize*}
\end{itemize*}
\subsubsection{BS: TinyOS}
\begin{itemize*}
\item Beispiel für sparsame BS im Bereich eingebetteter Systeme
\item verbreitete Anwendung: verteilte Sensornetze (WSN)
\item für drahtlose Geräte mit geringem Stromverbrauch
\item Architektur: monolithisch (Makrokernel) mit Besonderheiten
\begin{itemize*}
\item keine klare Trennung zwischen der Implementierung von Anwendungen und BS (aber von funktionalen Aufgaben)
\item[$\rightarrow$] zur Laufzeit: 1 Anwendung + Kernel
\end{itemize*}
\item Mechanismen
\begin{itemize*}
\item kein Multithreading, keine echte Parallelität
\item[$\rightarrow$] keine Synchronisation zwischen Tasks
\item[$\rightarrow$] keine Kontextwechsel bei Taskwechsel
\item Multitasking realisiert durch Programmiermodell
\item nicht-präemptives FIFO-Scheduling
\item kein Paging $\rightarrow$ keine Seitentabellen, keine MMU
\end{itemize*}
\item in Zahlen
\begin{itemize*}
\item Kernelgröße: 400 Byte
\item Kernelimagegröße: 1-4 kByte
\item Anwendungsgröße: typisch ca. 15 kB, DB: 64 kB
\end{itemize*}
\item Programmiermodell
\begin{itemize*}
\item BS+Anwendung als Ganzes übersetzt: statische Optimierungen durch Compiler (Laufzeit, Speicherbedarf)
\item Nebenläufigkeit durch ereignisbasierte Kommunikation zw. Anwendung und Kernel (command \& event)
%\begin{itemize*}
% \item command: API-Aufruf, z.B. EA-Operation
% \item event: Reaktion auf diesen durch Anwendung
%\end{itemize*}
%\item sowohl commands als auch events : asynchron
\end{itemize*}
\end{itemize*}
\subsubsection{BS: RIOT}
\begin{itemize*}
\item sparsames BS, optimiert für anspruchsvollere Anwendungen
\item Open-Source-Mikrokernel-basiertes Betriebssystem für IoT
\item Architektur: Mikrokernel
\begin{itemize*}
\item minimale Algorithmenkomplexität
\item vereinfachtes Threadkonzept $\rightarrow$ keine Kontextsicherung erforderlich
\item keine dynamische Speicherallokation
\item energiesparende Hardwarezustände vom Scheduler ausgelöst (inaktive CPU)
\item Mikrokerneldesign unterstützt komplementäre NFE: Adaptivität, Erweiterbarkeit
\item Kosten: IPC (hier gering)
\end{itemize*}
\item Mechanismen
\begin{itemize*}
\item Multithreading-Programmiermodell
\item modulare Implementierung von Dateisystemen, Scheduler, Netzwerkstack
\end{itemize*}
\item in Zahlen
\begin{itemize*}
\item Kernelgröße: 1,5 kByte
\item Kernelimagegröße: 5 kByte
\end{itemize*}
\end{itemize*}
\pagebreak
\pagebreak
\section{Robustheit und Verfügbarkeit}
\begin{itemize*}
\item allgemein: verlässlichkeitskritische Anwendungsszenarien
\item z.B. Forschung in garstiger Umwelt (Weltraum)
\item hochsicherheitskritische Systeme (Finanz, Cloud Dienste)
\item hochverfügbare System (öffentliche Infrastruktur, Strom)
%\item HPC (high performance computing)
\item \textbf{Verlässlichkeit} Fähigkeit, eine Leistung zu erbringen, der man berechtigterweise vertrauen kann
\item Untereigenschaften
\begin{enumerate*}
\item Verfügbarkeit (availability)
\item Robustheit (robustness, reliability
\item (Funktions-) Sicherheit (safety)
\item Vertraulichkeit (confidentiality)
\item Integrität (integrity)
\item Wartbarkeit (maintainability)
\end{enumerate*}
\item[$\rightarrow$] nicht immer sind alle Untereigenschaften erforderlich
\end{itemize*}
\subsection{Robustheitsbegriff}
\begin{description*}
\item[Ausfall] beobachtbare Verminderung der Leistung eines Systems, gegenüber seiner als korrekt spezifizierten Leistung
\item[Robustheit] Verlässlichkeit unter Anwesenheit externer Ausfälle (= Ursache außerhalb des betrachteten Systems)
\end{description*}
\begin{itemize*}
\item Fehler $\rightarrow$ fehlerhafter Zustand $\rightarrow$ Ausfall
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-fehler.png}
\end{itemize*}
\begin{description*}
\item[Ausfall] (failure) liegt vor, wenn tatsächliche Leistung(en), die ein System erbringt, von als korrekt spezifizierter Leistung abweichen
\begin{itemize*}
\item Korrektheit testen/beweisen( $\rightarrow$ formale Verifikation)
\end{itemize*}
\item[fehlerhafter Zustand] (error) notwendige Ursache eines Ausfalls (nicht jeder error muss zu failure führen)
\begin{itemize*}
\item Maskierung, Redundanz, Isolation von Subsystemen
\item[$\rightarrow$] Isolationsmechanismen
\end{itemize*}
\item[Fehler] (fault) Ursache für fehlerhaften Systemzustand (error)%, z.B. Programmierfehler
\begin{itemize*}
\item Ausfallverhalten spezifizieren, zur Laufzeit erkennen und Folgen beheben%, abschwächen...
\item[$\rightarrow$] Micro-Reboots
\end{itemize*}
\end{description*}
\subsection{Fehlerhafter Zustand}
%interner und externer Zustand (internal \& external state)
\begin{description*}
\item[externer Zustand] Teil des Gesamtzustands, an externer Schnittstelle sichtbar
\item[interner Zustand] restlicher Teilzustand
\item[erbrachte Leistung] zeitliche Folge externer Zustände
\end{description*}
%Fehlerausbreitung und (externer) Ausfall
\begin{itemize*}
\item Wirkungskette: Treiber-Programmierfehler (fault) $\rightarrow$ fehlerhafter interner Zustand des Treibers (error)
\begin{itemize*}
\item Ausbreitung dieses Fehlers (failure des Treibers)
\item[$\Rightarrow$] fehlerhafter externer Zustand des Treibers
\item[$\Rightarrow$] fehlerhafter interner Zustand des Kernels (error)
\item[$\Rightarrow$] Kernelausfall (failure)
\end{itemize*}
\item Auswirkung: fehlerhafter Zustand weiterer Kernel-Subsysteme
\item[$\rightarrow$] Robustheit: Isolationsmechanismen
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-treiber-kernel-fehler.png}
\end{itemize*}
\subsection{Isolationsmechanismen}
\begin{itemize*}
\item Isolationsmechanismen für robuste Betriebssysteme
\begin{itemize*}
\item durch strukturierte Programmierung
\item durch Adressraumisolation
\end{itemize*}
\item noch mehr für sichere Betriebssysteme
\begin{itemize*}
\item durch kryptografische Hardwareunterstützung: Enclaves
\item durch streng typisierte Sprachen und managed code
\item durch isolierte Laufzeitumgebungen: Virtualisierung
\end{itemize*}
\end{itemize*}
\subsubsection{Strukturierte Programmierung}
Monolithisches BS... in historischer Reinform
\begin{itemize*}
\item Anwendungen, Kernel, gesamte BS-Funktionalität
\item programmiert als Sammlung von Prozeduren
\item jede darf jede davon aufrufen, keine Modularisierung
\item keine definierten internen Schnittstellen
\end{itemize*}
Monolithisches Prinzip
\begin{itemize*}
\item Ziel: Isolation zwischen Anwendungen und Betriebssystem
\item Mechanismus: Prozessor-Privilegierungsebenen (user/kernelspace)
\item Konsequenz: fast keine Strukturierung des Kernels
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-systemaufruf.png}
\end{itemize*}
Strukturierte Makrokernarchitektur
\begin{itemize*}
\item schwach strukturierter (monolithischer) Makrokernel
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-makrokernelarchitektur.png}
\item[$\Rightarrow$] Schichtendifferenzierung ( layered operating system )
\item Modularisierung
\end{itemize*}
Modularer Makrokernel
\begin{itemize*}
\item Kernelfunktionen in Module unterteilt $\rightarrow$ Erweiter-/Portierbarkeit
\item klar definierte Modulschnittstellen
\item Module zur Kernellaufzeit dynamisch einbindbar (Adaptivität)
\end{itemize*}
\paragraph{Fehlerausbreitung beim Makrokernel}
\begin{itemize*}
\item[\cmark] Wartbarkeit
\item[\cmark] Portierbarkeit
\item[\cmark] Erweiterbarkeit
\item (begrenzt) Adaptivität
\item Schutz gegen statische Programmierfehler nur durch Compiler
\item[\xmark] kein Schutz gegen dynamische Fehler
\end{itemize*}
\subsubsection{Adressraumisolation}
Private virtuelle Adressräume und Fehlerausbreitung
\begin{itemize*}
\item private virtuelle Adressräume zweier Tasks ($i\not= j$)
%\item private virtuelle vs. physischer Adresse
%\begin{itemize*}
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-virtuelle-vs-physische-adresse.png}
%\end{itemize*}
\item korrekte private vAR: kollisionsfreie Seitenabbildung
\item Magie in Hardware: MMU (BS steuert und verwaltet...)
\end{itemize*}
Robustheit: Vorteil von privaten vAR?
\begin{itemize*}
\item[\cmark] nichtvertrauenswürdiger Code kann keine beliebigen physischen Adressen schreiben
\item[\cmark] Kommunikation zwischen nvw. Code muss durch IPC-Mechanismen explizit hergestellt werden $\rightarrow$ Überwachung und Validierung zur Laufzeit möglich
\item[\cmark] Kontrollfluss begrenzen: Funktionsaufrufe können i.A. keine AR-Grenzen überschreiten
%\begin{itemize*}
%\item[$\rightarrow$] BS-Zugriffssteuerung kann nicht durch Taskfehler ausgehebelt werden
%\item[$\rightarrow$] unabsichtliche Terminierungsfehlererschwert ...%(unendliche Rekursion)
%\end{itemize*}
\item keine Isolation zwischen Fehlern innerhalb des Kernels
\end{itemize*}
\subsection{Mikrokernelarchitektur}
\begin{itemize*}
\item strenger durchgesetzt durch konsequente Isolation voneinander unabhängiger Kernel-Subsysteme
\item zur Laufzeit durchgesetzt $\rightarrow$ Reaktion auf fehlerhafte Zustände möglich
\item zusätzlich zu vertikaler Strukturierung: horizontal
\begin{itemize*}
\item[$\rightarrow$] funktionale Einheiten: vertikal (Schichten)
\item[$\rightarrow$] isolierte Einheiten: horizontal (private vAR)
\end{itemize*}
\item[$\Rightarrow$] Kernel (alle BS-Funktionalität) $\rightarrow$ $\mu$Kernel (minimale BS-Funk.)
\item Rest: ,,gewöhnliche'' Anwendungsprozesse mit AR-isolation
\item Kommunikation: botschaftenbasierte IPC (client-server OS)
\item Nomenklatur: Mikrokernel und Serverprozesse
\end{itemize*}
\subsubsection{Modularer Makrokernel vs. Mikrokernel}
\begin{itemize*}
\item minimale Kernelfunktionalität
\item keine Dienste, nur allgemeine Schnittstellen für diese
\item keine Strategien, nur grundlegende Mechanismen zur Ressourcenverwaltung
\item neues Problem: minimales Mikrokerneldesign
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-modularer-makrokernel-2.png}
\end{itemize*}
\paragraph{Robustheit von Mikrokernen}
\begin{itemize*}
\item[=] Gewinn durch Adressraumisolation innerhalb des Kernels
\item[\cmark] kein nichtvertrauenswürdiger Code im Kernelspace, der dort beliebige physische Adressen manipulieren kann
\item[\cmark] Kommunikation zwischen nvw. Code muss durch IPC explizit hergestellt werden $\rightarrow$ Überwachung und Validierung zur Laufzeit
\item[\cmark] Kontrollfluss begrenzen: Zugriffssteuerung auch zwischen Serverprozessen, zur Laufzeit unabhängiges Teilmanagement von Code möglich %(z.B.: Nichtterminierung erkennen)
\item Neu:
\item[\cmark] nvw. BS-Code muss nicht mehr im Kernelspace laufen
\item[\cmark] Kernel: klein, funktional weniger komplex, leichter zu entwickeln, zu testen, evtl. formal zu verifizieren
\item[\cmark] Adaptivität durch konsequentere Modularisierung des Kernels
\end{itemize*}