FHNW: bsys 2

• Erhöhte Komplexität
• Erschwerte Fehlersuche
• Verlängerte Abhängigkeitsketten (Netzwerk z.B.)
• Sicherheitsdispositiv wird aufwendiger (Wiederherstellen eines Fehlers fast unmöglich)
• Nicht alle Subsysteme (Hard- und Software) eignen sich für die Verteilung
• Sicherstellung der Konsistenz und Synchronisation

Real-Time Systeme können nicht verteilt werden, da die Zugriff auf Resourcen oder Priorisierung nicht zuverlässig garantiert ist. 

• Gemeinsamer Kernel Code und System Calls
• Gemeinsamer Hauptspeicher (Page Table mit einer weiteren Spalte erweitern, welche Netzwerkadresse beinhaltet)
• Gemeinsames Prozess-Steuersystem
• Gemeinsames Dateisystem (NFS, UUID, GUID, Rechte...)
• Gemeinsame Interprozess-Kommunikation
• Gemeinsame Ausnahmebehandlung
• Gemeinsame Synchronisationsmechanismen
• Gemeinsames Systemmanagement
• Spezialisierte Funktionen für das Management der Verteilung
• Transparente Benutzerschnittstelle

Für den Benutzer sowie für die Applikation eines verteilten Systems ist die Art der Verteilung nicht relevant und idealerweise auch nicht ersichtlich. Das System verhält sich transparent (i.S.v. durchsichtig), als hätte der Nutzer es mit einem Gesamtsystem zu tun.

• Ortstransparenz: Der Ort der genutzten Resourcen / erbrachten Dienste ist für den Anwender nicht sichtbar.
• Migrationstransparenz: Ressourcen können verlagert werden, ohne dass sich ihr Name bzw. Nutzung verändert.
• Replikationstransparenz: Anwender können nicht erkennen, wie viele Instanzen es gibt.
• Nebenläufigkeitstransparenz: Mehrere Anwender können die Ressourcen automatisch gemeinsam und unabhängig voneinander nutzen.
• Parallelitätstransparenz: Aktivitäten können parallel bzw. nebenläufig ausgeführt werden, ohne dass der Anwender es bemerkt.

• Services sollen dynamisch an den Bedarf anpassbar sein, entweder durch administrative Eingriffe oder durch Eigenkonfiguration zur Laufzeit
• Änderungen sollen keinen kompletten Neustart des verteilten Systems erfordern.

• Verteilungs- und Kommunikations-Mehraufwand muss den Aufwand wert sein.
• Wiederholbarkeit / Determinismus von Leistungsindikatoren 
• Abhängigkeit von nicht direkt kontrollierbaren Komponenten (z.B. LAN)
• End-zu-End Performance statt Komponenten-Performance

• Angebotseite:
  • Statische oder dynamische Zufügung / Wegnahme von Servern
  • Verrechnung: Durchschnitt oder peaks?
  • Vermeiden von Flaschenhälsen durch starke Serialisierung (Applikationskomponenten, Datenstrukturen, Algorithmen)
• Dienstnehmerseite:
  • Nicht vorhersagbare Anzahl Dienstnehmer (Mit wem teile ich das System? Unbekannt)
  • Einhaltung von Dienstgütgegarantien

• Erhöhte Zuverlässigkeit gegenüber Einzelsystemen trotz additiver Ausfallwahrscheinlichkeiten (Redundanz).
• End-zu-End Verfügbarkeit statt Komponentenverfügbarkeit (Vertikale Verfügbarkeit)
• Sicherheit: Gleiche Richtlinien und Umsetzung im gesamten verteilten System
• Fehlertoleranz (versus Overhead)
• Automatisches Recovery von Komponenten

• Microkernel-Architektur: Auslagerung grosser teile des ursprünglichen Kernel-Codes in den User-Level
• Beinhaltet keine Security: Die Services sind nicht durch den Kernel geschützt (siehe Bild).
• Derivate: MachTen, Mac OS X, iOS
• Kernel Elemente:
  • Task: Umgebung um Prozesse auszuführen. Er beinhaltet einen virtuellen Adressraum, Ports zur Kommunikation und mindestens einem Thread.
  • Thread: Ein Task kann mehrere nebenläufige Threads enthalten. Diese verwenden alle die Resourcen eines Tasks (Speicher, Ports, etc.)
  • Port: Einfacher Kommunikationskanal. Zugriffe werden vom Kernel kontrolliert (Port Rights).
  • Nachrichten: Werden zwischen Tasks und Kernel über Ports ausgetauscht.
  • Memory Objects: Speicher für Tasks. 

