Open Source im professionellen Einsatz
Linux-Magazin 11/2014

Zacks Kernel-News

677

NMIs: Linus flucht über Hardwarehersteller

Nested Non-Maskable Interrupts (NMIs), eine vermeintlich lästige Altlast, wollte Andy Lutomirski loswerden – und damit eine ganze Latte an altem, dann nicht mehr benötigten Kernelquelltext. Dafür hatte er selbst Code eingebracht, um die Signale, die typischerweise Hardwarefehler melden, zu umgehen. Ganz vermeiden lassen sich die Interrupts aber nicht, kommen sie doch direkt von der Hardware.

Die gute Absicht in allen Ehren, so entwickelte sich doch eine längliche Diskussion auf der Kernel-Mailingliste um diesen Vorschlag. Beispielsweise gibt es synchrone NMIs, die nach MCEs erfolgen – also nach den Machine Check Exceptions, die von Windows als BSOD (Blue Screen of Death) bekannt sind.

Irgendwann mischte sich sogar Linus selbst in die Diskussion ein und meinte: "Schert euch nicht so viel um die MCEs. Dann ist die verdammte Hardware kaputt und niemand sollte eigentlich auch nur auf die Idee eines synchronen MCE kommen." Als Beweis führt der Finne ein Beispiel aus der Itanium-Welt an, um zu belegen, dass in dem Fall ein MCE wirklich keine Rolle mehr spielt.

Torvalds weiter: "Wenn ein NMI durch einen MCE unterbrochen wird, kann man einfach davon ausgehen, dass die Maschine eh schon tot ist. Das braucht uns dann auch nicht mehr zu kümmern. Vielleicht kriegt man die Situation wieder hin, aber das ist definitiv nicht unser Problem."

Danach drehte sich die Diskussion mehr um die Frage, ob der Kernel in solchen und ähnlichen Fällen eher einen Deadlock oder eine Kernelpanic auszulösen hätte. Auch dazu Torvalds in gewohnt deutlicher Sprache: "MCE Hardware Designer sind verdammte Idioten ("F  *g Morons") und sollten sich nicht fortpflanzen dürfen."

MCE, so Torvalds, sei "grundlegend falsch designt, ein Stück Dreck, ein Paradebeispiel dafür, wie man es nicht mache", schreibt er sich in Rage und spart dabei nicht mit Kraftausdrücken. "Ich weigere mich, Hardware-Bugs zu fixen!"

Bei all den Rants gesteht Linus aber im Lauf der Diskussion auch ein, dass trotz der langen Leitung der Hardwarehersteller so mancher davon ernsthaft an den Problemen arbeitet wie etwa Intel. Dennoch: Manche Hardware ist für Torvalds so kaputt, dass es gar keinen Sinn ergebe, sich um deren Fehlermeldungen zu kümmern. Aber, so schreibt auch Borislav Petkov: "Wir müssen eben mit dem leben, was wir momentan vorfinden. Eine Wahl haben wir ohnehin nicht."

Container: Sicherheit oder Features?

Eigentlich sollte so ein Container identisch mit dem Hostsystem sein, aber einen Benutzer zugleich sicher vom Gastgeber und anderen Containern wegsperren. In der Praxis jedoch ist das gar nicht so trivial. Im Gegenteil, viele Features dürfen Container gar nicht supporten, weil sie böswilligen Anwendern bisweilen unerwartete Tunnel aus dem eigenen Gefängnis zu bohren erlauben.

In kürzlich hinzugefügten Hot-Add-Patches etwa entstand die Notwendigkeit, jedem Container einen eigenen Namespace zu verpassen, damit diese auf neu angeschlossene Geräte sauber zugreifen können. Doch dem widersprach Greg Kroah-Hartman, das habe man auf der Linux Plummers Conference eindeutig abgelehnt. "Bitte nicht weiter diskutieren", so versuchte GKH die aus seiner Sicht unnötige Diskussion abzuwürgen – ohne Erfolg.

Im weiteren Verlauf der Diskussion führten Entwickler mehr und mehr Beispiele an, um zu belegen, warum zum Beispiel Loop-Devices auch in Containern notwendig seien. Zunächst widersprach Greg rigoros, später akzeptierte er eine grundsätzlich mögliche Notwendigkeit unter bestimmten Voraussetzungen, blieb aber dabei, dass das konkrete Beispiel anders gelöst gehöre.

Dann sprang ihm James Bottomly zur Seite und erklärte ebenfalls: "Hotplug in einem Container ist ein Sicherheitsrisiko. Besser ist es, der Host macht Hotplug und nutzt Nsenter, um ein angeschlossenes Device im Einzelfall durchzureichen." Loop-Back-Mounten oder überhaupt unkontrolliertes Mounten sollte einem Container verboten bleiben, schreibt er.

Ab da verläuft sich dieser Thread in einer Sequenz von Beispielen, was erlaubt sein sollte und was nicht. Beide Seiten scheinen sich mit starken Argumenten gegenüberzustehen, die nicht einfach aufzulösen sind. Einig ist man sich aber, dass die Sicherheit oberste Priorität haben sollte. (Zack Brown/mfe)

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 1 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.