We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Linux auf dem Desktop

00:00

Formal Metadata

Title
Linux auf dem Desktop
Title of Series
Number of Parts
254
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
2019 ist das Jahr des Linux auf dem Desktop! Ich zeichne gerne Architekturdiagramme auf Whiteboards während dem Pythonfoo im Chaosdorf. Weil daran anscheinend allgemeines Interesse besteht, habe ich in den letzten Monaten unregelmäßig die aktuellen Konzepte von modernen Desktop-Linux-Distributionen erklärt im Rahmen des [Freitagsfoo](https://wiki.chaosdorf.de/Freitagsfoo). Dies richtet sich hauptsächlich an Leute, die Linux oder irgendein BSD benutzen - ich habe von Windows oder macOS leider wenig Ahnung und werde in die Richtung daher wohl eher weniger Querverweise machen können. Ich hoffe, das ist trotzdem interessant - oder es dauert wenigstens nicht zu lange. Leute, die vollständige moderne Desktopumgebungen benutzen, erfahren wie das eigentlich hinter den Kulissen alles funktioniert. Leute mit Arch+i3 lernen, was ihnen fehlt bzw. wie sie das nachrüsten können.
Keywords
DesktopLINUXKDENetwork socketField extensionLengthComputer hardwareLocal ringDesktopRoute of administrationLINUXInformationShared memoryRoundingDiagramRandClient (computing)Statement (computer science)BlogFluxHauptspeicherBlock (periodic table)Web browserVersion <Informatik>TwitterMetadataEmulatorDevice driverComputer fontLinieNetwork socketWINDOWS <Programm>outputFlussdiagrammXlibNullComputer animation
Network socketLaptopDevice driverComputer hardwareComputer animationVersion <Informatik>Distribution (mathematics)ScreensaverPasswordRoute of administrationoutputTerminal equipmentDirection (geometry)Torsion of a curveCrash (computing)Programmer (hardware)Virtuelles TerminalClient (computing)BIENE <Computer>TouchscreenService (economics)Computer animation
Programmer (hardware)HypermediaLaptopElectronic visual displayCalculationComputer animation
TwitterLaptopPasswordMaus <Datentechnik>Electronic visual displayLoginWebcamTwitterSwitching <Kommunikationstechnik>Switch <Kommunikationstechnik>CalculationMoment (mathematics)ZugriffComputer animation
BIOSDisplayVersion <Informatik>LISPPasswordElectronic visual displayComputer hardwareBIOSBootingPartition (number theory)Angular resolutionPlatteMoment (mathematics)Router (computing)InformationVideo cardFirmwareUnschärfeLaptopCalculationKDETouchscreenHard disk driveLaufzeitInterrupt <Informatik>IP addressKernel (computing)LoginLINUXImplementationZugriffOperating systemWINDOWS <Programm>Axiom of choiceDecision tree learningModule (mathematics)Device driverGraphic designModemSet (mathematics)Social classGebiet <Mathematik>Computer animation
WINDOWS <Programm>HypermediaoutputBIOSKernel (computing)Ubuntu <Programm>MicrosoftAktion <Informatik>PasswordHard disk driveEnergy levelClefWINDOWS <Programm>LoginDebian GNU/LINUXService (economics)FirmwarePartition (number theory)Systems <München>CASCuboidInternet ExplorerVideo game consolePrime idealEXTESTComputer animation
Chain ruleHibernateClefProgrammer (hardware)Kernel (computing)SoftwarePasswordZugriffCryptanalysisComputer hardwareTransmitterMicrosoftHauptspeicherPlatteFirmwareDebian GNU/LINUXVideo game consoleCalculationModule (mathematics)Acoustic membraneDevice driverRhytidectomyMach's principleQuest <Programm>Source code
openSUSEComputer animation
Transcript: German(auto-generated)
Herzlich Willkommen zum nächsten Talk mit einem echten Dauerbrenner Thema. Linux
auf dem Desktop. Persönlich habe ich das Gefühl 2019 war es immer noch nicht so weit, aber ganz kurz, wer benutzt denn aktuell Linux auf dem Desktop? Kurz OK. Gut, vielleicht habe ich doch unrecht gehabt und 2019 war endlich das Jahr des Linux auf dem Desktop, aber mal sehen. Genau, Näheres dazu
wird uns gleich Uetwild erzählen. Ganz kurz ein Hinweis zum Ablauf des Talks. Der Talk ist in fünf Teilen untergliedert. Wir machen kurze Frage- und Antwortenrunden nach jedem Blog. Das heißt, wenn ein Blog zu Ende ist, bitte ich euch möglichst zügig zu einem der beiden Saalmikrofone zu
laufen oder währenddessen die Fragen online über Twitter, Mastodon oder IRC an den Signal Angel zu stellen, damit wir über die Frage- und Antwortrunden nicht zu viel Zeit verlieren und zügig durchkommen. Genau, das war es von meiner Seite und jetzt freue ich mich auf den Talk. Herzlich willkommen, Uetwild. Danke. Ich bin total überrascht, dass so viele Leute gekommen sind. Das
hätte ich echt nicht erwartet. Die fünf Teile haben einen einfachen Grund. Ich habe kein wirklich großartiges Konzept. Ich habe mir mehrere Dinge angeschaut. Es gibt bei uns in Karlsdorf den Freitagshof. Das ist ein
Thema ausgesucht, die euch hoffentlich interessieren. Das ist nicht wertend gemeint. Die sind nicht besonders wichtig oder unwichtig, aber fangen wir einfach mal an. Ich habe das ein bisschen gegliedert und wir würden
anfangen mit X und am Ende auch so ein bisschen Wayland. Es gab vor einer Stunde oder so einen sehr guten Talk hier auf dieser Bühne zu dem Thema. Ich bin froh, dass es nicht der doppelte Inhalt ist. Genau, das ist eigentlich auch nur eine Zusammenfassung von einem anderen Talk, der sehr großartig ist.
Ich habe das ursprünglich in acht Minuten gemacht. Ich werde das jetzt nicht versuchen. Grundsätzlich ist es so ein, wir kommen von dem oben links zu dem unten rechts. Beide Bilder sind neu, aber die Technik ist halt älter
auf dem Bild oben links und ihr seht schon, was sich da so ein bisschen alles verändert hat. Wir haben Schatten, wir haben Farben, wir haben verschiedene Schriftarten. Fangen wir in den 80ern an. Da gab es die X-Protokoll Version 1 bis 11. Seiteweise hat sich nichts mehr getan. Es gibt nur Erweiterungen. Das wird so ein Flussdiagramm mit Pfeilen. Das ist das
Rendering vom Bild. Die Inputs laufen halt genau andersherum. Und genau, wir haben den X-Server und wir haben die Hardware. Der X-Server spricht mit der Hardware und braucht dafür Treiber. Das ging tatsächlich sogar so weit, dass
irgendwie eine X-Box-Version, meine ich, eine Emulator für x86-CPUs hatte für Videoroms. Genau, dann haben wir Clients, zum Beispiel so ein Browser oder so. Wir benutzen dann zum Beispiel Xlib und reden über Netzwerksocket mit dem X-Server. Dann haben wir einen Window-Manager, der ist auch einfach nur ein Client
und der bestimmt dann, wo sind Fenster, welches Fenster ist gerade im Vordergrund und so was. Und da ist dann diese tolle Netzwerktransparenz, die von X immer gelobt wird. Und damals in den 80ern gab es die wirklich, die war wirklich funktional. Es hatte keinen großen Unterschied, ob wir Anwendungen
lokal oder Netzwerke ausführen. Genau, wie das funktioniert, ist die Clients machen Zeichenbefehle. Also ich will eine Linie haben, ich will Text haben. Und das heißt, der X-Server muss Fonts lesen und rendern können und das tatsächlich Bild rendern und zusammenbauen.
Das macht natürlich die Netzwerkpakete sehr klein, weil es nur die Informationen darüber sind, was dargestellt werden soll. Aber das hat nicht so wirklich gereicht, weil wir wollen, dass Anwendungen schöner werden in den 90ern. Also mit Farbverläufen und verschiedenen Farben, verschiedenen Schriftarten pro Anwendung oder sogar in einem Fenster.
Und das heißt, die Anwendungen bauen ihre Fenster jetzt komplett selber zusammen. Zum Beispiel mit Qt oder anderen Libraries und schieben dann das fertige Bild rüber als Framebuffer. Das geht auch noch übers Netzwerk, aber
es ist halt langsam. Ich hatte da mal ein Setup, irgendwie Full HD, X braucht so 25 MBit, meine ich, ohne irgendwie eine Komprimierung. Das will man vielleicht nicht unbedingt machen. Also Netzwerktransparenz geht, aber wenn man das lokal betreibt, ist es einfach shared memory. Also da wird gar nicht
großzeitig irgendwas rumkopiert, sondern es bleibt an einer Stelle im Arbeitsspeicher. Und übers Socket gehen dann nur noch die Metadaten. Das heißt, der X-Zerva muss Fronts immer noch können, weil ansonsten würde er nicht X11 unterstützen, aber praktisch wird das nicht mehr benutzt. Gut, das sind die 90er. Dann jetzt in den Nullern wollen wir wobbly
Windows und Desktop-Cubes haben. Total der krasse Scheiß. Und das heißt, der X-Zerva baut das Bild auch gar nicht mehr zusammen, sondern das macht jetzt der Window-Manager, um so Transparenz-Effekte und sowas einbauen zu können. Der X-Zerva muss das aber weiterhin können, weil ihr könnt jetzt zum Beispiel auch einen anderen Window-Manager nutzen oder Compositing
ausschalten, weil eure Hardware das nicht kann oder sowas. Das ist immer noch möglich übers Netzwerk, aber noch langsamer. Zumindest, wenn ihr den Window-Manager irgendwie übers Netzwerk macht, würde ich nicht empfehlen. Genau, und naja, wir haben jetzt das Problem gehabt, dass der X-Zerva Hardware-Treiber hat, aber das ist ja nicht das, was wir haben wollen.
Womit da richtigen Schichtarchitektur sind die Treiber ja am Körner. Was jetzt passiert, ist, wir haben Glamour als X-Backend, zumindest in aktuellen Distributionen mit aktueller Hardware, mit aktuellen Treibern. Der X-Zerva rendert dann einfach über EGL raus und der Körner kümmert sich um
die Auflösung und sowas. Das heißt, ihr könnt auch auf viertel Terminals wechseln, ohne dass es flackert zum Beispiel. Genau, und naja, Wayland mercht jetzt den X-Zerva und den Window-Manager und schmeißt halt das Zeug raus, was wir nicht mehr brauchen.
Die Netzwerk-Transparenz geht aber erstmal flöten, weil Wayland hat keine. Ihr könnt aber natürlich VNC benutzen oder sowas. Genau, gut, wenn ihr eine aktuelle Desktop-Ungebung benutzt, so eine große, dann könnt ihr das einfach bei der Anmeldung auswählen, was ich
Wayland haben möchte. Sonst habe ich für ein paar kleinere Window-Manager mal Alternativen für Wayland rausgesucht. Ja, ich habe das mal ausprobiert. Ich probiere das regelmäßig aus, wenn es eine neue Version von Maya-Distro gibt. Das meiste klappt eigentlich relativ gut. Mir fehlen bisher ein, zwei Features,
aber ich habe auch eine LTS, und mittlerweile sind die wahrscheinlich da. Wenn ihr Nvidia habt, dann habt ihr vielleicht noch mehr Probleme. Es gibt da eine etwas eigene Geschichte, die ich jetzt glaube ich nicht ausführlich erzählen muss. Ansonsten ein Problem, was eigentlich gut ist, ihr könnt nur
Anwendungen anzeigen, die als euer Nutzer-Account laufen. Es hat so ein bisschen Probleme, gepartet geht nicht mehr. Es gibt da ein Workaround, um zu sagen, Ruth darf auch Fenster anzeigen. Weißt ihr, ob ihr das wollt? Ja. Gut, habt ihr bis hierhin Fragen? Okay, anscheinend ist das ein Nein.
Ich trinke noch mal etwas. Ja, okay, dann kommen wir zum
nächsten Thema. Das ist eines meiner Lieblingsthemen, Bildschirmsperren. Genau. Da gibt es zwei Dinge, ihr kennt vielleicht von früher noch so Bildschirmschoner. Wir hatten ja früher Röhrenbildschirme, und wenn die regelmäßig das gleiche Bild eingezeigt haben, ist es irgendwie eingebrannt. Dann wurden da so tolle Animationen mit Röhren
oder Labyrinthen gemacht, um das Einbrennen zu verhindern. Heute brauchen wir das eigentlich nicht, und wir können tatsächlich sogar Strom sparen, was ja auch unserem Kongressmotor entspricht, wenn wir einfach keine Animationen machen und den Bildschirm ausmachen. Aber trotzdem wollen
wir, wenn ich den Laptop irgendwo liegen lasse oder so, dass Leute nicht darauf zugreifen können. Wir wollen den Bildschirm also sperren einfach. Genau. Es gibt damit so ein bisschen Probleme. Ich habe zum Beispiel in der Vorbereitung für diesen Talk diesen Tooth gesehen. Da hatte
jemand irgendwie i3, und die i3-Log hat irgendwie wild auf der Tastatur rumgehauen, und dann war der Bildschirm entsperrt. Das ist ein bisschen doof. Wir werden uns jetzt angucken, warum das so ist und was man dagegen tun kann. Das Problem ist nämlich, das X-Protokoll kennt kein Screen-Logging. Der Screen-Logger ist einfach nur
irgendwie ein Client, der sich in den Vordergrund schiebt und einen Input sich holt, und wenn ihr das Passwort richtig eingebt, sich beendet. Das hat natürlich auch das offensichtliche Problem, dass wenn der Screen-Logger crash der Bildschirm entsperrt ist, man kann die Links
gut lesen. Das hätte ich nicht gedacht. Ja, es gibt noch ein weiteres Problem durch dieses Ich schiebe mich in den Vordergrund. Ihr kennt das Konzept eines Kontextmenüs bis auch im Vordergrund. Wenn ich jetzt den Bildschirm sperren möchte, passiert halt nichts. Was man tun kann, ist man kann diesen
Passwort-Dialog und den Screen-Logger trennen. Das macht X-Screen-Saver so. Das sorgt dafür, dass wenn der Guita crasht, ist das nicht schlimm, den kann ich ja neu starten. Wenn der Screen-Logger crasht, ist
der Bildschirm entsperrt. Was man sonst auch macht, ist den Screen-Logger und den Window-Manager merchen. Das machen so die großen Testumgebungen. Durch Compositing können wir ja bestimmen, was zu sehen ist, ohne den X-Server. Dann können wir auf jeden Fall den Bildschirm blanken, egal was passiert. Im schlimmsten Fall haben wir einfach einen schwarzen Bildschirm, aber es ist besser, als eure Daten
anzuzeigen. Wir können auch den Screen-Logger und den Session-Manager merchen. Das sorgt nicht für weniger crashes, das sorgt dafür, dass wenn es crasht, dass alles weg ist. Also auch niemand eure Sachen sehen kann dann. Genau. Das kann ich immer eben demonstrieren. Wenn ich den Bildschirm
sperre, seht ihr, dass er erst schwarz wird und dann den Passwort prompt anzeigt. Das sind zwei verschiedene Programme. Weitere Probleme, die es damit gab, ist, wie kann ich als Anwendung herausfinden, ob der Bildschirm überhaupt gesperrt ist. Zum Beispiel irgendwie, ich bin
Media-Player, dann will ich das Video ja vielleicht gar nicht anzeigen, wenn der Bildschirm gesperrt ist. Das braucht ja niemand. Oder ich bin Media-Player und will verhindern, dass ich der Bildschirm sperrt, während ich gerade einen Film abspiele. Und ein weiteres Problem ist die Race-Condition mit Standby. Was ich früher oft hatte, ist, ich klappe meinen Laptop zu, der Bildschirm sperrt
sich und der Laptop geht in Standby. Die Reihenfolge war aber früher nicht definiert. Es ist mir häufig passiert, dass ich den Rechner aufgeklappt habe und der Bildschirminhalt war noch da, so für so drei, vier Sekunden. Wir können das jetzt mal eben ausprobieren und wenn das dann alles klappt, sehen wir, dass erst der Bildschirm dunkel wird, der Laptop dann jetzt in Standby geht und wenn ich ihn
aufwecke, ist der Bildschirm weiterhin schwarz und dann kommt die Passworteingabe. Genau. Was da das entscheidende Ding ist, ist das System D-Log Indie. Das
habe ich dann der Person auch direkt empfohlen und ich wurde überraschenderweise nicht geblockt. Genau. Log Indie ist der Nachfolger für ConsoleKit und verwaltet Sessions, also eure Logins und gerade laufende Sitzungen und Seats, das sind Bildschirme mit zugeordneten Plastaturen und Mäusen.
Üblicherweise habt ihr einen Seat an so einem Rechner, aber es gibt durchaus die Möglichkeit, mehrere zu betreiben. Was dadurch dann auch möglich ist, ist so genanntes Fast User Switching. Also ihr könnt mit mehreren Leuten eingeloggt sein und wechseln zwischen den laufenden Sessions und zum Beispiel hört ihr dann nur eure Musik und nicht die von
der anderen Person, die möglicherweise auch gerade läuft oder Webcams oder sowas. Berechtigungen werden dann auch mit gewechselt. Und es gibt halt Hugs für Standby, Shutdown und sowas. Das ist in der richtigen Reihenfolge passiert und dass halt der Standby so lange aufgehalten wird, bis der Bildschirm gesperrt wird. Genau, dann habe ich da unten noch die Doku
verlinkt. Das eben war auf Mastodon. Auf Twitter bin ich dafür mal geblockt worden. Wenn ihr eine aktuelle große Desktopangebung benutzt, dann habt ihr das alles schon. Wenn ihr irgendwie i3 oder sowas benutzt, es gibt
ein Tool, das nennt sich XSS-Log, was mit Login deintegriert und dann den Status zurückmeldet. Wenn ihr das einfach mal testen wollt, könnt ihr Login-CTL-Log-Session eingeben. Das müsst ihr eurem Bildschirm sperren. Mit Wayland werden Dinge besser, weil wir haben halt nicht mehr die Trennung zwischen X-Server und
Compositor. Das heißt, wir können tatsächlich dafür sorgen, dass der Bildschirm nicht mehr sichtbar ist. Login ist dafür quasi eh notwendig. Das heißt, wir haben auch den Zugruf auf die Geräte entsprechend nach Login.
Habt ihr zu dem Teil Fragen? Alles klar, da gibt es direkt am rechten Mikrofon eine Frage. Bitte schön. Ja, genau. Die Frage, die ich
habe, ist, ob das ein Problem ist, dass der Log-Screen im Multi-Bildschirm-Modus gerne mal auf dem falschen Bildschirm, sprich auf dem zugeklappten Laptop, auftaucht. Fixed-Login-D bzw. Wayland das auch? Und ich sollte mir jetzt eine neue Distro suchen?
Nein, das ist Teil des Green-Lockers. Ich kann jetzt nur hier demonstrieren, wie Plasma das macht. Und das ist, indem der gleiche Log-Screen auf allen Bildschirmen angezeigt wird. Also nicht nur auf einem. Ich kann jetzt hier irgendwie was eingeben. Und ihr seht, was ich eingegeben habe. Und ich kann jetzt hier das
richtige Passwort eingeben und es abschicken. Also der Trick, den Plasma macht, ist einfach den Log-Screen auf allen Bildschirmen anzuzeigen. Aber das kommt auf dein Logger an. Okay, bedeutet aber, du hast die nicht gespiegelt, richtig? Nein. Also werde ich mir KDE mal anschauen.
Alles klar. Okay, und dann gibt es direkt noch eine weitere Frage. Hallo. Bedeutet das, dass Wayland und System D ein Ding sind? Nein. Du kannst Log-In-D tatsächlich auch ohne System D nutzen. Es gibt da ein Fork von. Das heißt dann irgendwie E-Log-In-D. Genau. Der Trick
ist halt, wir wollen ja auf die Hardware zugreifen. Und Log-In-D sorgt dafür, dass wir nicht auf TTY 1 eingeloggt bin, ich tatsächlich Hardzugriff auf die Grafikkarte z.B. habe. Während in einem klassischen Setup läuft die X-Server als TTY die Route und kann deswegen zugreifen auf die Hardware. Das ist halt ein bisschen ein anderes Konzept.
Danke. Okay, das war es für das erste mit Fragen. Wir sehen uns später wieder. Oh, Sekunde. Zu früh gefreut. Da hinten gibt es eine Frage vom Signal Angel. Verzeihung. Hallo. Wie kann ich den Screen Locker abschalten bei Suze KDE?
In den Einstellungen. Also KDE hat sehr viele Einstellungen. Das ist ja großartig. Ich weiß aber nicht genau, wo. Bevor ich dich jetzt wieder ausversehen übergehe, hat der Signal Angel noch eine Frage. Okay, dann jetzt wirklich bis später. Okay, dann kommen wir zum Thema
Flackerfreier Boot. Auslöser war, ein Bekannter von mir hat ein neues Laptop installiert und das war dann mit Windows 10 und der Bootvorgang war, so wie ihr das vielleicht kennt. Also erst das Herstellerlogo, dann unten drunter dieser Kreis, der sich dreht und dann der Login Screen. Ich dachte mir,
das sieht doch cool aus, warum macht mein Laptop das nicht? Was meine ich mit Flackerfrei? Ich meine, dass die Auflösung nicht wechselt während dem Boot und ich meine auch, dass der Inhalt nicht wechselt. Also das alles irgendwie mit Flackeranimationen passiert und kein harter Cut drin ist. Dafür müssen wir uns den Bootprozess anschauen. Das sieht ungefähr so aus.
Wir haben hier die Firmware, die kommt vom Hersteller, da können wir jetzt erstmal nichts dran machen. Also es gibt Coreboot und sowas, aber ich betrachte jetzt einfach nur die Herstellerfirmware. Dann haben wir den Bootloader, der ist Teil eurer Distro. Dann startet das System irgendwie, dann könnt ihr euch einloggen und dann habt ihr eure laufende Sitzung. Schauen wir uns die Firmware zuerst
an. Klassischerweise ist es ein sogenanntes BIOS, das die Hardware initialisiert, das System startet und tatsächlich auch zur Laufzeit noch Dinge bereitstellt. Also irgendwie Energiesparmodi oder einfacher Zeichenmodi oder sowas. Tatsächlich auch Zugriff auf Festplatten. Das Problem ist,
dieses BIOS ist nie wirklich designt oder dokumentiert worden. Dieser klassische IBM PC hatte halt eins und die anderen sind Nachbauten davon. Genau, ich habe diese Fotos auf Wikimedia Commons gefunden. Das Rechte ist definitiv ein BIOS. Das linke
ist glaube ich schon UEFI. Wir gucken uns ja nur die Grafik an und da gibt es verschiedene Modi. Ursprünglich irgendwie EGA, VGA kennt ihr wahrscheinlich und dann SVGA. Ihr seht schon, diese Auflösungen sind winzig und alt. Wenn ihr einen Rechner anmacht und den im BIOS-Mode bootet, seht ihr,
dass die Auflösung am Anfang falsch ist. Das ist eine von denen Auflösung und dann ist der Text unscharf. Weiteres Problem ist, diese Grafiksteuerung vom OS aus geht nur im Real Mode oder irgendwelche Interrupts. Und wenn wir jetzt booten, darf das oder so ein Bootsektor, also das
BIOS springt einfach an den Anfang der Festplatte und führt aus, was dann da steht. Es gibt einen Nachfolger seit 15 Jahren ungefähr und das ist UEFI. Was tatsächlich ein Standard ist und dann gibt es da von verschiedenen Herstellern Implementierungen zu. Das hat die gleiche Aufgabe wie das
alte BIOS. Dieses Foto habe ich gefunden und auch das ist nicht ganz gerecht, weil es ist ein UEFI, aber es bootet im BIOS-Mode. Das könnt ihr daran lesen, dass der Text so groß ist und unscharf und wenn ihr ein Thinkpad habt, könnt ihr das relativ einfach erkennen, weil wenn das Thinkpad-Logo da ist, dann ist es in BIOS-Mode.
Wenn das den Novo-Logo da ist, ist das im UEFI-Mode. Auch da gibt es Grafik, das ist das sogenannte Graphics Output Protocol. Unter Linus könnt ihr das mit dem EFI-FB Kernel-Modul benutzen. Also wenn ihr irgendwie total abenteuerlustig seid, könnt ihr einfach mal eurer Grafikmodul blacklisten und wenn ihr da
neu startet und immer noch eine ordentliche Auflösung habt, dann ist das EFI-FB. Gut, der Boot funktioniert so, dass wir eine FAT-Partition haben, irgendwo auf der Platte. Das ist die sogenannte EFI-System Partition und da sind dann halt Binary's drin, die wir ausführen. Es gibt wieder die Beschränkung, dass wir nur Hardware-Calls
machen können im gleichen Modus, in dem die Firmware läuft. Aber es läuft ja mittlerweile alles im Long-Mode, von daher ist das egal. Aber wo kommen die Logos her? Da gibt es einen ACP1 Standard, diesen BGRT, diesen Boot Graphics Resource Table und der enthält
Informationen über das Hersteller-Logo. Nämlich diese Informationen über das Hersteller-Logo. Ob das Hersteller-Logo anbezeigt wurde oder nicht, es könnte jetzt mal sein, dass ihr F12 drückt und dann so ein Menü bekommt, dann ist das Logo ja schon weg, wenn das System startet. Es zeigt auch die Adresse des
Bildes, wenn das Betrieb des Logos noch mal haben will und auch wo das gezeichnet wurde. Das heißt, als Betriebssystem können wir nach dem Start genau das Logo an genau den Punkt nochmal drüber zeichnen und niemand merkt es, weil die Auflösung war ja vorher schon korrekt. Das sorgt auch dafür, dass hier irgendwo im SysFS auf Linux das
Hersteller-Logo findet. Ich meine, das wäre irgendwie Sys Class ACPi BGRT Image. Gut, wir haben Bootloader. Die sind dann je nach Modus entweder im Bootsektor oder auf dieser FESystem Partition. Die starten dann.
Die meisten Distros, die ihr im Moment verwendet, benutzen Grub oder Systemd Boot und die zeigen irgendwie ein Menü an, aber niemand macht mehr Dual Boot, glaube ich zumindest. Und es geht ja auch nicht schief beim Booten. Das heißt, wir sehen Bootloader einfach gar nicht. Das können wir jetzt ignorieren. Der Kernel braucht Hardware-Treiber.
Der Kernel möchte vielleicht auch Text anzeigen beim Starten. Der Trick hier ist dieses Fernbefragte-Konsole, die für Takeover dafür sorgt, dass nichts auf dem Bildschirm geschrieben wird, also auch nicht ein Lehrer-Bildschirm, bis da tatsächlich Text drauf ist. Das heißt, wenn wir quiet booten, bleibt einfach das Hersteller-Logo, weil wir den
Bildschirm gar nicht löschen. Ein weiteres Problem ist, wir haben ja vielleicht irgendwie so Logs, die wir beim Starten sehen wollen. Also irgendwie, welche Dienste gerade starten oder ihr habt Festplatten mit Verschlusslöhung. Das solltet ihr definitiv haben. Und dann müsst ihr ein Passwort eingeben beim Starten.
Gut, wenn wir das nacheinander starten, wie das lange Zeit der Fall war, dann ist das kein Problem. Wir haben eine Konsole, da können wir Text drauf schreiben, da können wir Text von lesen. Aber wir starten ja Dinge parallel mittlerweile. Und das sorgt für ein Problem, weil wenn wir parallel Text ausgeben, ist der irgendwie vermischt und das will keiner lesen.
Wo geht Input hin? Deswegen haben wir Plymouth. Das zeigt halt so ein Logo an im üblichen Fall. Es gibt aber auch einen Nur-Text-Modus. Und das kann dann auch Input. Also so ein, dieser Dienst möchte dann ein Passwort haben beim Starten.
Und wie das halt funktioniert mit dem Hersteller-Logo, es gibt ein BGRT-Theme dafür. Das hier ist das klassische Fedora-Theme. Das ist nicht mehr aktuell das Bild. Mittlerweile ist einfach das Hersteller-Logo oben, dann das Distro-Logo unten und so ein kleiner Spinner halt. Nächster Schritt ist dann, wir haben Login. Das ist irgendwie GDM oder SDDM.
Die laufen mit X oder Wayland. Und der Trick dabei ist einfach, den X-Server mit minus no root zu starten. Das heißt nicht, dass der X-Server nicht alles gut läuft. Das ist ein anderes Problem. Das hatten wir eben. Das sorgt dafür, dass der X-Server am Start den Bildschirm nicht löscht. Das heißt, bisher ist der Logo weiterhin drauf.
Und wir konnten ordentlich eine Animation machen mit einem Übergang. Und das Gleiche gilt dann halt auch für die Desktop-Umgebung. Was müsst ihr dafür tun? Ihr könnt ein aktuelles Fedora benutzen, dann klappt das alles. Wenn ihr ein älteres habt oder ein Ubuntu 19.10, dann gibt es da so ein Plymouth BGRT-Paket, das könnt ihr
installieren. Den Grab neu bauen, damit ihr den Bildschirm nicht mehr pink löscht, sondern schwarz löscht. Nee, gar nicht löscht. Und dann neu starten. Ihr braucht dafür einen aktuellen Kernel. Und es geht soweit. Ich weiß mittlerweile nur mit Intelliq-Reviews. Vielleicht bald auch mit anderen. Und ihr fragt euch jetzt sicherlich,
wie sieht das aus? Es gibt da von der zuständigen Person bei Fedora dieses schöne Video. Und naja, es ist halt so, wie man es erwarten würde.
Ja, das sah doch jetzt gar nicht so schlecht aus, ne? Ich habe euch da noch ein paar Links rausgesucht. Ich finde dieses GNOME-Wiki sehr großartig, weil sie haben da Mockups drin. Und auch, wie machen andere Systeme das mit Screenshots von Windows 10 und Mac OS, glaube ich.
Ja, gut. Habt ihr jetzt zu dem Bereich Fragen? Ja, ist das an? Ja. Schön. Also, ich habe gerade mal hier versucht, auf meinem CinePack das nachzustellen. Und ich habe einen UEF-Dings-Bios,
allerdings scheint es im BIOS-Mode zu starten. Und ich habe im BIOS jetzt nicht gefunden, dass ich es umstellen kann. Aber das muss dort irgendwo doch zu finden sein, oder? Ja, du hast dafür drei Optionen. Dieser BIOS-Mode heißt üblicherweise CSM, Compatibility Support Mode. Den kannst du ausschalten.
Du kannst aber auch den Default ändern. Problem ist halt, wenn du es nicht ausschaltest, macht er möglicherweise einen Fallback. Das setzt aber auch voraus, dass dein installiertes System UEFI kann und auch so installiert wurde. Wenn du es in BIOS-Mode installiert hast, musst du dafür ein paar Dinge umstellen. Du musst die Partition anlegen,
du musst den Bootloader-Eintrag hinzufügen und so was. Das kannst du machen. Am einfachsten wäre es wahrscheinlich, CSM auszuschalten und dann das System neu zu installieren. Okay. Aber wahrscheinlich meinst du nicht, dass es reicht, einfach Grub neu zu installieren danach? Wir können uns gleich mal treffen und dann kann ich dir sagen, was da fehlt. Aber so einfach ist es leider nicht. Okay. Gut.
Gerne. Nichts leichter als eine neue Installation, um ein Problem zu fixen. Signal Angel, eine Frage? Nein. Sehr gut. Dann geht es weiter. So. Sobald wir schon mal dabei sind, wie das Ganze bootet, können wir doch mal angucken, wie wir das sicher machen.
Damals, als ich meinen ersten Congress-Talk gesehen habe, war das dieser hier. Und Secure Boot hatte damals, als es neu rauskam, nicht so den besten Ruf. Das galt irgendwie so als oh nein, Microsoft will kontrollieren, welche Dinge ich starte. Das hat sogar so weit geführt, dass es dann eine Kampagne der FSF gegen gab.
Und aktuell steht im Debian-Wiki nochmal extra, dass es nicht dafür da ist. Genau. Wir hatten den Bootprozess ja eben grob. Ich werde mich jetzt auf das beschränken, was Debian und Ubuntu und meines Wissens auf Fedora machen.
Einen konkreten Implementation. Das sind Shim, Grub und der Dienstkörner. Ach so, und das Grüne ist der Teil, den wir sichern wollen. Die laufenden Dienste, könnt ihr nachinstallieren, da kann man nichts tun. Die Firmware ist vom Hersteller. Das ist eine andere Baustelle. Wir wollen den Bootprozess bis zum Bootloader, den Körner und alle Module
sichern, die ihr nachladet. Die Firmware hat irgendwie einen Key drin und prüft, ob der Bootloader davon signiert ist. Das kommt so ein bisschen darauf an, wenn ihr irgendwie so eine Dell-Laptop mit Ubuntu kauft, kann das sicher sein, dass da ein Canonical Key drin ist und nicht einer von Microsoft.
Bei den meisten Geräten sind die Keys von Microsoft drin. Das ist eine Geschichte. Ihr könnt aber auch eigene CAs erstellen und die Keys da reinladen. Das ist halt das übliche Problem mit Keys. Das will man nicht selber machen eigentlich. Genau, das erste Ding ist Schimmen. Das macht eigentlich relativ
wenig. Es lädt den Bootloader. Wofür haben wir das? Das Problem ist, Microsoft muss ja das Brain Resignieren und das ist nicht so einfach. Wenn ich die Post richtig gelesen habe, ist das so eine Aktion mit einer Windows-VM und das Smart Card und Internet Explorer.
Das will man halt nicht so oft tun. Und Microsoft signiert nur EFI-Baineries. Wenn wir auch die kernel Module prüfen wollen, dann müssen wir irgendwie so eine Chain of Trust hinbekommen. Es wäre schön, wenn man irgendwie Dinge cross zahlen könnte, aber auch das macht Microsoft nicht.
Das heißt, wir haben diesen Schimm, der ist signiert von Microsoft und der hat den Public Key einer anderen CA drin und prüft das nächste Bainerie dann dagegen. Das ist das, was Schimm hauptsächlich tut. Ansonsten ist Teil dieses Projekts der sogenannte Mock-Manager für Machine-Owner
Keys. Das ist dafür da, dass Sie auch selber Kernel-Module bauen könnt. Es gibt ja Leute, die machen das manchmal. Ich erzähle gleich noch was, wie das funktioniert mit dem Workflow. Gut, wir haben den Bootloader und auch der muss halt darauf angepasst werden, dass wir nur korrekt signierte Module oder Kernel laden. INITRA FS ist beliebig austauschbar.
Und wir haben auch ein bisschen das Problem, dass man zumindest bei Grab die Config ja bearbeiten kann. Der könnte irgendwie eh drücken beim Starten. Und das darf halt auch keine Lücken irgendwie aufreißen. Und auch der Kernel, den müssen wir ein bisschen anpassen. Was wir wollen, ist, dass wir
die Hardware vor unbeschränkend Zugriff zum Beispiel durch Boot schützen. Das heißt, wir wollen auch nicht, dass das System nachträglich manipuliert werden kann. Das heißt, wir können kein Hibernate machen, weil das bringt uns das, wenn wir die ganze Kette irgendwie gesichert haben, dann macht jemand den Rechner in Ruhe
zustand und tauscht den Kernel auf der Platte aus im Arbeitsspeicher. Das klappt ja auch nicht. Def Mem ist das gleiche Problem. Wenn wir im beliebigen den Speicher schreiben können, dann können wir den Kernel auch austauschen. Das ganze heißt Kernel Lockdown. Das ist so ein bisschen eine andere witzige Geschichte, weil
das lange Zeit nur in den Distros drin war. 2015 oder so. Das ist erst vor zwei Monaten wirklich im Upstream-Kernel gelandet. Ich glaube, das ist hier nicht ein Thema. Wie gesagt, die Module, die wir laden, die laufen ja auch im Kernel. Das heißt, wir müssen die auch ordentlich signieren. Zum Beispiel von der Distro.
Aber es gibt das Problem, dass ihr ja manchmal auch Module selber bauen wollt oder müsst. Zum Beispiel, weil ihr irgendwie Virtual Box installiert oder so. Das läuft über DKMS. Das baut die Module dann halt bei der Installation. Und das Konzept ist, wenn ihr eine Acroali-Distro habt und so ein DKMS-Modul
installiert, dann erkennt die das, erzeugt einen Private Key, signiert die Module damit und lädt den Public Key in eure Firmware rein. Dafür ist dieser Mock-Manager da. Das finde ich im Ubuntu-Wiki ganz gut beschrieben. Der einfachste Fall ist, ich installiere das und das ist sicher. Ich mache einfach nichts
weiter. Ein bisschen schwieriger wird es, wenn ich irgendwie so einen Grafik-Treiber, ihr wisst, welcher Hersteller gemeint ist, installiere, nicht nachträglich irgendwie bauen muss. Wie das funktioniert, ist wie gesagt mit diesem Private Key. Das Problem ist ja noch, wie finde ich heraus, ob der
Key echt ist. Wir müssen ja prüfen, dass die Person, die den Key erzeugt hat, auch die Person ist, die physikalischen Zugruf auf das Gerät hat. Wie das funktioniert, ist dieser Key hat ein Passwort und beim Neustart, also ihr müsst neu starten, fragt euch der Mock-Manager nach dem Passwort. Das ist das Konzept, um halt
sicherzustellen, dass es die gleiche Person ist. Dann gibt es natürlich auch noch andere Probleme. Leute vergessen Passwörte, aber gut, dann können wir den Prozess halt einfach neu machen. Das ist jetzt nicht so tragisch. Weiteres Problem, Leute haben komische Keyboard-Layouts, das ist nicht gelöst.
Gut, ihr müsst da jetzt nichts Großartiges tun. Ihr müsst eine aktuelle Firmware haben mit aktiviertem Secure Boot. Wenn ihr bereits mit EFI-Modus installiert habt, könnt ihr einfach Secure Boot nachträglich aktivieren. Das ist egal. Ihr braucht dafür eine Distro, die das unterstützt, auch somit der Kram ist ordentlich
signiert. Das sind meines Wissens diese hier, möglicherweise auch noch Mint oder sowas. Arch? Nicht. Ja, ich habe daraus zitiert und dachte euch, ich verlinke das auch nochmal, wenn ihr mehr Details zu haben wollt. Gut, ich habe das erzählt
im Chaos-Dorf und dann hat mich jemand gefragt, aber wie kann ich das denn deaktivieren? Erstens, das ist ein Sicherheitsfeature. Bitte nicht. Zweitens, ihr könnt das einfach an der Firmware deaktivieren. Also neu starten, das Firmware-Setup und dann Secure Boot deaktivieren. Das umfasst dann die ganze Kette. Ihr könnt mit diesem Befehl
den Schimm anweisen, den Kernel und den Bootloader nicht mehr zu prüfen. Das heißt, er hat noch so ein bisschen Sicherheit in den Bootprozess. Und es gibt sogenannte Magic-Sys-Requests. Mit Alt, Druck und irgendeine andere Taste könnt ihr einen Befehl an den Kernel senden. Und X steht dafür für
Lift-Lockdown. Das heißt, bis zum nächsten Neustart könnt ihr dann so einfach ein Management benutzen oder Beratungsmodule laden. Das würde ich jetzt nicht empfehlen. Diese Magic-Sys-Request könnt ihr auch auslösen, indem ihr entsprechende Buchstaben nach Proxy-Circuit-Trigger schreibt.
Ihr habt das Problem jetzt wahrscheinlich gesehen. Wir wollen uns ja schützen gegen Angriffe von RUT. Wenn ich das als RUT aufheben kann, ist das doof. Ja, das habe ich mal ausprobiert und dann war das kaputt. Mittlerweile ist das nur bunt für gefixt. In Fedora wurde
es irgendwie auch gefunden, zwar schon längere Zeit her, sie haben es aber niemandem gesagt, der Commit hat keine sinnvolle Beschreibung. Debian ist es schon noch offen, also wenn man in Debian hat, na ja. Das Problem ist halt, dieser Befehl hat zwei Dinge ausgegeben
auf der Konsole. Erstens, du darfst das nicht, zweitens, ich hab's gemacht und trotzdem haben heute Software geschrieben, die das benutzt. Nachdem der Bug gefixt war, hat mich irgendwie
eine Woche später jemand angeschrieben und gesagt, hier, ich habe dieses coole Programm, das den Lüfter steuert und das funktioniert jetzt nicht mehr. Ja, sorry, aber ihr solltet vielleicht nicht Programme als gut laufen haben, die direkt auf die Hardware zugreifen, da sind Kernelmodule da. Tja, und dann bin ich tatsächlich früher schon durch und würde
Fragen entgeben nehmen, glaube ich.