Generell gilt das Vorstellen der Zeit einfacher ist als das Rückstellen (Banksysteme)

• Absolut: (Zeit-Server durch Network Time Protocol oder eigene Referenzuhr durch Peripheriegerät)
• Relativ: Median von mehreren Quellen (intern und extern) oder Lokalzeit nutzen, falls Abweichungen gross sind

Semaphore and Monitor that protected critical section in single system are no longer appropriated in distributed systems. So in distributed systems, we must use a special algorithm to achieve mutual exclusion. There are 3 basic algorithms to be considered and work as a baseline for developing another mutual exclusion algorithm in distributed systems.
Those 3 are:

• Centralized algorithm:
  • Reliable and deterministic
  • Strong serialization
• Distributed algorithm:
  • Sends messages to all processes and waits for responses (reliable messaging necessary)
• Token ring algorithm:
  • Explicit permission to access in a pre-determined order
  • Not optimized usage of resources and waiting time

Image Depicts Centeralized Algorithm

• Eng gekoppelt:
  • (Non-Uniform Memory Access) NUMA: Hardware Multiprozessoren mit diversen Prozessoren am gleichen Bussystem.
• Lose gekoppelt:
  • Distributed Shared Memory (DSM): Ein Seitenladefehler wird dadurch aufgelöst, dass eine Seite nicht von der lokalen Disk geladen wird, sondern von einer entfernten Disk
  • Schlechte Performance, lange Netz-Wartezeiten
  • Optimierung durch Anlage nur der gemeinsam benutzten Datenstrukturen auf gemeinsam genutzten Seiten, alle anderen Seiten bleiben lokal.

• Monolit präferiert Effizienz vor Robustheit
• Eine Schichtenarchitektur des Betriebssystems fördert die Robustheit durch die Anordnung von Funktionalität in gegeneinander abgrenzte Shichten mit unterschiedlichen Privilegien.
• Eine Microkernel-Architektur präferiert Robustheit vor Effizienz
   
• Monolithic kernels are faster than microkernels. The first microkernel Mach was 50% slower than Monolithic kernel, while later version like L4 were only 2% or 4% slower than the Monolithic kernel.
• Monolithic kernels generally are bulky. A pure Microkernel has to be small in size, to fit into the processor's L1 cache (first generation microkernel).
•  Adding a new feature to a monolithic system means recompiling the whole kernel, whereas with microkernels you can add new features or patches without recompiling.

• Lieferwege (physisch, aber vor allem elektronisch)
• Software-Voreinstellungen (Defaults)
• Funktionale Fehler der Software / Ausnutzbarkeit von Nebeneffekten
• Nicht getestete oder nicht autorisierte Änderungen
• Fremd-/Fernzugriffe oder Auslagerung aus dem Sicherheitskontext
• Benutzer und Administrator

Unix

• Fehlerhafte Default Konfigurationen
• Unnoetige Services / Ports
• Zu wenig restriktive Zugriffsrechte
• Technische Benutzer ohne oder mit schlechten Passworte
• Brute Force Passwort-Angriffe auf Dienste wie telnet, ftp, ssh
• Ausnutzung von Software-Schwachstellen (Memory Overflow, Authentifizierung, etc.)

Windows

• Angriffe auf Service Control Programme (SCP)
• Unbenötigte Services
• Lokale Administrationsrechte
• Ausnutzung von Software-Schwachstellen

• Verfügbarkeit
• Vertraulichkeit
• Korrektheit
• Zeitliche Abfolge
• Bereitstellungstermin
• Identität / Autorisierung
• Handlungsfähigkeit
• Guter Ruf / Image

• Identifikation relevanter Systeme oder Applikationen
• Technische Überprüfung (Security Scan, Penetration Testing, Audits, Ethical Hacking)
• Organisatorische Überprüfung (ICT Bedrohungs- Risikoanalyse)
• Programme mit Verbindung zur Aussenwelt gegen Missbrauch und unitendierte Benutzung schützen
• Definition des Massnahmekatalogs zur Erhöhung des Sicherheitsniveaus

1. Wartungsverträge: Die Kunden haben die Systeme bereits im Einsatz.
2. Zuverlässigkeit: Funktioniert auch weiterhin bei einem Teilausfall
3. Rechenleistung: Grossrechner haben eine sehr hohe Leistung.
4. 100% Up-Time Policy: Updates können eingespielt werden, ohne das System oder Subsysteme abschalten zu müssen.
5. Rückwärtskompatibilität: Alte Funktionalität wird laufend unterstützt. Viele können/wollen ihre Anwendungen oder andere Abhängigkeiten nicht aktualisieren. (Never touch a running system)
6. Hardware / Software: Der Lieferant der Hardware und Software (OS) kommt vom gleichen Hersteller (IBM).
7. Gewohnheit / Zufriedenheit: Kunden sind bereits auf z/OS geschult und zufrieden. Umstellung bedeutet hohe Kosten und Aufwand.

Windows ist sehr weit verbreitet (vor allem im Endkonsumermarkt) was das Hacken und schreiben von Malware lohnenswert macht.

Zudem kommen die Security-Patches bei Linux sehr schnell raus. Teilweise sogar innert wenigen Stunden. Bei Windows (und auch Mac OS) kann es länger dauern, bis die Sicherheitslücken geschlossen sind.

1. Identifikation relevanter Applikationen oder Systeme: herausfinden, was betroffen ist.
2. Technische Überprüfung: Security Scan, Ethical Hacking oder Audit. Herausfinden wie sicher das eigene System ist.
3. Organisatorische Überprüfung: Eine Risikoanalyse machen und ICT-Bereich überprüfen.
4. Massnahmenkatalog erstellen: Erhöht das Sicherheitsniveau und garantiert einen fehlerfreien Ablauf im Ernstfall:
5. Default Installation hinterfragen: Kritisch anschauen, was per Default auf dem ist und ggf. anpassen
6. Konfigurationsänderungen: Rechte + Rollen an die User verteilen, gem. ihrem Aufgabenbereich. 
7. Zugriffe einschränken: Zugriffe von aussen auf bekannte IPs einschränken. (Generell Netzwerkkonfiguration: Ping erlauben, UDP, etc.)
8. Updates: Sicherheitsrelevante Security-Updates des Systems zeitnah installieren
9. Schnittstellen abbauen: Nicht benötigte Hardware, Software abschalten oder Dienste deaktivieren.
10. Zusatzsoftware: Installation von sicherheitsspezifischen Zusatzsoftware
11. Zyklische Überprüfung: Neuüberprüfungen von aussen oder innen (Scans mit Secunia z.B.)
12. Verbesserung: Veränderung / Verbesserung im Betriebsablauf oder Überwachung
13. Auswertung: Auswertung echter Angriffsversuche oder Kollateralinformation

1. Initiale Härtung: Garantieren das alle Systeme einem gewissen Standard entsprechen. Die Systeme sollen zuerst einheitlich gehärtet werden.
2. Zyklische SW Überprüfung: Schauen ob SW aktuell ist und ob es Security Patches gibt
3. Zyklische Prots Überprüfung: Schauen ob neue und unnötige Ports geöffnet wurden
4. User Schulung: Den Mitarbeitenden wie sie mit IT und deren Sicherheit umgehen müssen. Best Practices etc.

Ein Prozess muss seinen Ausführungskontext unterbrechen, abspeichern (im PCB), zum neuen Kontext wechseln, im neuen Kontext ablaufen, den alten Kontext wiederherstellen und neu starten können (Aufgabe des Kernels).

Context-Switching ist purer Overhead, weil das System in der Zeit des Auswechselns nichts sinnvolles macht.

Der Scheduler teilt Prozessen Rechenzeit zu und sequentialisiert damit die nebenläufige Ausführung von Prozessen oder Threads auf einer oder mehreren CPUs. Bei genügender Performance des Systems geschieht dies so rasch, dass für den Benutzer der Eindruck der Parallelität entsteht. 

• Modell 1: Prozess wartet aktiv auf das Eintreffen einer Nachricht (busy waiting). Sofortige Erkennung ist dadurch möglich, aber es verbraucht nutzlos Rechenzeit. Zudem sind keine nebenläufige Aktivitäten im Prozess möglich.
   
• Modell 2: Prozess wartet (schläft) auf das Eintreffen eines Wecksignals. Der Signal-Mechanismus von Unix weckt dann (via den Scheduler) alle auf dieses Ereignis wartenden Prozesse. Dabei wird keine Rechenzeit verbraucht und Nebenläufigkeit ist möglich.

Entweder mit einem Lock-File (Dateisystem) oder im Speicher mit sogenannten Lock-Bits.

Modell: Der Prozess prüft zyklisch auf Zustandsänderungen des Bits und modifiziert das Bit falls erlaubt.

Problem: Meist keine atomare Operation wegen jederzeitiger Unterbrechbarkeit, es kann daher zu Problemen kommen, wenn die Implementation nicht durch unteilbare CPU-Instruktionen (Intel Opcode cmpxchg) unterstützt wird.

Variante eines Locks, welches durch eine Zählervariable (im Shared Memory z.B.) implementiert wird.

Sinnvoll, wenn mehrere Prozesse zu synchronisieren sind, z.B. maximale Anzahl quasiparalleler Leseprozesse auf einer Datenbank.

Problem: Dasselbe wie bei den Locks: Nicht Atomare Operationen.

A situation, where several processes access and manipulate the same data concurrently and the outcome of the execution depends on the particular order in which the acess takes place, is called a race condition. To guard against race condition, we need to ensure that only one process at a time can be manipulating the variable / data. To make such a guarantee, we require that the processes be synchronized in some way. (Operating System Concepts)

At a given point in time, many kernel-mode processes may be active in the operating system. As a result, the code implementing an operating system (kernel code) is subject to several possible race conditions.

Consider as an example a kernel data structure that maintains a list of all open files in the system. This list must be modified when a new file is opened or closed (adding the file to the list or removing it fromthe list). If two processes were to open files
simultaneously, the separate updates to this list could result in a race condition. Other kernel data structures that are prone to possible race conditions include structures for maintaining memory allocation, for maintaining process lists,
and for interrupt handling. It is up to kernel developers to ensure that the operating system is free from such race conditions.

Ein Code Segment eines Prozesses, dass globale Variablen, Tabellen aktuallisiert, Files schreibt oder andere gemeinsame Resourcen manipuliert, die für andere Prozesse auch zugreifbar sind, nennt man Critical Section.

Während ein Prozess im Critical Section ist, darf kein anderer Prozess in seinem Critical Section sein (Mutual Exclusion).

Ein Preemptive Kernel erlaubt es, dass ein Prozess preempted wird, während es im Kernel Mode läuft.

Preemptive Kernels sind von Race Conditions betroffen, deswegen müssen sie so aufgebaut sein, dass geteilte Kernel Daten von Race Conditions befreit sind.

Vorteile eines Preemtpive Kernel: Ist mehr responsive, weil ein Kernel Mode Prozess nicht für eine unbestimmte Zeit läuft. Zudem sind sie eher für Real-Time Programmierung gedacht, da ein Real-Time Prozess ein Prozess im Kernel preempten kann.

Ein Non-Preemptive Kernel erlaubt es nicht, dass ein Prozess preempted wird. Ein Kernel-Mode Prozess läuft solange bis es den Kernel-Mode verlässt, blockt oder freiwillig die Kontrolle der CPU abgibt.

Ein Non-Preemptive Kernel ist von Race Conditions befreit, da nur ein Prozess im Kernel aktiv sein kann.

Steht für Mutual Exclusion Lock.

Mutex Locks werden verwendet, um die Critical Sections zu schützen und so Race Conditions zu vermeiden.

Ein Prozess muss den Lock bekommen, bevor er in den kritischen Sektor darf und diesen dann wieder freigeben, falls er damit fertig ist.

Mutex Lock hat in der Regel zwei Methoden aquire und release. Ein Boolean-Wert available (Binärer Lock) wird dabei manipuliert.

Nachteil: Es muss Busy Waiting betrieben werden. Während ein Prozess im Critical Section läuft, müssen andere Prozesse ständig im Loop Nachfragen, ob sie in Critical Section dürfen. Solche Mutex-Locks werden auch Spinlocks genannt. Busy Waiting verschwendet CPU-Zyklen und hindert andere Prozesse vom Laufen.

Vorteil: Kein Context-Switching notwendig. Falls Spin-Locks nur für eine kurze Zeit gehalten werden, können sie durchaus sinnvoll sein, da Context-Switching auch aufwendig sind.

Ein Semaphor beinhaltet einen internen Zähler und eine Queue für wartende Prozesse.

Operationen: Initialisierung, wait (P) und signal (V)

Binary Semaphore funktionieren ähnlich wie Mutex-Lock, weil der Zähler nur von 0-1 geht.

Counting Semaphore können bis zu einer beliebige Stelle gehen.

Es ist wichtig das die Semaphor-Operationen atomarisch ausgeführt werden. Es muss garantiert sein, dass keine zwei Prozesse gleichzeitig wait() und signal() auf das gleiche Semaphor ausführen (Critical Section Problem)

Counting semaphores can be used to control access to a given resource consisting of a finite number of instances. The semaphore is initialized to the number of resources available. Each process that wishes to use a resource performs a wait() operation on the semaphore (thereby decrementing the count). When a process releases a resource, it performs a signal() operation (incrementing the count). When the count for the semaphore goes to 0, all resources are being used. After that, processes that wish to use a resource will block until the count becomes greater than 0. (Operating Systems Concepts)

Each semaphore has an integer value and a list of processes list. When a process must wait on a semaphore, it is added to the list of processes. A signal() operation removes one process from the list of waiting processes
and awakens that process.

When a process executes the wait() operation and finds that the semaphore value is not positive, it must wait. However, rather than engaging in busy waiting, the process can block itself. The block operation places a process into a waiting queue associated with the semaphore, and the state of the process is switched to the waiting state. Then control is transferred to the CPU scheduler, which selects another process to execute. 

A process that is blocked, waiting on a semaphore S, should be restarted when some other process executes a signal() operation. The process is restarted by a wakeup() operation, which changes the process fromthe waiting state to the ready state. The process is then placed in the ready queue. (The CPU may or may not be switched from the running process to the newly ready process, depending on the CPU-scheduling algorithm.)

• die umstrittene Ressourcen nur exklusiv nutzbar sind,
• die umstrittenen Ressourcen nicht entzogen werden können,
• die Belegung von Ressourcen schon möglich ist, auch wenn auf die Zuweisung weiterer Ressourcen gewartet werden muss,
• eine zyklische Kette von Prozessen aufftritt, in der jeder Prozess mindestens eine Ressource besitzt, die der nächste Prozess in der Kette benötigt.

In einem Deadlock, werden die Prozesse nie Abschliessen und System Resourcen bleiben besetzt, was andere Prozesse davon hindert überhaupt zu starten.

Eine Menge von Prozessen sind in einem Deadlock Zustand, wenn jeder Prozess dieser Menge auf einen Event wartet, der nur von einer diesen Prozessen aufgerufen werden kann. Solche Zustände passieren in der Regel, wenn man auf eine Resource (CPU, Memory, File, Semaphore, etc.) wartet.

Starvation ist ein Zustand, wo alle Prozesse unendlich lange warten. Dies kann in einem Semaphore entstehen (Liste wartender Prozesse).

Nach folgendem Muster greift ein Prozess auf eine Resource zu:

1. Request: Anfrage an Resource. Falls Resource bereits alloziert, muss der Prozess warten, bis er die Resource übernehmen kann.
2. Use: Der Prozess manipuliert die Resource.
3. Release: Der Prozess gibt die Resource für den nächsten Prozess frei.

Es gibt zwar Applikationen die in der Lage sind, Deadlocks in Programmen zu finden, Betriebsysteme stellen aber solche Deadlock-Prevention Einrichtungen nicht zur Verfügung. Es bleibt die Aufgabe des Programmierers Deadlock-freie Programme zu entwerfen.

Folgendes kann dagegen unternommen werden:

• Sicherstellen, dass immer eine der Deadlock-Bedingungen nicht erfüllt ist.
• Zukünftige Ressourcenbedarf der Prozesse analysieren und Zustände erkennen/verbieten, die zu Deadlocks führen
• Bereits eingetretenden Deadlock erkennen und auflösen

Developers of multithreaded applications must remain aware of the possibility of deadlocks. The locking tools like Semaphores and Mutex are designed to avoid race conditions. However, in using these tools, developers must pay careful attention to how locks are acquired and released. Otherwise, deadlock can occur, as illustrated in the dining-philosophers problem.