Fragen? Antworten! Siehe auch: Alternativlos
Das bringt natürlich niemandem was, wenn es um Security geht, aber es zahlt einer Menge Menschen die Gehälter, die so nie irgendwas substanzielles für das Gemeinwohl beitragen müssen.
Viele CERTs sind auch nichts anderes mehr als Mailinglisten-Verteiler für Datenbankeinträge.
Eines Tages wird jemand merken, dass man das auch vollständig automatisiert machen kann, und man braucht nicht mal "KI"! Das kann ein Perlskript aus den 1990ern erledigen! WE HAVE THE TECHNOLOGY!
Aber egal. Das war nicht der Punkt.
Der Punkt war, dass es endlose Datenbanken mit Sicherheitslücken gibt, und einen veritablen Riesenmarkt aus unseriösen Resellern, die Datenbankeinträge weiterverkaufen, die sie selbst kostenlos aus dem Internet gescraped haben. Wenn es nach mir ginge, würde man die alle in die Wüste schicken. Aber es geht nicht nach mir.
Einige Projekte haben jetzt klar die Meinung entwickelt, dass sie da nicht mitmachen wollen. Der Linux-Kernel ist z.B. so ein Projekt. Jahrelang haben die keine CVE-Datenbankeinträge eingetragen. Deren Standpunkt war, dass so gut wie alle Security-Bugs Bugs sind, und Bugs fixen wir hier. Jedes Kernel-Release hat Hunderte von Bugs. Einige von denen sind Security-Bugs. Was du brauchst ist keine Datenbank mit Vulns, was du brauchst ist den jeweils aktuellen Kernel. Alle Patches einspielen, sofort. Immer.
Da haben sie völlig Recht mit, inhaltlich. Aber es hat halt dazu geführt, dass sie ständig von so Datenbank-Administratoren angeheult wurden. Ist ja auch klar, denn diese Datenbank-Einträge-Dealer leben ja davon, dass ihre "Leistung" wertvoll aussieht. Je mehr Einträge sie haben, desto wichtiger sieht das aus.
Der Linux-Kernel hat dann irgendwann die Opposition aufgegeben und ist seit Februar diesen Jahres eine CNA, hat einen eigenen ID-Bereich und kann aus dem Bereich selbständig CVEs vergeben. Sie haben gewarnt: Wenn wir das tun, dann kriegt ihr echt viele CVEs von uns, weil im Kernel-Kontext so gut wie jeder Bug auch ein Security-Problem ist, wenn man nur aus dem richtigen Winkel drauf guckt.
Die Datenbank-Heinis haben Dollarzeichen in den Augen gekriegt und "yes please" gesagt. Und jetzt haut der Linux-Kernel pro Woche (!) ca 100 CVEs raus.
Ich habe nicht genug Popcorn für diese Gesamtsituation gerade.
Ihr könnt euch vorstellen, dass die kommerziellen Datenbankheinis alle feuchte Höschen haben jetzt. Die können für noch mehr kostenlos bezogenen Content anderen Leuten Rechnungen stellen! Kaching!!
Aber es gibt halt auch nichtkommerzielle CVE-Verteiler, u.a. das DFN-Cert, und die sind jetzt ein bisschen ungehalten (jemand hat mir eine Mail von deren Verteiler weitergeleitet) und haben angekündigt, dass sie die nicht alle übernehmen und verbreiten wollen, sondern sie wollen vorfiltern, welche wichtig sind und welche nicht.
Das ist natürlich nicht gut. Das kostet Arbeitszeit, die denen irgendjemand bezahlen muss.
Aber für mich als Außenstehenden ist das tolles Popcorn-Kino.
Microsoft Helping Out In Making The Linux Kernel Language More InclusiveEndlich!1!!
Ein aktueller Fall illustriert das ganz gut: SuSE Linux Enterprise Server 15 SP4 hat eine BSI-Zertifizierung gekriegt. Ausgestellt am 15.12.2023.
Die benutzen OpenSSL 1.1.1. Das war zu dem Zeitpunkt bereits seit Monaten End-of-Life. Das steht auch im auf Dezember 2023 datierten Report drin, dass sie OpenSSL 1.1.1 verwenden.
Deren OpenSSH hat glaube ich auch noch keine Post-Quantum-Crypto drin. Weiß da jemand genaueres? War jedenfalls nicht Teil des Tests.
So, meine Damen und Herren, sieht Compliance-Sesselfurzerei aus. Kostet viel Geld, bringt weniger als nichts.
Wenn sich bei euch jemand damit bewirbt, dass er ein BSI-CC-Zertifikat habt, dann wisst ihr hoffentlich spätestens ab jetzt, was ihr von dem zu halten habt.
Update: Das Produkt selbst hatte übrigens am 31. Dezember 2023 End-of-Life, also weniger als einen Monat nach Zertifizierung (außer man zahlt LTSS). (Danke, Veit)
Welches Problem?
"Nach verheerendem Angriff auf Südwestfalen-IT: 205 Kommunen lassen IT prüfen"
Hunderte Kommunen in NRW lassen ihre IT-Sicherheit überprüfen, die Landesregierung bezahlt das. Sie will das Land künftig besser vorbereitet wissen.Hier also meine Hilfe. Kostenlos sogar.
Erstens: Spart euch das. Die Prüfung ist bereits abgeschlossen. Die Ransomwarer haben euch geprüft und ihr seid durchgefallen. Das Geld gibt man am besten VOR dem erfolgreichen Angriff aus.
Zweitens: Schmeißt die vier apokalyptischen Reiter raus: Windows, Office, Exchange und Active Directory. Lasst euch eure IT als Webanwendung machen und installiert den Leuten dumme Terminals. Irgendwas Linux-basiertes mit Komplett-Lockdown, das keine Daten lokal speichern kann, und als read-only Image verteilt und automatisch geupdated wird.
ChromeOS hat gezeigt, dass das grundsätzlich geht. Sollte vielleicht mal jemand als Produkt anbieten. Sowas wie Chromeos Flex aber ohne Google.
Oder ... gut, ich meine, ihr könnt natürlich einfach weiterpfuschen. Wir sehen uns dann beim nächsten Ransomwarevorfall. *winke*
Sucht mal in eurem Browser die Liste der vertrauenswürdigen CAs heraus und macht euch selbst ein Bild.
Wenn ihr z.B. eine sichere Verbindung zu meinem Blog aufzubauen versucht, dann ist das Zertifikat normalerweise von Let's Encrypt signiert. Wenn, sagen wir mal, der "Verfassungs""schutz" findet, dass ich regierungsfeindliche Inhalte verbreite und reingucken will, was ihr bei mir lest, dann könnten sie sich in den Netzwerkverkehr zwischen euch und meinem Blog klemmen und einfach ein anderes Zertifikat vorzeigen.
Es gibt da natürlich Vorkehrungen, um zu verhindern, dass einfach irgendeine freidrehende staatliche Repressionsbehörde Zertifikate für anderer Leute Domains holt, aber wenn die CA unter staatliche Kontrolle steht, dann ist das natürlich nutzlos. Diese Art von Angriff ist nicht theoretisch. Letztes Jahr gab es so einen Angriff auf jabber.ru, wenn ihr euch erinnert.
Warum erzähle ich das alles? Einer der Ansätze, diesen Angriff zu verhindern, ist dass man einen anderen Cert Store angibt. Curl hat dafür eine Kommandozeilenoption. Dann übergibt man da einen Cert Store, der nur genau die CA beinhaltet, die man erwartet. Und schon hat man Certificate Pinning für Arme implementiert.
Außer man verwendet curl auf Apple-Geräten. Apples SSL-Library verwendet immer auch den System Cert Store, wo Zertifikate von unvertrauenswürdigen Organisationen wie ... Apple drin sind. Falls Apple also eines Tages findet, dass sie in alle eure Kommunikationsn reingucken wollen, um "Kinderpornos zu finden" oder was an dem Tag die Ausrede der Woche ist, dann könntet ihr euch mit --cacert bei curl nicht davor schützen.
Wer kauft solchen Leuten eigentlich ihre Produkte ab?
Bei Microsoft sind natürlich auch ein halbes Dutzend Microsoft-CAs in der Liste. Unter Linux haben die Distros in ihren Root Stores auch Dutzende von CAs drin. Insofern ist das eine berechtigte Sorge, da Certificate Pinning machen zu wollen.
Wieso verbreiten die jetzt diesen Schwachsinn mit den DDoS-Zahnbürsten? Ich weiß es auch nicht. Aber ich habe Vermutungen.
Erstens mal, der Vollständigkeit halber. Nein, es gab da keinen DDoS. Das war ein hypothetisches Szenario. Muss wohl bei der Übersetzung verloren gegangen sein.
Zweitens: Die hatten noch nie einen guten Ruf. Die hatten damals behauptet, sie hätten ein eigenes Realtime-OS gehackt, was sich dann als ein Linux herausstellte, wenn man das Image gegen den hartkodierten Wert XORt. Aber das sind ja alte Kamellen. Neuer ist "FortiSIEM - Multiple remote unauthenticated os command injection". Ah, die Königsklasse! In der "oh Mann ist das peinlich"-Liga!
Aber warte, Fefe, das war doch letztes Jahr. Das haben die doch bestimmt schnell gefixt.
Klar! Microsoft-Style! Der Patch war rottig und jetzt mussten sie für dieselben Bugs neue Patches machen.
Wer kauft bei solchen Leuten?!
Überlegt mal, wie einfach sich das BSI das machen könnte! Einfach gucken, was Gartner empfiehlt, und jeweils direkt eine Warnung raushauen. Fertig!
Update: Die Aargauer Zeitung sieht sich übrigens als Opfer und bestätigt, dass es sich um ein hypothetisches Szenario gehandelt habe. Das war bestimmt mit "KI"-Hilfe übersetzt. Softwarefehler. Kann man nichts machen.
We discovered a heap-based buffer overflow in the GNU C Library's __vsyslog_internal() function, which is called by both syslog() and vsyslog(). This vulnerability was introduced in glibc 2.37 (in August 2022)2024 ist das Jahr von Linux auf dem Desktop, habe ich gehört! (Danke, Fabian)
ECC sind redundante Codes zur Fehlerkorrektur bei Bitfehlern. Die Linuxer glauben, dass dieser ominöse Mechanismus aus dem Exploit ein Interface zu direkten Schreiben in den Cache sei, und der Cache hat bei Apple ECC und daher muss man auch die ECC-Werte ausrechnen und schreiben.
Das klingt für mich plausibel. Sehr schön, wenn Experten aus verschiedenen Bereichen zusammenkommen und sich gegenseitig voranbringen. (Danke, Justin)
glibc hat in ihrem ld.so tolle neue GNU-Features eingebaut und darin einen Buffer Overflow.
Die glibc-Leute haben noch keine neue Version veröffentlicht.
Dirk-Peter van Leeuwen, CEO of SUSE, said, “For decades, collaboration and shared success have been the building blocks of our open source community. We have a responsibility to defend these values. This investment will preserve the flow of innovation for years to come and ensures that customers and community alike are not subjected to vendor lock-in and have genuine choice tomorrow as well as today.”Dazu muss man wissen, dass der Mann erst seit ein paar Wochen Suse-Chef ist und vorher viele Jahre bei Redhat gearbeitet hat.Jetzt streiten sich die Nerds, ob das eine gute oder eine schlechte Nachricht ist. Ich persönlich bin weder mit Suse noch mit Redhat jemals warm geworden. Die "Stabilität" ist eine Fata Morgana, du schiebst nur die nötigen Arbeiten ewig lange auf. Und wenn du sie dann machen musst, ist die Welle so groß geworden, dass du das updaten nicht mehr leisten kannst.
The StackRot vulnerability has been present in the Linux kernel since version 6.1 when the VMA tree structure was changed from red-black trees to maple trees.Die Hybris dieser Leute immer, etablierten Code wegzuschmeißen, weil sie ja so viel schlauer sind als alle vor ihnen.Und dann erst mal Bugs einbauen, die der alte Code nicht hatte. Klar.
Erstens: Nitrokey verbreitet, dass der Qualcomm-Chipsatz deine privaten Daten in die Cloud hochlädt.
Das ist Blödsinn. Der Cloud-Kontakt von dem Qualcomm-Chipsatz ist das Runterladen des GPS-Almanachs. GPS funktioniert so, dass Satelliten Signale schicken, und du kannst dann deine Position ausrechnen, wenn du die Signale siehst, und weißt, wo die Satelliten gerade waren. Im Signal ist ein Timestamp, mit dem du sehen kannst, wie lange das Signal unterwegs war. Jetzt musst du nur noch wissen, wo die Satelliten sind, und da deren Laufbahnen ständig nachkorrigiert werden, sind das keine statischen Daten. Die Positionen stehen in einem sogenannten Almanach, und den lädt Qualcomm halt alle zwei Wochen oder so aus der Cloud nach.
Dass das über HTTP geht, kann man kritisieren. Aber was Nitrokey hier verbreitet überschreitet die Grenze der grotesken Inkompetenz und sieht für mich nach mutwilliger Irreführung aus.
Zweitens: Heise verbreitet, dass Google Authenticator deine Zwei-Faktor-Seeds in die Cloud backupt und dabei nicht Ende-zu-Ende-Krypto einsetzt.
Analysieren wir doch mal die Situation. Wir haben hier ein Cloud-Backup "im Klartext", d.h. der Typ in der Cloud kann die Daten einsehen. Der Weg zur Cloud ist TLS-verschlüsselt, und Google spricht jetzt davon, dass die Daten auch verschlüsselt bei ihnen abgelegt sind. Das ist natürlich ekelhafte Irreführung, denn damit meinen sie Platten-Krypto. Das schützt gegen "jemand bricht bei Google ein und klaut die Platten". Es schützt nicht gegen "jemand bricht bei Google ein und kopiert die Daten". Das ist das Szenario, vor dem man hier Sorgen haben sollte, und da hat Heise einen Punkt, dass das ein Problem ist.
Auf der anderen Seite läuft auf deinem Telefon Google-Software. Das Google-Android schützt deine Seeds auf dem Telefon vor dem Zugriff anderer Apps und verhindert Netzwerk-Kommunikation der Google Authenticator App. Wenn dein Bedrohungsmodell also ist, dass jemand bei Google einbricht und dort böse Dinge tun kann, dann hast du eh schon komplett verloren, weil derjenige dir auch ein böses Android-Update schicken kann, das deine Seeds auf Facebook postet oder bei Github hochlädt oder so.
Was hätte man besser machen können? Man könnte das Backup mit einem Schlüssel verschlüsseln, den Google nicht kennt. Allerdings muss diesen Schlüssel halt dein Telefon kennen, sonst kann es ja nicht die Daten damit verschlüsseln, und die Software auf deinem Telefon kommt von Google. Die Forderung hier ist also gerade, dass Google deine Daten vor Google schützt. Das klingt nicht nur bekloppt, das ist bekloppt.
Zusammenfassend: Ich würde nie meine Daten zu Google (oder sonstwo) in die Cloud backuppen oder auch nur mein Windows an einen Microsoft-Account binden. Aber selbst mit dieser paranoiden Grundeinstellung bin ich machtlos, mich auf einem Android-Telefon gegen böse Updates zu wehren.
Insofern: Ist das ein Problem? Ja. Aber ein weitgehend akademisches. Mit "E2E" (passt in diesem Szenario eigentlich nicht, weil beide Enden du selbst bist) würde man sich gegen ein Szenario schützen, wo ein Einbrecher es innerhalb von Google bis zu dem Backup-Storage schafft, aber nicht die Updates kompromittiert kriegt. Ist das sonderlich realistisch? Müsst ihr selbst beurteilen. Aus meiner Sicht sieht das nach "Sommerloch bei Heise" aus. Wenn du mit Firmen wie Microsoft oder Google überhaupt kooperierst, hast du schon direkt ziemlich komplett verloren. So zu tun als gäbe es da Graustufen und man hätte aber eigentlich doch noch Reste von Kontrolle ist aus meiner Sicht Augenwischerei.
Ist 2FA damit vollständig Bullshit? Ich bin grundsätzlich kein Freund von 2FA, weil das im Wesentlichen nur einen Zweck erfüllt: Eine Beweislast- und Schuldumkehr von Google zu mir. Vorher: Mein Google-Account wird gehackt? Google war Schuld. Nachher: Mein Google-Account wird gehackt? Ich bin Schuld.
Wieso würde ich da mitspielen wollen? Sehe ich nicht ein.
Aber WENN man schon 2FA macht, dann zwischen konkurrierenden Firmen. Wenn Microsoft 2FA erzwingt, dann generiere das Token unter Android. Wenn Google 2FA erzwingt, generiere das Token unter Windows oder Linux oder sonstwo, wo Google nicht rankommt. D.h. dann auch: Wo kein Chrome läuft!
Der ganze postulierte Sicherheitsgewinn von 2FA kommt daher, dass Username+Passwort und Token nicht an derselben Stelle abgreifbar sind. Das muss man dann auch sicherstellen. Wenn du also Google Authenticator verwendest, dann darfst du dich von dem Android aus nie in den Account einloggen, sonst kann Google auch Username+Passwort sehen (über die Keyboard-App u.a.).
Update: Hat der Fefe gerade argumentiert, dass man Cloud-Backup nicht verschlüsseln muss? Nein! Das ist grundsätzlich eine gute Idee. Da gibt es gute Gründe für, Backups immer zu verschlüsseln, auch wenn das Backup lokal ist. Nehmen wir an, eine der Platten geht kaputt und du willst die entsorgen. Wenn die Backups verschlüsselt waren, kannst du die einfach wegschmeißen (der Schlüssel darf dann natürlich nicht daneben liegen). Wenn die Backup-Infrastruktur komplett nur verschlüsselte Daten sieht, kannst du da unvertrauenswürdige Infrastruktur einsetzen (z.B. ein SMB-Share, NFS, Cloud-Storage, whatever). Da kann dann nichts absichtlich oder versehentlich leaken. Wenn die Software Temp-Files rumliegen lässt oder Daten im RAM cached, dann musst du dir keine Sorgen machen.
Aber die Gelegenheit war günstig, mal zu zeigen, wie man so eine Risikoanalyse in der Praxis machen sollte. Mein Argument war nicht, dass Backup-Crypto nicht notwendig ist, sondern dass Google auch mit Backup-Crypto an deine Daten rankommt und daher die Auswirkungen nicht so groß sind wie man erstmal instinktiv annehmen könnte.
Es gibt noch ein Argument für E2E-Krypto in diesem Fall. Wenn jemand bei Google deine Daten abgreifen will, kann der im Moment entweder dir ein böses Update schicken oder deine Backups abgreifen. Die Risiken sind additiv. Wenn du die Backups ordentlich verschlüsselt hast, bleibt zwar der andere Teil des Risikos bestehen, aber dieser Teil fällt weg. Hilft halt nichts gegen "der CEO / das FBI verlangt Zugriff auf deine Daten", und das ist der Fall, der mir persönlich mehr Sorgen machen würde.
Update: Ja aber Fefe, muss ich mir für meinen Google-Account ein Iphone kaufen, damit das 2FA auf einem anderen Gerät als dem Android läuft? Nein. Für sowas kann man auch FIDO2-Tokens nehmen, von Yubikey oder so.
Es gibt natürlich Gegenbewegungen, z.B. Coreboot, aber die laufen nur auf einer Handvoll von Mainboard-CPU-Kombinationen.
Inzwischen ist es so schlimm, dass das UEFI-BIOS einen Bereich hat, wo der Hersteller Windows-Treiber-Blobs hinpacken kann, die Windows dann ohne Nachzufragen installiert. Von einer Souveränität des Besitzers der Hardware kann schon lange keine Rede mehr sein.
Das ist alles so schlimm, dass es inzwischen ein Geschäftsmodell ist, eine Hardware anzubieten, wo nur noch Blobs von dem Hersteller drin sind, mit dem man einen Vertrag geschlossen hat, nicht auch noch von Dutzenden von anderen Leuten.
Es ist nicht nur so, dass man den Quellcode für die Blobs nicht hat, sondern die sind z.B. bei Intel und AMD gerne auch verschlüsselt und signiert. Selbst wenn man den Quellcode hätte, könnte man damit nicht selber einen Blob bauen und verwenden, weil man die Schlüssel nicht hat.
Zumindest eine Sache könnte man aber mal fordern: Dass die Hersteller den Quellcode veröffentlichen und Reproducible Builds haben. Dann kann ich den Quellcode nehmen und bauen und gucken, ob dasselbe Blob rauskommt (vor der Signatur). Hilft natürlich nicht, wenn das auch noch verschlüsselt ist, und ich kann dann immer noch keine eigene Version bauen und hochladen. Aber es wäre in Sachen Vertrauensbildung ein echter Meilenstein.
Stellt sich raus: Intel hat damit jetzt angefangen (ganz runterscrollen). Aus meiner Sicht ist das ein absoluter Game Changer für die ganze Industrie. Ich hoffe mal, dass das Schule macht.
Der Code ist das jetzt offenbar seit Monaten öffentlich im Internet und es hat keiner mitgekriegt :-)
Der Grund für dieses Design ist, dass so meine Daten sicher sind. Das Merge kann man über das Netz nicht anstoßen, und der tinyldap läuft daher auch nicht mit Zugriffsrechten, die mehr als Lesen von der Binärdatenbank erlauben würden.
Inzwischen haben tinyldap und mein Blog auch Schreibzugriff implementiert. Das Blog sagt dann halt dem tinyldap, es will was ändern, und tinyldap hängt die Änderung an das Journal an.
Wenn irgendwo was schiefgeht, kann ich das journal mit einem normalen Texteditor reparieren. Leider habe ich mir angewöhnt, bevor das Blog ein Ändern-Interface hatte, Updates von Hand mit vim im Journal einzupflegen. Wenn ich dabei die Syntax kaputtmache, dann wirft tinyldap beim Starten einen Fehler und das Blog sagt "ldapbind failed".
Wieso kommen in letzter Zeit häufiger Fehler vor? Weil ich verschiedene Terminals unter Windows durchprobiere. Ich habe immer putty verwendet, aber auf dem neuen Laptop in den letzten beiden Versionen hängt sich das gerne mal auf, wenn ich parallel eine Fullscreen-Grafikanwendung aufhabe, d.h. ein Spiel spiele. Daher habe ich mal das bei Windows beiliegende ssh probiert, in dem Windows beiliegenden Standard-Terminal, in dem cmd startet.
Das funktioniert soweit leidlich gut und hängt sich auch nicht auf, aber bei Backspace schickt es Delete. Das war unter Linux auch immer Standard, aber nicht bei meiner Distro und auf meinen Rechnern. Auf meinen Rechnern schickt Backspace Backspace und Delete schickt Delete. Und die Gegenseite erwartet das auch so.
Was jetzt passiert: Ich tippe was ein, spät nachts, vertippe mich, tippe Backspace, das Terminal schickt Delete, und wenn ich das am Ende der Eingabe mache, dann löscht das die Leerzeile am Ende. Das verletzt das LDIF-Format und tinyldap mag das dann nicht.
Ich habe bisher nicht herausgefunden, wie ich diesem Terminal sagen kann, dass ich gerne bei Backspace Backspace haben will und nicht Delete. Falls jemand einen sachdienlichen Hinweis hat: Her damit!
Da kommen jedenfalls in letzter Zeit die "ldapbind failed"-Fehler her. Operator Error. Ich müsste mir entweder angewöhnen, nach dem Ändern nochmal Reload zu machen im Browser, oder ich müsste mir angewöhnen, halt das Edit-Interface zu benutzen, das ja extra dafür da ist.
Software umschreiben ist immer einfacher als jahrelange Gewohnheiten zu ändern. Seufz.
Update: Alle Terminals bisher haben Nachteile. Das Windows-Terminal macht z.B. Copy-und-Paste schlecht. Man markiert etwas mit der Maus, aber dann muss man erst noch Return drücken, damit das in der Zwischenablage landet. Da stolpere ich jedes Mal drüber. Bei putty ist das nach dem Markieren in der Zwischenblage.
Ansonsten habe ich noch alacritty probiert. Da stolpere ich auch immer über Copy-und-Paste. Da muss ich nach dem Markieren Ctrl-Shift-C drücken, damit es in der Zwischenablage landet, und zum Einfügen Ctrl-Shift-V. Ich hätte gerne Pasten mit der mittleren oder rechten Maustaste. Das kann man glaube ich sogar konfigurieren bei alacritty, aber Ctrl-Shift-C kann man nicht wegkonfigurieren. Schade.
Update: Oh, stellt sich raus: Es gibt doch noch Terminal-Einstellungen. Die sind nicht mehr unter dem Logo links oben sondern unter dem invertierten Dach rechts neben den Tabs. Da kann man das Copy-Verhalten umschalten. Oh geil und da kann man Retro-Mode einschalten! Nur Backspace kann man offenbar nicht umkonfigurieren.
Update: Wenn man in den Settings die JSON-Config öffnet, kann man dort folgendes command eintragen:
{ "command": { "action": "sendInput", "input": "\b" }, "keys": "backspace" }Dann geht Backspace!
Update: Und in Alacritty kann man einstellen, dass er direkt ins Clipboard selektieren soll (save_to_clipboard). Nett!
Hauptanforderungen waren:
Tuxedo kann keine aktuellen Ryzens, Schenker auch nicht.
Sekundäranforderung war, dass ich nie wieder Nvidia Geld in den Rachen werfen wollte, aber da hätte ich mich von abbringen lassen, wenn der Rest wirklich unfassbar großartig gewesen wäre. War er aber nirgendwo.
Dass Asus keinen guten Ruf hat, müsst ihr mir nicht erklären. Das Zephyrus ist angeblich nicht von Asus sondern von AMD gebaut worden, die damit zeigen wollten, dass auch sie eine wirklich überzeugende Plattform hinkriegen. Ist ja auch eigentlich ziemlich coole Scheiße, was die da in Sachung Performance und Kühlung hingekriegt haben. Müsste jetzt nur noch zuverlässig funktionieren, auch unter Linux.
Hier kurz meine bisherigen Erfahrungen.
Erstens: Das Gerät hat eine aktuelle Zen-CPU und auch eine diskrete AMD-GPU. Das war der Grund, wieso ich das überhaupt angeschafft habe.
Die Erfahrungen bisher sind recht durchwachsen. Erstens war die Idee, dass man auf heutigen CPUs keine Kompromisse mehr machen muss zwischen Batterielaufzeit und Performance. Du kannst das eine oder das andere haben. Vorbei sind die Zeiten, bei denen du auf einem Gaming-Laptop nicht durch sparsame Nutzung einen Tag durchhalten konntest. So dachte ich jedenfalls. In der Praxis stimmt das schlicht nicht.
Unter Linux hängt sich die AMD-Grafik mehrfach pro Tag spontan auf. Wenn ich das eingebaute Panel per xrandr ausschalte, dann kriegt Video-Abspielen plötzlich nur noch einen Frame alle zwei Sekunden raus. Weniger als 20W Stromverbrauch habe ich bisher noch nicht gemessen gekriegt.
Displayport gibt es nicht, nur HDMI. Wenn man HDMI ansteckt, kann man auch unter Windows plötzlich die diskrete GPU nicht mehr abschalten. The fuck?!
Das Mauspad ist I2C und erkennt unter Linux keine Gesten.
Zwischen der GPU und meinem Monitor gibt es einen unheiligen Pakt, dass offenbar beide zu erkennen versuchen, ob die andere Seite da ist, und sonst Stromsparmodus machen. Sobald der Laptop ne Weile keine Tastatureingaben hatte und den Monitor abschaltet, bleibt der auch aus, bis ich ihn entweder ab- und wieder anstöpsel, oder ein paar Sekunden in Folge mit den (beschissen unergonomischen) Bedienelemenenten am Monitor interagiere.
Wahrscheinlich ist die Hälfte davon etwas, was ich durch geschicktere Bedienung oder Konfiguration beseitigen könnte.
Ich bin mir sicher, nächstes Jahr kriegen wir dann Linux auf dem Desktop!1!!
Immerhin, die Compile-Leistung der Ryzen-CPUs hat meine Erwartungen noch übertroffen.
Erwähnte ich, dass Asus da eine Tastatur mit Enter-Taste nach amerikanischem Modell einbaut? Also nur halbe Bauhöhe der üblichen Enter-Taste? PgUp und PgDn, Home und Enter haben sie sich gleich ganz gespart. Kann man ja über Fn-Taste fummeln. Oder so.
Das machen sie wieder wett, indem sie dir ungefragt ein bescheuertes, nerviges Vrooom-Geräusch reindrücken beim Booten. Das kann man immerhin abschalten. Herr, wirf Hirn vom Himmel!
Wer also von euch mit dem Gedanken spielte, ein G14 Zephyrus für Arbeiten unter Linux zu kaufen, dem kann ich nach aktuellem Stand nur davon abraten. Leider scheint es ansonsten keine Laptophersteller zu geben, die vergleichbare Hardware anbieten. Sind entweder alle noch am Abverkaufen der Vorgeneration oder haben gar kein AMD am Start.
Oh, eines noch. Man kann den relativ gut aufschrauben und dann die NVMe und einen der beiden RAM-Riegel tauschen. Maximum-Bestückung ist 32 GB, im anderen sind 8 fest verlötet. In früheren Modellen gab es einen 2. NVMe-Slot, darauf hatte ich gehofft. Das ist bei der aktuellen Revision aber nicht mehr so.
Update: Es gibt noch eine Eigenschaft, die mich überrascht hat. Das Bootlogo erscheint nur auf dem eingebauten Display. Auch das BIOS erscheint nur dort, und wenn ich in Grub boote, dann auch der Grub-Screen. Das BIOS erkennt und initialisiert also externe Bildschirme nicht ordentlich.
Jetzt fragen hier Leute, wie ich kein Thinkpad gekauft habe, da gibt es auch eines mit aktuellem Ryzen. Thinkpad mag ich nicht, und in dem Modell ist die GPU schwächer und das RAM nicht upgradebar aufgelötet. Außerdem gibt es weder HDMI noch USB-A. Das sind bei mir alles Ausschlusskriterien. Ich hab mich schon bei dem Asus geärgert, dass sie kein Kabel-Ethernet mehr haben. Da bewegt sich echt einiges in die falsche Richtung finde ich.
Finde ich eine sehr gute Idee. Wünsche ich mir auch für Linux. (Danke, Leo)
Die gibt er dann mit einem magischen setsockopt dem Kernel, und dann kann man mit dem Socket einfach wie früher read, write und sendfile machen und der Kernel übernimmt die symmetrische Krypto und die TLS-Paketierung.
Warum würde man das machen wollen? Nun, es gibt zwei Gründe. Erstens kann man so wieder sendfile machen. sendfile kriegt einen Socket, einen File Descriptor, ein Offset und eine Länge, und schickt dann das Segment aus der Datei über den Socket raus. Im Gegensatz zu traditionellem read und write spart das einmal eine Kopie der Daten. Das Google-Stichwort ist dann auch Zero-Copy.
Nun, zero copy macht Kernel-TLS natürlich auch nicht draus, der muss ja die Daten verschlüsseln und das macht ja auch eine Kopie. Allerdings gibt es Netzwerk-Karten, die TLS Offload beherrschen. Ich habe sowas nicht, aber es existiert, und dann kann der Kernel die Krypto direkt durchreichen an die Hardware, und kann es möglicherweise gar einrichten, dass die Netzwerkkarte sich die zu schickenden Daten direkt per DMA vom NVMe holt, oder halt aus dem RAM, ohne dass der Kernel die anfassen muss.
Naja gut, denkt ihr euch jetzt vielleicht, aber macht das wirklich so viel aus? Nicht bei Fast Ethernet und Gigabit geht auch noch ohne. Aber bei 10 und 100 GBit kriegt man die Leitungen ohne Zero Copy nicht saturiert. Und natürlich hat man mehr Ressourcen für andere Arbeit auf dem Server, je weniger man mit sinnlosem Hin- und Herkopieren von Daten verbraucht.
gatling habe ich damals explizit mit dem Ziel geschrieben, mich mal in Zero-Copy-TCP einzuarbeiten, aber das ist mit TLS erstmal wertlos. Bis jetzt.
Zu meiner großen Freude unterstützt OpenSSL seit Version 3 das zumindest auf dem Papier. Allerdings konnte ich das nicht funktionieren sehen. Heute habe ich das mal debugged. Auflösung: Die Kernelheader in /usr/include/linux waren zu alt :-)
Heute habe ich das zu Laufen gekriegt, und hatte bei wget einer 1 GB-Datei über das Loopback-Device sowas wie 1 GB/sec Durchsatz.
Das war mit dem alten TLS-Code, der mmap+SSL_write machte. Da hat man dann kein sendfile. Daher hat OpenSSL 3 eine Funktion namens SSL_sendfile nachgereicht. Die konnte man in meiner Abstraktion in libowfat nicht benutzen, daher hab ich die heute ein bisschen erweitert und dann in gatling per Callback SSL_sendfile eingebaut, und dann hatte ich im selben Test 1,9 GB/sec Durchsatz.
Fand ich sehr beeindruckend, muss ich euch sagen. Schön zu sehen, dass sich die Technologie auch ein bisschen weiterentwickelt.
In der Praxis wird das bei meinem Blog oder so nicht viel bewirken, weil der Großteil der CPU-Zeit da für das Handshake draufgeht, nicht für die symmetrische Krypto. Trotzdem. Hocherfreulich, wenn in der IT mal was schneller wird, und nicht immer nur langsamer und bloatiger.
Update: Richtig konsequent zuende getrieben hat das Netflix, wobei die allerdings FreeBSD und nicht Linux verwenden. Die haben dazu einen ziemlich sehenswerten Vortrag gehalten: Folien, Video.
Update: Oh und natürlich hilft Kernel-TLS mit Offloading auch auf schwachbrüstigen Embedded-SOCs, die auf Kosten- und Stromsparen ausgelegt werden, nicht auf CPU-Power.
Nach ein bisschen herumprobieren kommt raus, dass dasselbe clang-Binary aus dem Build-Verzeichnis aufgerufen funktioniert, aber der holt sich sein xmmintrin.h auch aus dem Build-Verzeichnis. Mein Produktions-Bleedinge-Edge-clang ist in /opt/llvm und das ist aus einem Squashfs mit zstd gemountet.
Stellt sich raus: Wenn ich das Binary aus dem Buildverzeichnis aufrufe, aber per -I xmmintrin.h aus dem squashfs hole, dann platzt das.
Diese Konstellation habe ich seit Jahren auf anderen Geräten im Einsatz. Der Unterschied ist, dass das neue Gerät AVX512 kann.
Meine Arbeitshypothese ist gerade, dass squashfs+zstd im Kernel AVX512 benutzt und damit Register im Userspace übernagelt. Ich erinnere mich dunkel an eine "ist das gültiges UTF-8"-Implementation mit AVX512 von diesem einen kanadischen Professor und seiner Arbeitsgruppe. Jetzt habe ich jedenfalls clang ohne squashfs installiert und es läuft sauber durch.
Das finde ich ja mal äußerst beunruhigend hier gerade. Wenn das stimmt, habe ich mit den Auswirkungen noch mal mehr als Glück gehabt.
Update: Stellt sich raus: Das Problem tritt auch ohne AVX512 auf. Das hat nichts damit zu tun. squashfs ist gerade (Linux 6.0) kaputt.
It would appear that there is a set of memory-related vulnerabilities in the kernel's WiFi stack that can be exploited over the air via malicious packetsJa super!
Man stelle sich das mal vor! Die haben jetzt Jahre der Entbehrung vor sich und am Ende haben sie digitale Souveränität, eine stabile, nicht kaputtmachbare Basis für ihre IT, haben Knowhow im Land, weil sie die Software selber geschrieben haben, und haben dabei Arbeitsplätze noch und nöcher geschaffen. Auf dem Weg müssen sie auch noch auf die wertvolle Expertise von McKinsey und co verzichten! Haha, was für Deppen, ey!1!!
Manchmal glaube ich ja, dass wir auch mal wieder einen Krieg verlieren müssen und fette Sanktionen brauchen, bevor es hier mal wieder Aufschwung geben kann. Bis hier mal wieder gute Ideen umgesetzt werden. Stattdessen kriegen wir elektronische Rezepte in der Blockchain. Kannste dir gar nicht ausdenken.
Das ist normalerweise in Ordnung. Aber eine Sache hat mich immer gestört. Ich kann nicht einen leeren Container aufsetzen und dann in dem Container ein Programm ausführen. Das Programm (die Datei) muss selbst in dem Container liegen.
Das Programm kann den Container selber aufsetzen, nachdem man es gestartet hat, und sich dann in dem Container einschließen. Das geht.
Aber jetzt geht auch ein Programm in einem Container starten. Linux hat jetzt einen Syscall namens execveat (schon seit Jahren, seit Version 3.14 sagt die Man Page). Das nimmt wie openat einen "dirfd", wo man den Deskriptor eines Verzeichnisses reingeben kann, und relativ zu dem werden relative Dateinamen dann aufgelöst. Aber es gibt auch ein Flags-Argument, und da gibt es das Flag AT_EMPTY_PATH. Wenn man das übergibt, dann ist dirfd nicht ein Verzeichnis sondern das Binary, das man ausführen will. Damit wird jetzt ein Szenario möglich, in dem man ein Binary öffnet, dann ein chroot oder Namespace-basiertes Jail aufsetzt, in dem das Binary nicht liegt, und dann in dem Jail das Binary ausführt.
Finde ich super. Wollte ich schon länger haben. Hilft natürlich erstmal nur mir, denn dynamisch gelinkte Programme brauchen immer noch ihre shared libraries in dem Jail, und Skripte brauchen immer noch ihre Interpreter in dem Jail. Das will man ja eigentlich auch nicht haben. Aber ich linke ja statisch, für mich reicht das.
Es hat noch eine interessante Auswirkung. Man kann unter Linux mit memfd_create einen Deskriptor auf eine Datei erzeugen, die nie die Festplatte berührt. Da kann man dann eine Malware reinschreiben und so ausführen. "Endpoint Security", die Dateien auf der Platte scannt, würde das gar nicht sehen.
Man konnte sich das bisher zusammentricksen, indem man execve auf /proc/self/fd/15 macht, aber dafür muss in dem Jail /proc gemountet sein.
Ich glaube, Hyundai hat da gerade die neue Referenz gesetzt.
A developer says it was possible to run their own software on the car infotainment hardware after discovering the vehicle's manufacturer had secured its system using keys that were not only publicly known but had been lifted from programming examples.Ja, richtig gelesen! Die haben mit Schlüsseln aus Programmierbeispielen "verschlüsselt"!Und nicht nur das. Sie haben die Keys auch noch auf ihre Webseite hochgeladen.
As luck would have it, "greenluigi1" found on Mobis's website a Linux setup script that created a suitable ZIP file for performing a system update.The script included the necessary ZIP password for the system update archives, along with an AES symmetric Cipher-Block-Chaining (CBC) encryption key (a single key rather than an RSA asymmetric public/private key pair) and the IV (initialization vector) value to encrypt the firmware images.
Gut, aber das hatten wir ja schon häufiger, dass Leute ihre Keys bei Github und co hochluden.Zurück zu den Keys, wo die herkamen.
"Turns out the [AES] encryption key in that script is the first AES 128-bit CBC example key listed in the NIST document SP800-38A [PDF]".Ja gut, wenn die das ZIP-Passwort und den AES-Key öffentlich zugänglich haben, vielleicht ist dann auch der RSA-Schlüssel öffentlich!Luck held out, in a way. "Greenluigi1" found within the firmware image the RSA public key used by the updater, and searched online for a portion of that key. The search results pointed to a common public key that shows up in online tutorials like "RSA Encryption & Decryption Example with OpenSSL in C."That tutorial and other projects implementing OpenSSL include within their source code that public key and the corresponding RSA private key.
Und das, meine Damen und Herren, ist ein neuer Rekord. So viel geballte Inkompetenz habe ich persönlich noch nie gesehen.
Auf der einen Seite will ich nicht nur schreiben, wie kaputt alles ist. Auf der anderen Seite will ich aber auch nicht dafür sorgen, dass Leute länger bei Windows bleiben, weil sie dank irgendwelcher Konfigurationsratschläge den Eindruck haben, sie könnten das schon irgendwie absichern. Zu guter Letzt bin ich Code Auditor, nicht Admin. Was man da alles konfigurieren kann ist nicht mein Spezialgebiet. Am Ende verbreite ich noch Unfug?
Daher haben meine Zero-Trust-Folien am Ende eine eher allgemeine Vision.
Allerdings kam ein Leserbrief mit konkreten Ratschlägen rein, den ich jetzt mal veröffentlichen möchte. Nehmt das aber bitte nicht als abzuarbeitendes Howto sondern als Grundlage für eigene Recherchen. Ziel der Übung sollte sein, dass ihr ein bisschen mehr verstanden habt, wie die Dinge funktionieren.
zu deiner Zero Trust Präsi möchte ich mal etwas zur Windows Security einwerfen. Sorry, ist etwas länglich geworden.Anmerkung von mir: Die ct hatte dazu mal ein Tool veröffentlicht, da könnt ihr damit mal herumspielen.Wir sind IT Dienstleister und übernehmen in der Regel den Service einer bestehenden IT Landschaft die entweder vorher durch den Kunden oder durch einen anderen Dienstleister betreut wurde. KMU 1 bis 500 MA.
Dahin zu gehen und den Kunden Windows und Outlook wegzunehmen wird in der Regel nicht gelingen. Wenn es möglich ist einen neuen Server auf Linux hoch zu ziehen könnte man das vorschlagen und umsetzen, da hört es aber dann auch schon auf.Der Satz "Das geht, weil Sie Outlook und Office benutzen" stimmt leider in den meisten Fällen, obwohl das nicht so sein müsste.
MS liefert schon seit Windows 2000 allerhand Techniken mit die genau das alles verhindern. Wir haben aber noch nicht einen Kunden bekommen bei dem irgendwas davon aktiv war und holen das alles schleunigst nach. Das schlimmste was uns als Dienstleister passieren kann, ist ein Ransomwarebefall eines Kunden bei dem wir die Schuld tragen, weil deren Systeme nicht sicher sind, obwohl man es *ohne* Anschaffung zusätzlicher Software hätte besser machen können. Der Kunde verlässt sich darauf dass wir ihm eine sichere Arbeitsumgebung geben. Es ist ein Unding, dass ein aktueller Windows Server bei einer frischen Active Directory Installation immer noch fast die gleichen Sicherheitsdefaults verwendet wie es in 2000 eingeführt wurde und so kommt es, dass von all dem was nun kommt in freier Wildbahn oft nichts zu sehen ist.1: Software Restriction Policies (SRP), ja ich weiß ist deprecated, läuft aber selbst auf Win 11 noch. MS wollte das durch Applocker ersetzen. Ist aber auch deprecated. MS will das durch Defender Application Control ersetzen, geht aber nur per XML oder und nur in Enterprise oder so. Wir bleiben bisher bei SRP, weil das keine Enterprise Lizenzen braucht und seit Win 2000 unverändert läuft. Muss man halt nach jedem größerem Update testen ob es noch geht.
Was tut es? Windows führt nur noch EXE, CMD/BAT, PS1, sonstwas aus Pfaden aus die der Admin per GPO festgelegt hat. Outlook kopiert den Anhang aus der Mail in ein Temp Verzeichnis und will es dort starten. Das darf es dann nicht mehr. Admins installieren nach c:\program files\. Das ist erlaubt. Ein User darf da nicht schreiben.GPO ist ein Group Policy Object, oder in deutschen Versionen: Gruppenrichtlinien.
MS torpediert es aber selbst mit Programmen die sich unter AppData\Local installieren. Teams z.B. und andere Hersteller sind da auch keine Vorbilder. Muss man sehr enge Ausnahmen setzen und das Risiko in kauf nehmen.2: Makros. Ja, der gelbe Balken bringt nix. Per GPO hart ganz abschalten. Brauchen ohnehin die wenigsten Anwender. Die die es brauchen, kann man geziehlt auf die Dokumente einschränken für die es gehen soll. Was machen die Malware Makros? VBS oder Powershell Script ausführen und Payload nachladen und starten. Geht eigentlich durch SRP schon nicht mehr, aber es soll ja Bugs geben die vielleicht um SRP drum rum kommen.
3: Beschafft sich lokale Admin-Rechte und übernimmt den Domain Controller.In meinen Folien hatte ich gesagt, dass Lateral Movement nicht Teil des Threat Models ist. Ich bin mir unsicher, inwieweit man das verallgemeinern kann. Ich unterhalte mich zu Ransomware mit Kumpels, die weiter oben auf der Eskalationsskala sitzen, die sehen dann praktisch ausschließlich Fälle, bei denen der AD übernommen werden konnte. Ich habe leider keine Zahlen, wie hoch der Prozentsatz der Ransomware-Angriffe ist, die man verhindern könnte, wenn man Lateral Movement unterbindet. ALLERDINGS: Wenn man durch andere Maßnahmen dafür sorgt, dass der Sprung zum Domain Admin nicht geht, dann wird die Verhinderung von Lateral Movement plötzlich eine wichtige Maßnahme. Genau das spricht der Leserbrief hier an.
Wenn 1 und 2 versagt hat kommen wir dahin. Nächste Verteidigungslinie ist Lateral Movement zu verhindern.Es gibt genug GPOs zum härten der Systeme, aber man klemmt halt damit alten Legacy ab, was ich aus technischen Sicht eigentlich ganz gut finde. NTLM Auth weg, Credential Caching für Admins und generell Server abschalten, Debugging Rechte global abschalten und nur im Einzelfall erlauben. LAPS benutzen, auch für Server. Das macht es Mimikatz schon ganz schön schwer an verwertbare Daten zu kommen.
Mit ESAE hat MS schon lang ein Konzept die Admin Ebenen voneinander zu trennen. Man muss auch nicht zwingend mehrere Domänen betreiben um den wichtigsten Teil davon umzusetzen.Ich hab das in einem Nebensatz irgendwo erwähnt, dass man die Admin-Accounts aufteilen soll, und dass der Domain Admin nicht an die Datenbanken können soll. Der Leser hier hat völlig Recht, das kann und sollte man noch mehr auftrennen. Dann hat man tatsächlich etwas getan, um im Threat Model ein Bedrohungsrisiko zu senken.
Bei uns darf ein Domain Admin nicht mal PCs in Domänen aufnehmen. Niemals sollte sich ein Domain Admin an einem Client anmelden und das lässt sich auch per GPO verhindern.
Der darf auch nur an Domain Controller, die CA und ähnliche Systeme. Ein Server Admin darf da nicht hin und der darf auch nicht an Clients. Ja, der Domain Admin hat dann halt 4 User Accounts. User, Client Admin, Server Admin, Domain Admin. Natürlich mit Grundverschiedenen Passwörtern. Kommt man mit klar.
Selbst ein Keylogger auf dem Client bekommt dann höchstens den Admin für die Clients, aber kann immer noch nicht auf Server oder gar Domain Controller.Dazu sei angemerkt, dass auch mit Smart Cards im Hintergrund immer noch Kerberos läuft mit Kerberos-Tickets, die abgreifbar sind. Aber die laufen wenigstens nach einer Weile aus.4. Benutz Smart Cards für die Admins und lass nur Anmeldungen per Smart Card zu. In dem Fall kann ein Keylogger auf dem PC auch das Kennwort nicht einfach mal mitlesen.
USB Smart Cards sind nicht teuer. Die Menge an Admins überschaubar.
Für RDP gibt es dann noch den Restricted Admin Mode mit entsprechenden Komforteinbußen.
In Enterprise Editionen noch Credential Guard, usw.
5. Exchange kann Split Permissions. Nutzt das. Es entfernt die Berechtigungen dass der Exchange Server Domain Admin Rechte hat. HAFNIUM war damit nur halb so schlimm.Für die BMC und Hypervisoren würde ich dringend zu physisch getrennter Verkabelung raten, statt zu irgendwelchen Software-Geschichten.
Server müssen auch nicht überall ins Internet dürfen. Verhindert dass Malware auf euren Servern ganz bequem per HTTPS ihren Payload laden können.Erweitert das noch mit VLANs und Firewalls. Kein Anwender muss auf die ESXi Infrastruktur, einen Switch oder das BMC vom Server. Die müssen auch auf die wenigsten Ports für die Anwendungsserver. Da reichen oft ACLs auf dem Core Switch um zumindest bei Line Speed zu bleiben.
Backupserver aus der AD nehmen. Per Firewall/ACL einschränken, dass der an die Server darf, aber die Server nicht zum Backupsserver.Das ist ein guter Ratschlag!
All diese Dinge die ich beschrieben habe gehen mit Bordmitteln. Da ist nicht ein Anti-Virus, SIEM oder sonst eine 3rd Party Lösung beteiligt.Nur ein Nachsatz noch von mir: Der Feind ist Komplexität. Es ist zwar schön, dass man bei Microsoft eine Menge konfigurieren kann, so dass es weniger schlimm ist, aber am Ende des Tages überblickt niemand mehr den ganzen Softwarehaufen, und alle sind nur an der Oberfläche am Herumkratzen. Das betrifft glücklicherweise auch die meisten Angreifer. Wirklich sicher fühlen würde ich mich da nicht. Und wenn man erstmal diese Art von Knowhow aufgebaut hat, dann wird man wahrscheinlich nie wieder von Windows wegmigrieren wollen.
Wir setzen das meiste davon bei Firmen ein die keine 10 Mitarbeiter haben. Das kann man mit Routine an einem Tag umsetzen. (Den Windows Teil zumindest) Testet das selbst mit Mimikatz, Bloodhound und was auch immer. Hackt euch selbst und danach oder wenn ihr das generell nicht könnt, holt euch noch einen Pen Tester um die offensichlichen Lücken weg zu machen.Am Rande: Domain Joined Device Public Key Authentication muss man nicht einschalten. Das ist per Default an. Man muss es aber erzwingen wenn man das Fallback nicht haben will. Ist fast das gleiche, aber doch nicht ganz und geht erst mit Server 2016.
Am weiteren Rande: Patchmanagement. Es wäre schön, wenn MS nicht Patches raus bringen würden die großflächig zu Boot Loops auf Domain Controllern, Druckproblemen oder 802.1X/802.11X Problemen führen würden. Dann hätte man auch mit Auto-Updates weniger schmerzen. So muss man eigentlich schon zwangsweise ein paar Tage warten, wenn man nicht vor einem Totalausfall am nächsten Tag stehen möchte. Beides verfahren sind somit schlecht.
Ich gehe nicht davon aus das danach das System unhackbar sicher ist. Wir sprechen hier immer noch von Software und von Microsoft, aber zumindest hat man etwas in die richtige Richtung getan und die offenlichtlichen Scheunentore geschlossen.
Wer nun mit dem erhöhten Supportaufwand argumentiert, dem sei gesagt dass er bei uns gesunken ist, weil die Anwender eben nicht mehr alles ausführen können was bei 3 nicht auf den Bäumen ist und die Computer dadurch so bleiben wie der Admin es sich mal vorgestellt hat.
Entwicklungsabteilungen können zusätzlich Nicht-Domain Computer oder VMs bekommen um ihre systemnahe Arbeit durchzuführen.
Aus meiner Sicht ist der Vorteil von Linux und co, dass es da keine natürliche Schranke gibt, wie viel Verständnis man von dem Gesamtsystem aufbauen kann.
Update: Einer der Gründe, wieso ich solche Tipps ungerne gebe, ist weil das alles furchtbar komplex ist, und es da immer wieder Untiefen gibt, die man halt nicht kennt, wenn man nicht nach ihnen sucht. SRP und UAC sind da exzellende Beispiele für. Seufz. Siehe auch hier und hier.
Für die allermeisten Anwendungen wird das aber reichen. Die Leute haben sich ja auch mit der Management Engine und UEFI abgefunden.
Ich persönlich applaudiere. Es hat nur wenige Jahrzehnte gedauert, und Linus musste ihnen öffentlich den Stinkefinger zeigen!
Der einmal rumlaufen und überall zlib updaten-Tag!
Fix a deflate bug when using the Z_FIXED strategy that can result in out-of-bound accesses.Schreibzugriffe. Und das geht auch ohne Z_FIXED.Das betrifft die Kompression mit zlib, nicht die Dekompression. Trotzdem gilt wie immer: Alles updaten. Sofort. Auch wenn ihr glaubt, ihr seid nicht betroffen.
Update: Wenn ihr Software herstellt, dann geht mal bitte in Ruhe durch alles sorgfältig durch. zlib wird gerne mal von wohnmeinenden Pfuschern statisch reinkompiliert. Bei Firefox, der Qualitätssoftware aus dem Hause Mozilla, sind beispielsweise direkt zwei Kopien von deflate.c im Repository. Bei gcc ist auch ein deflate.c dabei. Im Linux-Kernel ist auch ein deflate.c im Tree. Seufz. Das wird ein Blutbad, das alles zu updaten.
Update: zlib ist in Browsern, in allen Programmen, die mit PNG umgehen, in allen Programmen, die mit ZIP-Dateien umgehen, auch versteckt wie Office oder Java, ... zlib ist eine der am häufigsten verwendeten Bibliotheken. Kernelmodule werden gerne mit zlib komprimiert, Man Pages, das ist auch sonst in irgendwelchen Dateiformaten implizit drin. Einmal alle Skriptsprachen. Das ist echt Worst Case in Sachen Abhängigkeitshölle, wenn in zlib was kaputt ist.
Der Bug selbst ist nicht so bemerkenswert. Da haben die Leute halt jahrelang Code refaktoriert und dabei ist was kaputt gegangen. Hatte Security-Auswirkungen. Ist jetzt gefixt.
Aber dieser Write-Up von dem Finder ist wirklich exzellent und ich würde mir viel mehr solche Post-Mortem-Dinger wünschen.
Das ist eine weitere dieser völlig überflüssigen ranzigen Schrottkomponenten aus dem Gnome/Freedesktop-Umfeld. Wenn ihr Linux verwendet, und euch eure Distro nicht wie ich selber gebaut habt, dann ist die Antwort wahrscheinlich: ja.
Der Bug betrifft euch auch, wenn ihr das nur installiert habt, aber der Daemon nicht läuft.
Von Trend Micro gar, die hier schon mehrfach zu Gast waren mit ihrer unterhaltsamen Produkt"qualität"?
Money Quote aus dem Advisory:
The Trend Micro Deep Security Agent does not perform proper input sanitization, which allows a local unprivileged attacker to inject and run code as `root` user.Nein nein, Fefe, Schlangenöl erhöht gar nicht die Angriffsoberfläche, wie du seit Jahren gebetsmühlenartig ausführst!!1!
Der Standard-Linker unter Linux ist GNU ld von den binutils. Das ist ein uraltes Fossil von einer Codebasis, weil die eben nicht das konkrete Problem gelöst haben, sondern ein allgemeineres Problem lösen. Der Linker ist parametrisierbar und kann zur Compilezeit mitgeteilt kriegen, ob man ELF, COFF oder gar Windows EXE Files damit linken will. Kann glaube ich auch MACH-O von Apple, bin mir aber nicht sicher gerade.
Jedenfalls ist das Teil schnarchlangsam. Spielt in den meisten Fällen keine Rolle. Ich hab damit jahrzehntelang prima arbeiten können, ohne dass mir jemals aufgefallen wäre, wie langsam das Teil ist. Meine Programme sind aber auch alle relativ überschaubar.
Wenn man mal, sagen wir, Firefox linkt, dann ist die Link-Pause merkbar. Spielt im Vergleich zur Compilezeit keine Rolle, aber ist nicht gar nicht da.
Also haben sich über die Jahre Projekte gegründet, um mal einen schnelleren Linker zu bauen. Der erste, den ich gesehen habe, ist GNU gold, der ist auch Teil von den binutils. Ist in C++ geschrieben und direkt ... doppelt so groß wie ld. War zwar ein bisschen schneller aber linkte bei mir mal Firefox nicht und konnte auch kein link-time optimization und war daher direkt draußen.
Das nächste Projekt, das antrat, war LLVM lld. Der hat erstmals ein bisschen Multithreading am Start, aber nur für einige Teile. mold will jetzt alle Teile auf alle Cores verteilen.
Ich habe mal testweise das Erstellen von libavcodec.so gemessen:
GNU ld: 1.21s user 0.26s system 99% cpu 1.463 totalDas war jeweils noch mit Debug-Symbolen. Gut, unterhalb einer Sekunde ist das jetzt alles nicht sonderlich aussagekräftig, und die %CPU-Spalte bei mold ist offenbar damit überfordert, wie flott das Ding fertig war :-)
GNU gold: 0.83s user 0.10s system 99% cpu 0.928 total
LLVM lld: 0.69s user 0.17s system 258% cpu 0.333 total
mold: 0.03s user 0.00s system 13% cpu 0.247 total
Aber ich finde das ein interessantes Ergebnis und wollte direkt mal dietlibc damit linken, um zu gucken, ob das geht. Ging nicht, weil ich eine obskure Spezialoption von GNU ld benutze, -z noseparate-code. ld hat vor ein paar Jahren angefangen, nach SPECTRE bei den Segmenten Padding auf Page-Größe zu machen. Hintergrund ist, dass die Hardware Speicherschutz mit Page-Granularität macht. Wenn also in einem Binary Code und Datensegment nebeneinander im Binary liegen, dann war früher auf der letzten Page des Datensegmentes (das read-write gemappt ist!) auch die ersten Bytes des Codesegments, und man hätte da also reinschreiben können in einem Exploit oder so. Jetzt bläst der Linker das mit Null-Bytes auf. Ist an sich eine gute Idee, aber bei dietlibc will ich halt winzige Binaries haben. Da ist das Binary für rm sowas wie 9k groß. Wenn der Linker da Padding einfügt, dann ist das mal eben 50% größer. Daher möchte ich das bei der dietlibc gerne selektiv ausschalten können, und obiges wäre die Option dafür gewesen.
Die konnte mold nicht. Also hab ich vor zwei Tagen einen Bug aufgemacht. Heute war die Mail in der Inbox, dass er das eingebaut hat.
Ich muss sagen: Hut ab. So stellt man sich das in seinen Fieberträumen vor, dass Software-Entwicklung so abläuft. Erstens natürlich dass der Typ überhaupt reagiert, dann dass er mir nicht erklärt, meine Anforderung sei Scheiße, dann dass er das implementiert, und dann dass er das quasi über Nacht implementiert. Sehr beeindruckend.
Ich wünsche euch allen, dass ihr eure Codebasen auch so in Schuss habt, dass ihr auf so eine Anforderung mal eben so flott reagieren könntet. :-)
mold hat bei mir jetzt auf jeden Fall mehrere Schritte auf der Treppe genommen.
Update: Äh, jetzt habe ich den Link vergessen. Ist auf Github. Hat m.W. keine separate Homepage.
Lass mich raten… weil OpenSSL so einen schlechten Ruf hat?
Tavis Ormandy hat mal geguckt, wie die ihre Signaturen ablegen. Sie haben da eine Union, in der das größte Element 16 kbit groß ist, für RSA.
Okay, but what happens if you just….make a signature that’s bigger than that?Well, it turns out the answer is memory corruption. Yes, really.
Oh. Mein. Gott.Das ist schlimmer als Heartbleed. Das ist sozusagen der Hallo Welt unter den Remote Code Execution.
Sagt mal seid ihr auch so froh, dass Mozilla ihr Geld für so Dinge wie Colorways ausgegeben hat?
Oder dafür, dass ihr endlich Werbung im New Tab kriegt?
Oder für das ungefragte Einsammeln von Telemetrie?
At Mozilla, we want to make products that keep the Internet open and secure for all. We collect terabytes of data a day from millions of users to guide our decision-making processes. We could use your help.Nein, Mozilla. Wenn ihr meine Hilfe wollt, dann löscht ihr erstmal alle Daten über eure User.Aber zurück zu diesem Bug. Tavis Ormandy ist besonders geflasht, dass Mozilla da endlos static analyzer und fuzzing gemacht hat, und die Tools haben alle grüne Lampen angezeigt. Und nicht nur doofe Fuzzer sondern aktuelle state-of-the-art Fuzzer mit Coverage-Analyse!
Mich überrascht das ja nicht so doll. Ich werde praktisch nach jedem Code Audit gefragt, wieso ihre Static Analyzer das alles nicht gefunden haben. Ihr solltet vielleicht mal weniger Geld für Tools ausgeben und mehr Geld in eure Entwickler stecken, dass die lernen, wie so ein Bug aussieht und worauf man achten sollte.
Fail Overflow sind die Leute, die Linux auf Switch, PS3 und PS4 installiert haben.
Das macht mir gerade enorm schlechte Laune, muss ich euch sagen. Das Internet bestand früher aus lauter interessanten Charakteren, Leute mit Visionen, wo es für die Gesellschaft hingehen sollte. Leute, die nicht nur über ihren eigenen Profit nachdachten.
Die sind alle weg. Gilmore war der letzte von ihnen.
Das waren nicht immer nette oder einfache Leute. Mir fallen da gerade Richard Stallman, Eric Raymond und Larry Wall ein.
Aber es gibt einen, über den ich noch nie von irgendjemandem ein böses Wort gehört habe, und das ist John Gilmore. Ich hab den ein paar Mal getroffen und war jedesmal beeindruckt. Stellt euch einen alten Hippie vor, der in verhältnismäßig jungen Jahren zu Wohlstand gekommen ist (er war Angestellter Nummer 5 bei Sun). Das soll jetzt hier nicht wie ein Nachruf klingen, der lebt ja noch, aber um euch mal ein Gefühl dafür zu geben, was wir dem Mann so alles zu verdanken haben:
Gilmore hat die EFF gegründet. Er ist Autor von GNU tar. Ohne seine Mithilfe hätten wir womöglich kein BSD Unix gehabt, denn er war Teil des Teams, die den freien BSD-Teil aus dem proprietären AT&T-Scheiß gepolkt haben. Er machte Emacs portabel. Er machte wichtige Teil von GNU make und GDB.
Als klar war, dass freiwillige Mitarbeit nicht reichen würde, um binutils, gcc und gdb fit zu kriegen, gründete er Cygnus Solutions, die sich jahrelang darum kümmerten.
Als klar war, dass die US-Exportrestriktionen für Kryptografie ein Problem sind, finanzierte er das djb-Verfahren gegen die US-Regierung, das am Ende zum Einsturz der Krypto-Exportrestriktionen führte.
Als Linux einen IPsec-Stack brauchte, gründete und finanzierte er FreeS/WAN.
Ohne Gilmore gäbe es auch GNU Radio nicht, oder das One Laptop per Child-Projekt.
Kurz gesagt: Gilmore ist der Typ, der sieht, dass irgendwo was nicht flutscht, und dann aushilft. Ohne dass sein Name groß dransteht.
Mir fällt spontan niemand ein, dem das Internet mehr verdankt als ihm.
Wenn es nach mir ginge, wäre der Rest von dem Board rausgeflogen, nicht Gilmore. So ist die EFF jetzt nur noch eine weitere gesichtslose durchoptimierte Organisation, die belanglose Pressemitteilungen produziert. Sehr schade.
Update: DHCP basiert auf BOOTP, das kommt auch von Gilmore.
F
Jörg war jemand, der Solaris für Linux überlegen hielt, der darum selbst eine Opensolaris-Distribution bastelte. Einer, der GNU tar sah und dann lieber sein eigenes tar-Programm schrieb. Einer, der einen CD-Brenner hatte und darauf nicht brennen konnte unter Unix, also schrieb er sein eigenes Brennprogramm.
Ein Titan unter den Dickschädeln dieser Welt.
Ohne Dickschädel gibt es keinen Fortschritt.
Wir brauchen mehr Dickschädel.
Diese Acer-Geräte haben ein Touchpad, das standardmäßig im "Advanced Mode" läuft, das ist dann ein Protokoll, das HID (von USB) über I2C spricht. Hat sich Microsoft irgendwann aus dem Arsch gezogen. Dieser HID-über-I2C-Scheiß hat zwar einen Treiber unter Linux, aber irgendwas muss ich da falsch gemacht haben, jedenfalls erkannte der das Gerät nicht.
Früher konnte man im BIOS einfach das Touchpad von Advanced auf Basic schalten, was das auf ein PS2-Gerät mit Synaptics-Protokoll umstellte, was unter Windows und Linux auf Anhieb funktioniert.
In den aktuellen BIOSsen gibt es diesen Schalter nicht mehr. Das Handbuch erwähnt auch keinen Weg, wie man das umschalten kann.
Und dann ... fand ich einen Cheat Code fürs BIOS. Den raunt man sich in Acer-Foren zu.
Du musst im BIOS ins Main Tab gehen und Ctrl-S drücken. Dann erscheint ein Knopf für das Touchpad und ein Knopf für das AHCI-Umschalten.
Alter Schwede, dass wir mal 1990er-Gaming-Style Cheat Codes im BIOS haben würden, das hätte ich bis gestern nicht geglaubt.
Update: Leserbrief dazu:
bzgl. Cheatcodes fürs BIOS, das hat MSI mittlerweile auch "verbrochen". Da ist es sogar noch etwas abenteuerlicher, muß man doch die rechte SHIFT- und CTRL-, sowie die linke ALT-Taste gedrückt halten und dann noch zusätzlich F2 drücken und schon kommt man in das "advanced" BIOS rein. Da sind dann allerdings auch Sachen drin, mit denen man sich sein Notebook definitiv bricken kann. Ich hatte da mal versehentlich das interne Display abgeschaltet (klares Eigenverschulden, weil nicht richtig aufgepaßt). Das BIOS danach zurückzusetzen ist nicht so einfach bei fest verbauten Akkus und keinem BIOS-Reset Knopf.
Update: Noch ein Leserbrief:
Diese "Cheat Codes fürs BIOS" sind garnicht so jung, wie es sich in deinem Beitrag anhört. HP hat in Ihre BIOS und frühen EFI Implementationen (die Jahrgänge die noch wie das vorherige BIOS ausgesehen haben) ebenfalls solche Codes verstecken lassen. Wenn man CTRL-A auf dem Main Tab drückte, konnte man zusätzliche Eingabefelder im "System-IDs" Fenster anzeigen damit der Reparatur-Service nach einem SysBoard-Replacement die Seriennummer und Service Tags und so Scheiße wieder einstellen konnte.
Ich hab das mal experimentell als AVIF statt JPEG hochgeladen, das jetzt angeblich alle Browser können. Bin mal gespannt, ob das Format realitätsfest ist.
Update: Hups, da hat mich meine Toolchain verarscht. Die kann gar kein AVIF und hat da ein JPEG abgelegt. m(
Update: OK jetzt liegt da tatsächlich ein AVIF und es kommt auch mit MIME-Type image/avif raus. Bei mir zeigen Firefox und Chrome das unter Linux richtig an. Leser berichten, dass der Android-Firefox das noch nicht kann, aber Android-Chrome kann es. Unter Windows können es wohl auch alle namhaften Browser. Safari kann anscheinend gar kein AVIF, egal wie aktuell man ist.
Update: Stellt sich raus: Firefox 92 hat das wegen eines Bugs wieder rausgenommen. Bei mir ging Firefox, weil ich unter Windows den beta Channel angeschaltet habe, das ist dann 93, und unter Linux den Nightly selber baue.
Sieht aus als ob Microsoft da den Linux-VMs ungefragt einen "Agenten" untergejubelt hat, der dann in der VM Dinge tut. Dieser Agent ist von außen erreichbar.
Wenn du den Authentication-Header weglässt, bist du root.
Nein, wirklich. Lest das nochmal.
Wartet, wird noch krasser. Gemeldet wurde das Problem am ersten Juni. JETZT unterrichtet Microsoft ihre Kunden. Am 12. August gab es einen Drive-By-Commit namens "Enhanced Security" im Repo.
Wow! Such professional! Many cloud expert! Da willste doch deine kritischen Unternehmensdienste hosten, bei solchen Leuten!!1!
Man kann auch eine Menge andere Dinge erkennen. Zum Beispiel: Wenn die Partei dich zur Briefwahl nötigen will, ist genau wie wenn dich eine Computerspielefirma zum "Pre-Purchase" nötigen will. Die wollen gerne, dass du jetzt, wo es außer heißer Luft und billigen Versprechen nichts gibt, die Entscheidung triffst, damit du nicht mehr abspringen kannst, wenn sich vor der Wahl noch rausstellt, dass das alles Lügen waren und die Partei dich nach Strich und Faden verarscht hat.
Soweit ich weiß, ist die per Briefwahl abgegebene Stimme auch tatsächlich bindend und nicht korrigierbar. Korrigiert mich, wenn ich da falsch liege. Aber selbst wenn das nicht so wäre: Wer sich einmal festlegt, ändert seine Position nur sehr unwahrscheinlich. Ein abgegebener Wahlzettel fühlt sich an wie ein Versprechen. Versprechen brechen ist sozial geächtet. Niemand will unzuverlässig sein.
Lasst euch also bitte nicht zur Briefwahl nötigen. Es gibt gute Gründe für eine Briefwahl. Aber "weil die CDU mich drängte" ist keiner davon.
Aber eigentlich ging es ja um Digitalisierung. Der offensichtliche Prüfstein ist: Setzen die Cookies und lügen dir im Terrorbanner noch ins Gesicht, sie täten das für dich und um deine "Erfahrung zu optimieren"? Binden die externe Ressourcen ein? Am besten noch ausländische?
Gucken wir doch mal.
Oh und: Sie setzen einen Cookie. Ohne um Erlaubnis gefragt zu haben.
Inhaltlich ist das natürlich auch grotesk. Die schreiben da ernsthaft:
„Respekt – das ist meine Idee für unsere Gesellschaft. Dafür kämpfe ich mit Leib und Seele, mit Herz und Verstand.“Von dem Olaf Scholz, der Folter für mutmaßliche Kleindrogendealer eingeführt hat. Der lügt uns jetzt was von Respekt ins Gesicht. Unglaublich.
Oh und darunter? "JETZT BRIEFWAHL BEANTRAGEN". Danke. Keine weiteren Fragen.
Die CDU bindet Ressourcen von zwei COM-Domains ein. Einmal von Cloudflare, das ist bei mir in nächster Nähe in Berlin gehostet, und einmal von einem dänischen Anbieter, der bei Amazon US-WEST hostet. Ja, richtig gelesen! Die haben einen externen Anbieter für ihr Cookieterrorbanner, setzen direkt 4 Cookies, bevor man da zustimmen konnte, und dann liegt das Cookieterrorbanner auch noch in den USA. Schlimmer verkacken kann man das gar nicht an der Stelle.
Aber was ist ihr erster inhaltlicher Punkt nach dem Aufmacher-GIF? "JETZT BRIEFWAHL BEANTRAGEN!". Danke. Keine weiteren Fragen.
Was ich bei den Grünen noch auffällig finde:
Hilf uns, den erfolgreichsten Bundestagswahlkampf aller Zeiten vorzubereiten! Wir wollen möglichst viele Erstwählerinnen in der ganzen Republik auf die Wahl aufmerksam machen.Wir sind hier nur an Frauen interessiert. Männer können ruhig CDU wählen gehen.
Wie so häufig stellt sich raus, dass die Linkspartei als einzige nicht Totalversager sind.
Ich versteh echt nicht, wieso die bei den Umfragen nur bei 7% liegen gerade. Ich meine, die Leute sind von Baerbock und Laschet so abgetörnt, dass sie den Scholz in Erwägung ziehen! Aber nicht die Linken!?
Ich frag das ja gelegentlich Leute, wieso die Linken eigentlich nicht mehr Stimmen kriegen. Da kommt dann häufig: Aber die ganzen SED-Kader!1!!
Das ist ein Mem aus den 90er Jahren. Das stimmte damals nicht und stimmt heute erst recht nicht. Wenn euch alte Stasi-Kader sorgen, müsst ihr mehr Angst vor der CDU haben als vor den Linken!
Dann kommt noch häufig: Aber die Klimakatastrophe! Da muss man doch die Grünen wählen! Ach? Ist das so?
Die Linkspartei hat sicher auch ihre Probleme, gar keine Frage. Aber was da so gegen sie vorgebracht wird, das sind keine davon.
Wie verstrahlt die Situation ist, kann man auch gut daran sehen, dass die Leute der SPD, die ihnen Hartz IV gebracht hat, sie zu ewiger Armut und staatlicher Gängelei verurteilt hat, und aus Kohlekumpelstimmfanggründen lieber Kohlekraftwerke betreibt als was gegen die Klimakatastrophe zu tun, dass man DENEN mehr Sozialkompetenz zutraut als den Linken.
Lest euch mal deren Programm durch. Guckt euch mal deren Gesetzesvorschläge an! Wat!?
Der Fairness halber hier noch eine Gegenposition: Mein Kumpel Erdgeist ist frisch nachgeschulter Wahlhelfer, und der findet, dass es dieses Mal mit Covid und den hochkomplexen Wahlzetteln in der Tat kein gültiger Kritikpunkt ist, wenn Parteien ihre Wähler zum Briefwählen nötigen wollen. Er sagt auch, dass man sich nach der Briefwahl nochmal umentscheiden kann. Man muss dann zum Wahlamt laufen und denen die Situation erklären und die invalidieren dann den Wahlzettel und geben dir einen neuen. Würde mich wundern, wenn das irgendjemand wahrnimmt, ehrlich gesagt, denn Briefwahl machste ja gerade, um dir den einen Behördengang zum Wahllokal zu sparen. Wenn du zum Umentscheiden zum Wahlamt musst, dann machste ja unterm Strich sogar Verlust im Vergleich zur Präsenzwahl.
Update: Mir schriebt jemand, dass es die Wahlkampfkostenerstatung ab 1% gibt. Das wusste ich nicht, ich dachte die gibt es ab 5%.
Update: Der Vergleich betraf nur die Homepages. Wenn man da Links folgt, sieht das möglicherweise anders aus und da kommen dann auch bei den Linken Youtube-Videos mit Zustimmungsterrorbanner. Seufz.
Klar können sie das. Das konnten sie seit der Sekunde, in der ihr Geräte gekauft habt, die nicht euch gehören sondern Apple. Wenn ihr die Souveränität über eure Hard- und Software aufgebt, dann seid ihr solchen Übergriffen schutzlos ausgeliefert.
Das war von Minute 1 an klar. Es war schon vorher klar. Leute haben davor gewarnt. Ihr habt trotzdem lieber Apple-Geräte gekauft. Eigenbau-Linux-Projekte, die diese Probleme nicht gehabt hätten, habt ihr verhungern und austrocknen lassen.
Guckt mich jetzt nicht so an als müsste ich euch jetzt vor den Konsequenzen eurer Handlungen schützen. Jetzt steht ihr mal bitte schön ganz alleine auf der Straße und schimpft über Apple. Ich habe euch das gleich gesagt. Convenience war euch wichtiger. Jetzt habt ihr den Salat. Hört also bitte mit dem Herumgememme auf und fresst die Suppe, die ihr euch eingebrockt habt.
Was dachtet IHR denn? Dass Apple anständig ist und sowas nicht bringen würde?! Nachdem sie sich in China den Regierungsauflagen gebeugt haben? So blöde kann doch niemand sein!
Nein. Wir sind jetzt da, wo der Weg die ganze Zeit hinführte. Ihr habt eure Souveränität aufgegeben. Ihr benutzt Prozessoren mit Management Engines, die verhindert, dass ihr auf eurer Hardware den Kopierschutz von Netflix-Videos brecht. Ihr verwendet Computer mit "Sicherheitschips", die verhindern, dass ihr auf eurem Computer booten könnt, was ihr wollt. Ihr benutzt Software, die eure Daten nicht nur nicht schützt sondern in die Cloud hochlädt. Eure Daten sind längst in irgendwelchen Clouds in irgendwelchen Ländern. Die sind schon so oft weggekommen, dass die Preise für persönliche Daten aus Cloud-Hacks inzwischen in Hunderttausenden von Datensätzen angegeben werden.
Ihr gebt irgendwelchen Webseiten euer Geburtsdatum!! What the FUCK?
Apple war bloß der letzte umfallende Dominostein. Eure Souveränität ist schon länger futsch. Ihr konntet euch nur bisher selbst belügen, dass es schon nicht so schlimm werden würde.
by creating, mounting, and deleting a deep directory structure whose total path length exceeds 1GB, an unprivileged local attacker can write the 10-byte string "//deleted" to an offset of exactly -2GB-10B below the beginning of a vmalloc()ated kernel buffer.Ach komm, Atze, niemand wird jemals so einen Pfad erzeugen!!1!Stimmt! Außer den bösen Angreifern, die deine Kiste hacken wollen. Die würden das machen.
write() und writev() haben ein Limit von 2GB, wieviel sie auf einmal schreiben.
Wir haben hier 64-bit-Systeme. Man kann viel größere Dateien in den Speicher mappen. Wenn ich eine Datei kopieren will, dann mappe ich die Quelldatei in den Speicher und erwarte, mit einem write(zieldatei, memorymapping, quelldateigroesse) alle Daten in die Zieldatei schreiben zu können.
Das funktioniert auch, außer die Zieldatei ist 2 GB oder größer.
Warum ist das so? Weil die Codequalität der Treiber unter aller Sau ist. Linus hatte nach ein paar Monaten keinen Bock mehr, denen hinterherzuwischen, und hat dann einfach gesagt: Mehr als 2GB auf einmal darf man dann halt nicht schreiben.
Habe ich auf menschlicher Ebene Verständnis für, aber es entspricht nicht meinem Verständnis von Softwarequalität und an Anspruch an sich selbst als Softwareingenieur. Das ist wie wenn die Bundesregierung anstatt marode Autobahnen zu reparieren einfach Geschwindigkeitsbegrenzungsschilder aufstellt.
Oh, warte ...
Das Problem ist nicht Linux-spezifisch. Unter Windows ist es noch lustiger, da hat das WriteFile-API als Typ für die Anzahl der zu schreibenden Bytes bloß ein DWORD, das ist auch auf 64-bit Systemen 32-bit breit. Völlig absurd.
Die ganze Problematik blubbert hier gerade hoch, weil ich unter FreeBSD gegen ein Limit in writev gelaufen bin. Stellt sich raus: writev unter FreeBSD macht erstmal im Kernel eine Kopie aller zu schreibenden Daten, nicht nur des Vektors, auch der darin verlinkten Daten. Und weil das halt scheiße ineffizient ist, haben sie da ein Limit drin.
Ich muss bei sowas immer an Bill Gates und seine 640 KB denken.
Was für Arschkrampen ey. Klar hab ich euer Trinkwasser vergiftet, aber das war für die Forschung!!1!
BleedingTooth is a set of zero-click vulnerabilities in the Linux Bluetooth subsystem that can allow an unauthenticated remote attacker in short distance to execute arbitrary code with kernel privileges on vulnerable devices.Der (für mich) verstörenste Teil daran ist:I discovered the first vulnerability (introduced in Linux kernel 4.19) by manually reviewing the HCI event packet parsers.Erstens: 4.19 ist nicht sooo alt. Da waren die Prozesse, die diese Art von Problem verhindern sollen, eigentlich schon aktiv. Insbesondere sollten die Prozesse "manually reviewing [...] parsers" eigentlich beinhalten.Das ist also offensichtlich noch einiges im Argen bei Linux.
Google will angeblich gerade den Bluetooth-Support in Android neu schreiben, den Userspace-Teil in Rust.
Oracle hat ja Sun gekauft, und damit die Rechte an Java.
Google hat Android gekauft, das war ein kleines Startup, und die haben voll auf Java gesetzt, aber um Oracles Trademarks nicht zu verletzen und keine Lizenzgebühren zahlen zu müssen, haben sie nicht das Sun/Oracle-Java genommen sondern einmal die APIs nachprogrammiert.
Oracle hat dann vor Gericht gemeint, sie besäßen aber "geistiges Eigentum"-Rechte an den APIs und dafür müsse Google Lizenzgebühren zahlen.
Der Supreme Court hat jetzt Google recht gegeben.
Alles andere wäre auch echt furchtbar geworden. Dann könnte auch SCO Linux verklagen, oder Microsoft könnte WINE plätten. Emulatoren wären tot.
Insofern war das auf jeden Fall die richtige Entscheidung.
Allerdings hat das Gericht da (wie üblich) versucht, einer Grundsatzentscheidung aus dem Wege zu gehen, damit sie nicht nochmal einen Klopper wie Citizen United fabrizieren.
Und so haben sie nicht generell entschieden, dass APIs nicht unter Copyright fallen, was meines Erachtens die richtige Ansage gewesen wäre, sondern sie haben bloß entschieden, dass Google hier Fair Use gemacht hat, d.h. eine Ausnahme vom Copyright greift. Damit ist natürlich zukünftigen Verfahren Tür und Tor geöffnet, ab wann ein API-Nachbau nicht mehr unter Fair Use fällt. (Danke, Andreas)
Die Firma hinter pfsense ("World's Most Trusted Open Source Firewall") hat einen Typen bezahlt, damit er Wireguard nach FreeBSD portiert, und zwar in den Kernel rein. Die wollten das in ihren Produkten unterstützten (Wireguard ist ein VPN-Protokoll, sowas wie IPsec).
Der Typ hat dann nach ein paar Monaten einen Port nicht nur abgeliefert, sondern bei FreeBSD einfach so in den Code einchecken können. Die Wireguard-Leute erfuhren aus der Presse auf einer FreeBSD-Mailingliste davon und dachten sich: Sollten wir vielleicht mal kurz einen Blick drauf werfen. Steht ja immerhin unser Name dran.
Was fanden die? Nun, äh, es war nicht gut. Es war so doll nicht gut, dass sie sich entschieden haben, da mal die Dinger zu fixen. Sie haben also zwei Wochen lang im Wesentlichen Crunch-Mode gefahren (auf Schlaf verzichtet) und am Ende war von dem ursprünglichen Port-Code nichts mehr übrig.
Und DAS, meine Damen und Herren, ist ein GANZ eindeutiges Zeichen. Wenn du zwei Wochen hast, und du machst lieber alles neu, dann war das ungefähr die Hölle auf Erden.
Es gibt eine Liste:
The first issue is whether Macy's code actually had significant problems. Donenfeld said that it did, and he identified a number of major issues:- Sleep to mitigate race conditions
- Validation functions which simply return true
- Catastrophic cryptographic vulnerabilities
- Pieces of the wg protocol left unimplemented
- Kernel panics
- Security bypasses
- Printf statements deep in crypto code
- "Spectacular" buffer overflows
- Mazes of Linux→FreeBSD ifdefs
Da muss ich doch mal kurz den Zyniker raushängen lassen und auf Linus zeigen. Der wird seit Jahren angefeindet, weil er Leute, die schlechten Code einreichen, abweist. Wer es einfach nochmal versucht, kriegt eine Beleidigung. Wer es nochmal probiert, wird abgewatscht.Wenn du das nicht machst, passiert sowas hier.
Update: FreeBSD hat ein Statement veröffentlicht. Da war ich ja mit meinem Linus-Vergleich geradezu prophetisch.
Update: Man kann auch die Perspektive haben, dass das kein Qualitätssicherungsproblem bei FreeBSD ist, denn die Qualitätssicherung selektiert nicht, was nach HEAD reinkommt, sondern was in die Release-Branches kommt.
Ich hatte da zwei Stories. Einmal eine zu einem Typen, der in seiner Garage eine Impfung gebaut und seinen Mitarbeitern verabreicht hat, ohne die dafür vorgeschriebenen Testreihen durchlaufen zu haben, und dafür eine Anzeige der zuständigen Behörde eingefahren hat, die genau dafür existiert, sowas zu verhindern. Sonst könnte ja jeder Krämer an der Straßenecke retrovirale Impfungen gegen Haarausfall verkloppen.
Ich habe zu dem extra zwei schöne Debunking-Links ins Blog getan, damit die Leute das lesen und sehen, wieso die Anzeige nicht nur berechtigt sondern gewollt war.
Es gibt da noch ein paar Details, die euch hätten auffallen können, als Teil der Übung. Erstens hättet ihr das mal googeln können und hättet dann dieses Statement von Petra Falb finden können, die bei der zuständigen Behörde Gutachterin für die Zulassung von Impfstoffen ist. Oder ihr hättet bemerken können, dass die Querdenker (die ja ansonsten eher impfkritisch sind) voll auf den stehen, vermutlich weil der Stöcker ein AfD-naher Klimakatastrophen-Leugner ist, der zum Sturz der Kanzlerin aufrief. Von DEM würden die evidenzbasierten Alternativmediziner einen germanischen Impfstoff nehmen, was ihre Fundamentalopposition zu anderen Impfstoffen gar lustig kontrakariert.
Aber egal. Eigentlich ging es mir ja nicht um die Rechten. Eigentlich ging es mir um die Linken. Diese Finnland-Meldung kam nämlich vom gegenüberliegenden Teil des Hufeisens (das gibt wieder böse Mails!1!!), von ein paar fundamentalmarxistischen Kapitalismusgegnern.
Meine eigentliche Hoffnung mit der Übung war, dass ihr die Argumente aus dem 1. Teil seht, und dann bei der Lektüre des 2. Teils merkt, dass die alle auch da passen. Dass, mit anderen Worten, Verschwörungstheorien unabhängig vom politischen Spektrum auf denselben Mustern aufbauen.
Oder, wenn ihr das nicht erkennt, hättet ihr wenigstens googeln können, dass der Oxford-Impfstoff schon im Januar 2020 fertig war, d.h. als dieser Impfstoff im Mai soweit war, war Oxford schon seit Monaten am Testen.
Stattdessen haben offenbar die meisten Leser den Eindruck gewonnen, dass ich hier den Stöcker feiern wollte. Nein. Wollte ich nicht. Im Gegenteil. Die Formulierungen haben das angedeutet, weil ich ja die Leute ansprechen wollte, die das glauben oder unentschlossen sind.
Tja. You win some, you lose some.
Übrigens gab es noch ein langen Leserbrief von jemandem, der eure Perspektive auf diese Impfstoffe möglicherweise radikal ändern wird:
In der Diskussion um den Stöcker (und jetzt auch noch diese Finnen!) kommt immer wieder von Experten (!) zum Ausdruck, dass man so ein komplexes Produkt ja gar nicht im Hobbykeller basteln kann. Das könnten nur Profis! Und schon gar nicht so ein Nazi-Opa in seiner Scheune (ja, für Ad-Hominem-Argumente ist der Stöcker sehr gut brauchbar).Tatsächlich ist das Herstellen von einem rekombinanten Protein oder customized Adenovirus so einfach wie das Drucken eines hübschen Foto-Albums: Man braucht da nur im Internet einen Service anschreiben. Das hat der Stöcker sicher auch gemacht, und GENAU DESHALB kann er nicht sagen, was für eine Zell-Linie exakt das war.
Protein (chinesische Firma, kann man also bei Bedarf auch komplett an unseren Autoritäten vorbei bestellen): sinobiological.com
Adenovirus (hier dann mal eine US-Firma als Ansprechpartner): vectorbiolabs.com
Das sind nur die zwei ersten Fundstellen bei Google. Die, die dort Werbung bezahlt haben, dass man sie findet. Niemand, der sowas entwickelt, braucht dafür ein eigenes Labor! Die 10^12 Viren, die man da bekommt, reichen bei der Dosierung von AstraZeneca für 100 Impfungen, also genug für einen Phase-2-Test; wie viel Stoff man bei den Proteinen man so bekommt, habe ich jetzt nicht geguckt, wahrscheinlich auch so in der Größenordnung 100 Impfungen. Wenn man das richtig macht (also z.B. statt deaktivierte Replikation eine etwas abgeschwächte Replikation) kommt man vermutlich mit 10^6 Vektor-Viren pro Impfung hin, und kann sogar aus dem Rotz der geimpften weiteren Impfstoff gewinnen (so hat man übrigens die Pocken-Impfung repliziert: Die Pocken-Blasen an der Impfstelle enthalten genügend Kuhpocken-Viren für mehrere Impfungen). Dann könnte man mit einer Bestellung tatsächlich ganz Finnland durchimpfen und mit dem so entstandenen Rotz aus der Impfreaktion die ganze Welt.
Für die Antikörper-Tests braucht man auch keinen Drosten. Corona-Antikörpertest mit Titer kann jedes einigermaßen ausgestattete Labor, man muss die Probanden nur zum Hausarzt schicken. Mehr haben die kommerziellen Anbieter bei ihren Phase-2-Tests auch nicht gemacht.
Ich habe jetzt nicht gefragt, wie teuer der Spaß wäre (das geben die nicht direkt an, sondern “request a quote”), aber gehe davon aus, dass es sich um Budgets handelt, die kein Show-Stopper für ein Uni-Forschungsinstitut wären, denn das sind ja die üblichen Kunden. Entsprechend muss man sich nicht wundern, wenn Meldungen von Enthusiasten die Runde machen, die sich auf eigene Faust einen Impfstoff gebastelt haben. Ja, ne, die haben nur die DNA dafür auf dem Rechner zusammengeclickt, und das von so einem Service bauen lassen, mehr Aufwand ist das gar nicht mehr. Die Zellen, die die Vektor-Viren produzieren, haben das Adenoviren-Replikationsgen drin, und können deshalb auch ansonsten nicht vermehrungsfähige Adenoviren clonen. Serotyp und Payload kann man also frei wählen. Und bei rekombinanten Proteinen muss man eigentlich nur noch den Zelltyp anwählen (möglichst nah am Menschen).
Der Aufwand sind die Phase-3-Tests und der Aufbau der Massenproduktion. Nur, auch das Einkaufen und Betreiben von so Bioreaktoren und Aufreinigern ist kein Voodoo, sondern ebenfalls ein ganz normales bestellbares Produkt.
Der Hauptgrund der Aufregung scheint mir zu sein, dass so Hobbyisten-Free-Pharma-Produkte eine Industrie erschüttern würden wie einst GNU und Linux das mit der Software gemacht haben.
Nur, wenn man sich die Entwicklungszeiten anguckt, ist es um mehrere Größenordnungen einfacher, so einen Impfstoff zu *entwickeln* als irgendwelche freie Software. Irgendwo zwischen echo und cat oder so.
Und lasst euch nicht von „Unethisch!“ ablenken. Die Pharma-Industrie war bereit, 30 Millionen Afrikaner sterben zu lassen, nur um die Profite für die AIDS-Medikamente hoch zu halten. Denn nachdem der Patentschutz dort endlich aufgehoben wurde, waren die Medikamente als Generica für fast 2 Größenordnungen billiger zu haben, und DANN wollten auch die Krankenkassen von reichen westlichen Staaten plötzlich diese Wucherpreise nicht mehr bezahlen.
Es gibt im ganzen 20. Jahrhundert nur ganz wenige menschengemachte Katastrophen, die ähnlich viele Opfer gefordert haben wie die Pharma-Patente nur auf die drei AIDS-Medikamente. Russlandfeldzug. Großer Sprung nach Vorn. So, die Größenordnung.
Und die Verzögerung der Corona-Impfung durch die explizit als Marktzugangshemmnis aufgerichteten Impf-Regularien (die übrigens in pandemischen Situationen in vielen Ländern gekippt werden könnten, aber außer Russland und China hat das keiner gemacht) haben auch schon 2 Millionen Menschenleben gefordert.
Impfstoff-Entwicklung ist vor allem deshalb in der Regel schwierig, weil die verbliebenen Pathogene von Interesse böse Tricks auf Lager haben, die einen daran hindern, einfache etablierte Techniken zu nutzen, oder weil die Fälle so selten sind, dass man Jahrzehnte warten muss, bis die Kontrollgruppe endlich ihre 100+ Fälle durch hat. Das alles ist bei Covid-19 nicht der Fall: Die Impfstoffentwicklung ist trivial, das Virus hat keine bösen Tricks auf Lager, und die Kontrollgruppe durchseucht sich ziemlich schnell.
Update: Hier ist ein Blogeintrag von einem Ami, der das mal gemacht hat. Mit diesem interessanten Absatz:
(Side note: in many ways immunity in the mucus lining is better than in the blood, since it blocks infection at the point where it’s introduced. This is an advantage of inhaled vaccines over injected. So why do most commercial vaccines inject? Turns out logistics are a major constraint on commercial vaccine design, and injections are surprisingly easier logistically.
Also doch nicht "weil wir ein Patent auf Spritzkram hatten" :-)
Ein bisschen später gab es dann noch ein Blogpost, wie er das jetzt testen will aber noch ohne Resultate. Die stehen noch aus.
So von Kapitalismus und Big Pharma?
Story 1: Lübecker Tüftler baut Covid-Impfstoff, Wirkung unabhängig bestätigt, und er will das Zeug verschenken.
In dem Glas mit dem Erdbeerdeckel befindet sich eine Ampulle mit einem blauen Verschluss. »Da ist das Antigen drin«, sagt Stöcker. »Damit könnte man innerhalb eines halben Jahres drei Viertel der Bevölkerung Deutschlands gegen Corona immunisieren.«Was passiert? Strafanzeige gegen ihn.
Original kam die Story hinter Paywall beim ehemaligen Nachrichtenmagazin, daher hier keinen Link von mir. Dieser Link hier geht zur Gegenstory beim SWR, die argumentieren, dass die Strafanzeige gerechtfertigt war. Hier ist der BR dazu, die ähnlich argumentieren wie der SWR.
Story 2: Finnische Forscher hatten angeblich schon im Mai 2020 einen wirksamen Impfstoff, den man sogar per Nasenspray verabreichen konnte. Die Sache wurde aber nie in Richtung Zulassung vorangetrieben, weil man damit kein Geld hätte verdienen können.
Saksela und sein Team hatten bereits im Mai 2020 einen patentfreien Covid-19-Impfstoff entwickelt, den sie in Anspielung auf das berühmte finnische Open-Source-Betriebssystem als »das Linux unter den Impfstoffen« bezeichneten. [...]Das bemerkenswerte an diesem Artikel ist aber nicht dieser Teil der Story, sondern das hier (finde ich zumindest):»Es ist ein fertiges Produkt, in dem Sinne, dass sich die Rezeptur bei weiteren Tests nicht mehr verändern wird«, sagt Saksela. »Mit dem, was wir haben, könnten wir morgen die gesamte Bevölkerung Finnlands impfen.«
»Die Hintergrundrecherche war an einem Nachmittag getan, und die gab dann allen die Richtung vor«, sagt Saksela. »Auf Grundlage der bisherigen Forschung zu SARS-1 und MERS, lag eigentlich alles auf der Hand – das war kein großer Triumph der Wissenschaft.« Anstatt einen inaktivierten oder geschwächten Keim in den menschlichen Körper einzuschleusen, trainieren die neuen Coronavirus-Impfungen unser Immunsystem, auf ein – an sich harmloses – »Spike-Protein« zu reagieren, das die charakteristischen Ausstülpungen auf der Virusoberfläche bildet.Ja wie, warte mal, war das nicht gerade die große Innovation bei Biontech und Moderna? Das war gar nicht neu?!
Das Wissen über diesen Mechanismus ist älter als alle Beiträge von Pharmaunternehmen.Nein, war es nicht. Ja, äh, aber was war denn dann der neue Beitrag von denen?
»Verschiedene Biotech-Unternehmen packten das Spike-Protein auf irgendeine Art von Übertragungsmechanismus, sei es RNA-Technologie oder etwas anderes«, erklärt Saksela. »Dabei basiert die Wahl in der Regel darauf, auf welche Anwendungen die jeweiligen Unternehmen ein Patent haben – ob das nun die beste Option ist oder nicht.«Die eigentliche Innovation der Pharma-Unternehmen ist die Profitmaximierung.
Mit diesen künstlich (und in meinen Augen unredlich) herbeigeführten Profiten finanzieren die dann die langjährigen Zulassungsvoraussetzungen für die nächste Runde an Patent-Pharma. Das ist ein selbsterhaltendes Monopolerzeugungssystem.
Nuvia? Nie gehört? Das könnte daran liegen, dass die noch keine Produkte auf dem Markt gebracht haben. Nuvia ist eines der Startups, die bisher eher durch ein großes Maul aufgefallen sind: Die tollsten ARM-Server-Prozessoren, besser als Intel und AMD!
Da gab es schon mehrere von, bisher alle ein Reinfall. Wieso gibt Qualcomm jetzt also so viel Geld für Nuvia aus? Deshalb:
Gründer und CEO Gerard Williams III war bis Anfang 2020 fast 10 Jahre bei Apple, zuletzt als CPU-ChefarchitekturDie einzigen, die bisher einen wirklich ernstzunehmenden ARM ins Feld geschickt haben, der es von der Leistung her mit Intel und AMD aufnehmen kann, war Apple. Qualcomm kauft hier also nicht ein ARM-Startup, sondern sie kaufen das Knowhow hinter dem Apple-Erfolg.
Wer hätte gedacht, dass es im Prozessormarkt doch nochmal so spannend wird?
Ich finde das jedenfalls gut, wenn wir jetzt ein paar ARM-PCs kriegen. Schön mit Linux drauf, versteht sich.
Update: Diverse Leser wiesen mich darauf hin, dass Android nicht betroffen ist (bis auf uralte Versionen).
Damit keine Malware auf Linux-Servern landet, sollten Admins die eigentlich schützende Software ServerProtect for Linux (SPLX) von Trend Micro auf den aktuellen Stand bringen. Das von der Lücke ausgehende Risiko gilt als "kritisch".Hat zufällig jemand eine Statistik greifbar, wie viel Linux-Malware Trend Micro so "erkennt"? Und in ihrer Firmengeschichte insgesamt abgewehrt hat? Ist jemandem ein einziger Fall bekannt?
Sprecht mir nach: Antiviren sind Schlangenöl!
New hotness: Microsoft operiert Windows aus Windows raus :-)
Starting with Windows Insiders preview build 20211, WSL 2 will be offering a new feature: wsl --mount. This new parameter allows a physical disk to be attached and mounted inside WSL 2, which enables you to access filesystems that aren’t natively supported by Windows (such as ext4).Ja, äh, wenn ich eine Linux-Partition mounte und davon Linux-Programme ausführe, … wieso hab ich dann überhaupt noch Windows?
Da werden aber bei den ganzen Sklaven der Neuzeit die Korken knallen! Endlich befreit sie mal jemand!
#include <string.h>
int main() {
char buf[10];
memcpy(buf,"fnord",6); // ok
memcpy(buf,"fnordfnord",11); // not ok
}Wieso heult der Compiler da nicht? Weil der Compiler nur die Typen kontrolliert, und die sind hier OK.Es gab da jetzt mehrere Ansätze, wie man dieses Problem lösen kann. Einer davon ist der hier:
$ gcc -O -o t t.c -D_FORTIFY_SOURCE=1 $ ./t *** buffer overflow detected ***: ./t terminatedDas hat mehrere Nachteile. Es funktioniert nur mit -O oder stärkerem Optimizer. Es funktioniert nur auf einige eingebaute Funktionen. Es funktioniert nur, wenn das Ziel ein Buffer und kein Pointer ist (weil das über Makros implementiert ist, die sizeof() benutzen). Und es fügt zusätzlichen Code ein, der das Programm langsamer machen wird.
Hier ist die neue Lösung mit den oben beschriebenen Attributen:
#includeWenn wir das mit dem neuen gcc kompilieren, auch ohne Optimizer, gibt es diese Warnung (auch wenn gar keine Warnungen angeschaltet wurden!):__attribute__((access(read_only,2,3), access(write_only,1,3))) void* memcpy2(void* dest, const void* src, size_t len) { return memcpy(dest,src,len); } int main() { char buf[10]; memcpy2(buf,"fnord",6); // ok memcpy2(buf,"fnordfnord",11); // should reject or at least warn }
t.c: In function ‘main’:
t.c:11:3: warning: ‘memcpy2’ writing 11 bytes into a region of size 10 overflows the destination [-Wstringop-overflow=]
11 | memcpy2(buf,"fnordfnord",11); // should reject or at least warn
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
t.c:4:7: note: in a call to function ‘memcpy2’ declared with attribute ‘write_only (1, 3)’
4 | void* memcpy2(void* dest, const void* src, size_t len) {
Auch diese Lösung hat Nachteile. Auch sie funktioniert nur, wenn der Compiler die Größe des Zielbuffers kennt, und die Länge der Quelle zur Compilezeit feststeht. Auf der anderen Seite kann man durch Inlining den Kontext der für den Compiler zur Compilezeit sichtbaren Konstanten erweitern, es erzeugt keine Laufzeitkosten, funktioniert auch ohne Optimizer und man kann seine eigenen Funktionen annotieren, um diese Diagnostik im Compiler freizuschalten. Das ist schonmal ein guter Schritt nach vorne, insbesondere da Microsoft vergleichbare Funktionalität seit Jahrzehnten bietet. Die verwendet außer Microsoft selbst kaum jemand, weil die Windows-Coder alle doof sind. Das wäre jetzt die Gelegenheit für die Linux-Gemeinde, es denen mal so richtig zu zeigen!!1!
Ein Kumpel von mir hat sich kürzlich eine WD Elements Portable 5TB Platte gekauft, und musste feststellen, dass die unter Linux nicht funktioniert. Die Firmware unterstützt die "WRITE SAME" SCSI-Anweisung nicht.
Ich hab ja schon viel Pfusch im IT-Sektor gesehen, aber ohne Not SCSI-Opcodes einfach nicht mehr zu supporten ist schon echt krass.
Bei der Gelegenheit erzählte mir der Kumpel auch, dass man die Platte nicht mehr aus dem Gehäuse ausbauen und direkt anschließen kann. Der Bridge-Chip ist direkt auf der Platine der Platte aufgelötet.
Bis WD sich erklärt und entschuldigt kommen mir jedenfalls keine externen WD-Platten mehr ins Haus. What the FUCK!
Kurze Erklärung, wie Netflix funktioniert. Die stellen ihre Video-Server bei eurem ISP auf. Wenn ihr Netflix guckt, dann kommt das nicht von Übersee, im Allgemeinen nicht mal von jenseits des DE-CIX, sondern aus dem fucking Netz eures fucking ISPs. Die einzige Infrastruktur, die da also überlastet sein könnte, wäre die des ISP. Und wisst ihr, was passiert, wenn Netzinfrastruktur überlastet ist? Dann werden Pakete gedroppt. Und wisst ihr, wer das sofort merkt? Euer Client. Und der holt sich dann automatisch die nächstkleinere Auflösung, weil er annimmt, DASS DIE FUCKING INFRASTRUKTUR ÜBERLASTET IST.
Noch nicht überzeugt? Euer ISP kann selbstredend auch Traffic künstlich runterpriorisieren. Das nennt sich Traffic Shaping. Einfach Netflix und Youtube runterdrehen. Wisst ihr, woran ihr erkennt, dass sie das machen? tagesschau.de flutscht noch, aber euer Youtube ruckelt. Oder noch besser: Gar nichts ruckelt.
Es gab hier keinen Handlungsbedarf. Die EU hat Netflix kaputtgemacht.
Im Übrigen sei der Hinweis erlaubt, dass Netflix einer der technisch besten Streaming-Anbieter ist, wenn es um schonende Bandbreitennutzung geht. Amazon streamt z.B. deutlich verschwenderischer. Daran könnt ihr sehen, dass es hier nicht um die Sache ging, sondern ein EU-Fuzzy wollte gerne beim Handeln gesehen werden. Leadership!!1!
Update: Nach Netflix jetzt auch Youtube. Für die gilt alles oben gesagte ebenfalls.
Update: Kurze Anmerkung noch dazu: Auch wenn die Netzneutralitätsleute das nicht gerne hören: Traffic Shaping ist ganz normal. Geht mal davon aus, dass euer Internet auch Traffic Shaping macht. Und zwar nicht nur euer ISP, auch euer Plasterouter. Denn wenn der Plasterouter das nicht machen würde, dann würde bei euch bei jedem Upload gar nichts mehr gehen. Verbindungen sind im Internet paketbasiert. Wenn du was downloadest, schickt dir die Gegenseite immer ein großes Paket mit dem nächsten Datenhappen, und dann schickst du der Gegenseite ein kleines "ist angekommen"-Paket. Weil die Internetprovider kapitalistische Schweinebacken sind, haben sie euer DSL genau so ausgelegt, dass vom Internet zu euch hin die Bandbreite dick ist, und von euch zum Internet hin ist sie dünn. So dünn, dass es genau reicht, um für einen die Leitung auslastenden Speed-Test alle "ist angekommen"-Pakete rauszuschicken. Warum erzähle ich das? Ohne Traffic Shaping würde ein Upload euer Internet komplett zum Erliegen bringen, weil die kleinen "ist angekommen"-Pakete nicht mehr oder nur stark verspätet rausgehen würden. Daher machen alle Plasterouter Traffic Shaping und priorisieren die "ist angekommen"-Pakete. Die heißen übrigens ACK.
Trafficpriorisierung funktioniert in der Praxis gerne so, dass lange Bulk-Verbindungen (Downloads, Backups) die kleinste Priorität kriegen, dann Streaming-Dienste, dann Videokonferenzen und Fernwartung, dann DNS und interaktive Dienste wie SSH und die höchste Priorität haben ACKs.
Wer sich für die Details interessiert, wie man sowas unter Linux selbst konfiguriert: Die Referenzdokumentation von Bert Hubert.
Wer darin jetzt einen schönen Bug findet, kann damit einmal alle Kunden von Avast hopsnehmen.
Damit man beim Bugsuchen nicht so viel Schmerzen hat, hat der gute Tavis das unter Linux lauffähig gekriegt. Viel Spaß!
Zur Abwechslung ist es mal kein Intel-Hardware-Bug sondern schlicht nicht fertig implementierter Code.
Ach komm, Fefe! Es kompiliert! Das shippen wir!!1!
Hey, Fefe, ich verstehe gar nicht, wieso unsere Behörden keine IT-Experten finden! Wir haben doch alles getan, um den Nachwuchs zu fördern!!
Der Name ist eine Anspielung auf die OffensiveCon, ebenfalls in Berlin, in ein paar Tagen. Dort treffen sich so Exploit-Schreiber und Malware-Leute und diskutieren Angriffsmethoden und -vektoren. Mich stört das schon länger, dass die Regierungen alle in Angriff investieren und niemand macht Verteidigung. Daher freute ich mich, dass jemand eine Gegen-Con macht.
Meine Erwartung war: Fehlerminimierende Softwarearchitektur, resilienzsteigernde Netzwerkarchitektur, vorbeugender Coding-Stil, sowas.
Tatsächlich war das aber ein Treffen von der AG Kritis. Kritis ist der Name für das BSI/BBK-Projekt zum Schutz kritischer Infrastrukturen, also Strom, Wasser, Krankenhäuser, etc. Ich habe mich da nie für interessiert, weil das aus meiner Sicht voll am Thema vorbeischießt. Die reden da überhaupt nicht darüber, wie wir eine sichere Infrastruktur aufbauen können, oder wie wir von Windows+Outlook+Active Directory wegkommen, sondern die optimieren da, wie schnell man nach einem Emotet-Befall neu aufsetzen kann. Den Emotet-Befall selbst verhindert niemand. Der ist bei dem Zustand der Infrastruktur so sicher wie das Amen in der Kirche.
Aus meiner Sicht ist damit das ganze Projekt nicht interessant. Versteht mich nicht falsch: Man kann da prima Geld verdienen. Man kann Installationen zertifizieren, man kann Audits machen, ob alle Punkte auf der Checkliste bearbeitet wurden, … aber nichts davon finde ich auch nur das geringste bisschen attraktiv. Nicht nur ist das nicht attraktiv, es hilft auch niemandem. Meine Code Audits haben zumindest einen nachweisbaren kurzfristigen Nutzen in die richtige Richtung. Das, was wir aber mal wirklich machen müssten, das macht niemand. So war dann auch eine meiner ersten Wortmeldungen aus dem Publikum nach dem Vortrag des BSI-MIRT (Mobile Incident Response Einheit). Ich fragte den BSI-Menschen, da ja Windows+AD+Outlook der Einfallsvektor für Emotet sei, ob sie da mit gutem Vorbild vorangehen und was anderes einsetzen. Er verweigerte lieber die Aussage, und meinte dann in der Pause so zu mir: Wir haben auch eine Menge Linux-Rechner!!
Ich bin inzwischen der Meinung, dass das nicht nur nicht hilfreich ist, sondern dass das aktiv schädlich ist, wenn man in Incident Response investiert. Ich kenne das von Software-Herstellern. Wenn der Daemon sich automatisch restartet nach Crashes, dann ist der Leidensdruck weg, was gegen die Crashes zu tun. Dann lebt man halt mit den Crashes. Ich habe das auch bei der Softwareentwicklung schon beobachtet, dass mir Entwickler erklärten, es gäbe da ja eine Security-Abteilung, die für sowas zuständig sei, daher müsse man sich hier jetzt nicht so stressen deswegen.
Die zentrale Verlautbarung auf der Konferenz war aber die Vorstellung eines neuen Cyberwehr-Konzeptes. Weil es schon ein Cyberwehr-Konzept gab, und das voll verkackt wurde und gescheitert ist, heißt das jetzt Cyber-Hilfs-Werk, als Wortspiel auf das THW. Die Idee ist, dass man bei einer "Großschadenslage" (ein Konzept aus dem analogen Katastrophenschutz) erste Hilfe leistet, damit die Versorgung der Bevölkerung schnell wieder anläuft. Wenn jemand unseren Strom wegcybert, dann könnte das Menschenleben kosten. Das ist also schon quasi unterlassene Hilfeleistung, wenn ich als Nerd dann nicht freiwillig und ehrenamtlich mithelfe.
Sorry, aber das sehe ich überhaupt nicht so. Im Gegenteil. Das setzt die völlig falschen Anreize. Wenn die Stromkonzerne sich darauf verlassen können, dass ich ihnen im DurchNotfall den Arsch abwische, wieso sollten die dann in Vorbeugung investieren?
Ja aber Fefe, sagten die mir, das ist doch ein Großschadensfall! Der ist eh schon astronomisch teuer! Dann müssen wir halt dafür sorgen, dass das nicht billiger wird durch unseren ehrenamtlichen Einsatz!
Sorry, überzeugt mich auch nicht. Die Unternehmen spekulieren offensichtlich darauf, wenn wir schon die völlig überflüssigen und volkswirtschaftlich kontraproduktiven Banken mit Milliardenbailouts retten, und da war noch nicht mal ein Angreifer am Start sondern die haben sich mit ihrem Gezocke selber versenkt, dann ist ja wohl aus Sicht der Stromversorger völlig klar, dass der Staat bei einer Großschadenslage einspringen würde. Ich erinnere daran, dass die Bahn ihr Schienennetz auf Verschleiß fährt und nicht ausbessert, weil bei akuter Einsturzgefahr von Brücken der Staat zahlt und nicht die Bahn. Glaubt mal nicht für eine Sekunde, dass die Stromkonzerne auch nur einen Euro in Vorsorge investieren, wenn sie sich den auch in die Tasche stecken oder an die Shareholder auszahlen könnten.
Ich fühle mich in meiner Position bestätigt, wenn ich sehe, dass Vater Staat das Konzept der Cyberwehr großartig findet und voll an Bord ist. Vater Staat ist nämlich nicht so doof wie man immer glaubt. Das ist ja schon länger meine These, dass so viel Verkacken nicht nur mit Inkompetenz erklärbar ist. Das ist Strategie. Der Staat sieht das offensichtlich genau so wie ich und würde gerne die Kosten für die Reparatur an die Ehrenamtlichen externalisieren.
Als der wohlmeinende Vortragende dann noch erklärte, dass man aus versicherungstechnischen Gründen nur auf Anordnung (!!) des Innenministeriums (!!!!) aktiv würde, weil man dann ein Verwaltungshelfer sei und gegen Unfälle auf dem Weg zum Einsatz versichert sei, da knallten bei mir die letzten Sicherungen auch noch durch. GANZ SICHER werde ich NIEMALS für das Innenministerium irgendwas tun. Das sind die Leute, die mir aktuell Trojaner auf die Geräte spielen wollen. Das sind die Leute, die gegen meine Proteste Videoüberwachung ausgerollt haben, obwohl klar war, dass das nichts bringt und meine Grundrechte verletzt. Das sind die mit dem großen Lauschangriff. Mit der Funkzellenauswertung. Das sind die mit dem Hackertoolverbot. DIE LETZTEN, auf deren Ruf ich zur Mithilfe bereit bin, sind die vom Innenministerium. Das geht gar nicht. Absoluter No-Go.
Mir tut das echt in der Seele weh, denn in der Szene sind viele liebe kompetente hilfsbereite Nerds, die einfach nur Menschenleben retten wollen. Aber ich glaube, dass das nie besser wird, wenn wir nicht mal einen so richtig fetten Großschadensfall haben und denen ihre Ministerien niederbrennen, weil keiner vorgesorgt hat. Je länger dann alles down ist, desto besser. Damit das auch mal Konsequenzen hat. Mir schwebt da so ein Fight-Club-Szenario vor.
Aber genug von der Cyberwehr. Es gab auch noch andere Vorträge. Zum Beispiel einen über die völkerrechtliche Bewertung von Hackback. Nun habe ich mich ja schon zu Hackback geäußert, aber nicht zu rechtlichen Fragen. Das war Absicht. Ich halte die rechtliche Debatte für kontraproduktiv. Auf der anderen Seite sitzen schließlich die Leute, die Gesetze machen. Wenn du denen nachweist, dass ihr Scheiß gegen die Gesetze verstößt, dann machen die halt neue Gesetze. Das Völkerrecht kann ich nun überhaupt nicht ernst nehmen. Das ist Freiwilligenrecht. Für mich war das Interessanteste an dem Vortrag daher nicht der Inhalt, sondern wie die Vortragende es vortrug. Mit dem Brustton der Überzeugung kamen da so Aussagen wie: Das wäre dann klar völkerrechtswidrig. Äh, mal in den Irak geguckt? Wie war das mit unserem NATO-Angriffskrieg in Jugoslawien damals? Auch alles klar völkerrechtswidrig. Hält genau niemanden auf. Die halten nicht mal inne und denken nochmal drüber nach. Die Vortragende dann so: Das hat der Internationale Gerichtshof so festgestellt! Ja, äh, und? Erinnert mich an eine Aktionskarte bei dem Brettspiel Junta. "Studenten protestieren gegen Menschenrechtsverletzungen. Keine Auswirkungen." Daher habe ich mich in meinen Hackback-Überlegungen darauf konzentriert, dass das auch inhaltlich völlig bekloppt ist und garantiert nicht weiterhelfen wird. Ein weiterer Referenzpunkt in dem Vortrag war die Martensklausel. Googelt das mal selbst und überlegt euch, ob ihr das ernst nehmen würdet als Rechtsnorm. Und wer da eurer Meinung nach für die Durchsetzung zuständig ist.
So bin ich am Ende in der paradoxen Lage, dass das eine wunderschöne Konferenz mit kompetenten Vortragenden und netten Unterhaltungen war, aber ich inhaltlich nichts gelernt habe. Ich habe schon Dinge gelernt, aber über die Leute, nicht über die Inhalte.
Hmm. So kann ich euch jetzt nicht gehen lassen. Lasst uns mal ein Szenario entwickeln, in dem das schon alles gut ist. Mir fällt nur eins ein: Strukturelle Inkompetenz. Strukturelle Inkompetenz ist, wenn du dich freiwillig bereiterklärst, in der WG das Geschirr zu waschen, und das dann so unzureichend wäschst, dass sie dich nie wieder fragen werden. Möglicherweise ist das Cyberhilfswerk auch sowas. Wir reden jetzt jahrelang darüber, und dann machen wir einen Plan, und der Plan rechnet dann mal aus, wieviel das im Zweifelsfall hilft, und kommt zum Ergebnis: Gar nicht. Vielleicht merken die dann, dass sie lieber vorbeugen sollten. Angesichts der praktisch reinen Symbolpolitik in Digitalfragen halte ich das für eine gefährliche Strategie. In allen bisherigen Fällen hat der Staat dann trotzdem die offensichtlich und mit Ansage ungenügende schlechte Idee umgesetzt, und dann danach schockiert festgestellt, dass es nicht geholfen hat. Warum sollte das diesmal anders laufen?
Übrigens, am Rande: In Israel fährt der Staat jetzt das volle Arsch-Abwischen-Programm und telefoniert proaktiv Firmen hinterher, sie sollen mal patchen. Wie in der Seniorenresidenz. Hast du heute schon deine Pillen genommen? Was für ein Menschenbild! Meine Erfahrung ist außerdem: Wenn du Menschen wie Kleinkinder oder Alzheimerpatienten behandelst, dann werden die sich auch wie Kleinkinder oder Alzheimerpatienten verhalten.
Update: Was wäre denn mein Vorschlag? Strafen. Hohe Strafen. Und nicht warnen sondern direkt die Firma schließen. Das muss richtig doll wehtun, wenn du die Infrastruktur runterkommen lässt, weil du glaubst, die Kosten externalisieren zu können. RICHTIG fucking schmerzhaft muss das sein. So mit rückwirkender Pfändung von vorher ausgezahlten Vorstands-Gehältern und so. Und insbesondere würde ich das für den Aufsichtsrat schmerzhaft machen, wenn sie ihrer Aufsichtspflicht nicht nachkommen.
Das ist eigentlich auch Teil von Kritis übrigens. Wenn der Auditor sagt: Das hier ist ein hohes Risiko. Dann kann die Firma sagen: Wir akzeptieren das Risiko. Nur hat das im Moment halt keinerlei Auswirkungen, wenn das ganze Ding dann hochgeht. Das müssen wir ändern.
Update: Einer der anderen Veranstalter weist darauf hin, dass nur 3/5 bei AG Kritis sind, aber 5/5 in der c-base. Die akkuratere Darstellung wäre also, dass das eine c-base-Veranstaltung war, auch wenn das Programm am Ende Kritis-lastig aussah :-)
Update: Leserbrief dazu:
in Deinem Kritis-Rant schreibst Du: "Wenn der Auditor sagt: Das hier ist ein hohes Risiko. Dann kann die Firma sagen: Wir akzeptieren das Risiko."
Das ist i.A. richtig, aber eben nicht bei Kritis-Audits. Dort gilt vielmehr: "Der B3S stellt klar, dass bzgl. relevanter Risiken für die kritische Dienstleistung eine eigenständige dauerhafte Risikoakzeptanz durch den Betreiber in der Regel keine zulässige Option im Sinne des BSIG ist" (Orientierungshilfe zu Inhalten und Anforderungen an branchenspezifische Sicherheitsstandards (B3S) gemäß § 8a (2) BSIG, Abschnitt 4.3.2, Quelle)Ob das am Ende einen großen Unterschied macht, sei mal dahingestellt ...
Doch das Gegenteil ist der Fall: Die Lizenzmodelle der Software-Heinis werden immer grotesker. Die Datenbank- und VM-Hersteller wollen auch noch pro Core bezahlt werden, und sägen damit an dem Ast, auf dem sie sitzen.
Eigentlich müsste man angesichts dieser Frechheit eine Völkerwanderung zu Open Source beobachten. Tut man auch, aber anders als ihr annehmt. Nicht die Enduser benutzen alle Open Source, sondern die kommerziellen Software-Heinis benutzen alle Open Source. Ja genau. Die, die euch dann pro Core Lizenzkosten aufdrücken wollen. Die benutzen intern selber alle Open Source. Denn wer wäre schon so blöd und zahlt pro Core, amirite?
Ich bin ja eh immer wieder erstaunt, dass es kommerzielle Datenbanken wie SQL Server und Oracle überhaupt noch gibt. Früher konnte man sich da was zurechtlegen von wegen "das skaliert bestimmt besser", aber geht doch mal gucken, was die Cloud-Leute für Datenbanken anbieten. Postgres! Die, die beruflich mit Skalierung zu tun haben, die nehmen Postgres. Die, die Skalierung nur vom Golfplatz kennen, wenn sie anderen CEOs vorlügen, wie fortschrittlich ihre IT ist, die nehmen kommerzielle Datenbanken.
Aber aber aber Fefe, das ist bestimmt eine Supportfrage! Wer ordentlichen Support haben will, der kauft beim Marktführer! Wer das sagt, hat offensichtlich noch nie einen Supportfall bei einem Marktführer in Anspruch genommen. Wie man da behandelt wird, das ist unter aller Kanone. Denn die haben euer Geld ja schon an der Stelle. Wieso sollten die euch mit Respekt behandeln? Ihr seid ja schon im Lock-In gefangen und habt den langjährigen Knebelvertrag unterzeichnet! Und wieder: Die, bei denen die Supportkosten wirklich Einfluss auf die Profitmarge haben, die Cloud-Leute, die nehmen lieber Postgres.
Und die nehmen auch nicht VMware sondern lieber Linux-Container und Kubernetes.
Wir sind halt in alle Richtungen von Morast umgeben.
Der Vortrag von Andy über die Überwachung in der Botschaft von Ecuador hat Überwachungsvideos aus deren Kameras gezeigt. Und zwar hatte Ecuador ja eine spanische Firma mit der Security der Botschaft beauftragt, und die hat sich dann nebenher von der CIA bezahlen lassen, um die Überwachungserkenntnisse zeitnah den Amerikanern zu geben. Das ging soweit, dass die die zuständige Behördenleiterung in Ecuador bestochen haben, um einen Vorwand für das Nachrüsten von Wanzen zu erreichen. Das ist jedenfalls wohl der aktuelle Stand der Ermittlungen in dem Verfahren in Spanien, in dem aber bisher noch nicht mal Anklage erhoben wurde. Der Chef hat aber die CIA-Kohle nicht mit seinen unterbezahlten Schergen geteilt, woraufhin ein paar von denen spontan ein Gewissen entwickelten und zu Whistleblowern wurden. Da kommen diese Aufnahmen jetzt her.
Julian Assange hat in der Botschaft mit Abhörversuchen gerechnet und daher im Konferenzraum einen Rauschgenerator installiert. Die Lautsprecher von dem Teil waren dann u.a. direkt neben dem Fenster montiert, woraufhin das CIA-Team im Haus gegenüber, die per Laser den Schall von den Fenstern abnehmen wollten, keine brauchbaren Aufnahmen bekamen. Die haben dann die spanische Firma beauftragt, nach geeigneten Plätzen für eine Innenverwanzung zu suchen und die Wanzen zu montieren. Am Ende haben die im Fuß des Feuerlöschers eine Aushöhlung mit einer Wanze angebracht.
Für die sensibleren Gespräche ist Julian mit Anwalt dann zum Badezimmer gegangen und hat die Dusche laufen lassen. Daraufhin ließ die CIA eine Wanze hinter dem einen Schrank dort anbringen. Es war wohl einigermaßen erheiternd, die fluchenden Amis in den Anfragen an die Spanier zu lesen, weil sie nicht weiterkamen.
Das Ende war dann weniger lustig. Über die Wanze im Feuerlöscher haben die Amis ein Gespräch zwischen Julian und der Geheimdienstchefin von Ecuador belauscht, die Julian einen ecuadorischen Pass beschafft hatten, ihn zum Diplomaten ernannt hatten, und eine offizielle Abberufung in eine Botschaft in einem anderen Land eingetütet hatten. Am nächsten Morgen lag dann überraschend ein internationaler Haftbefehl der USA vor. Überwachen hat also ernsthafte Folgen.
Es gab leider technische Probleme beim Streaming und der Aufzeichnung am Anfang. Ich hoffe mal, das ist trotzdem was geworden. Andy hat extra später angefangen.
Danach saß ich im Archimedes-Vortrag drin, der war auch echt großartig. Wer sich ein bisschen für Computerarchitektur interessiert, für den ist das ein Fest.
Nach diesem Vortrag war ich bei "Von Ich zu Wir", wo sie u.a. gezeigt haben, dass Klimakatastrophe kein Neusprech ist, sondern Klimawandel ist der Neusprech. Klimakatastrophe war im aktiven Gebrauch während der Ozonloch-Geschichte, und das hat gewirkt, wenn ihr euch erinnert. FCKW war schnell verboten und das Ozonloch hat sich deutlich gebessert. Maha rief mich dann öffentlich dazu auf, in meinem Blog überall Klimawandel durch Klimakatastrophe zu ersetzen. Ich sehe mein Blog auch als Archiv und werde das daher nicht tun, aber ich werde versuchen, ab jetzt immer Klimakatastrophe zu sagen. Wörter haben Macht.
Der PSD2-Vortrag war dann doch weniger Rant und mehr Katastrophentourismus. Der rote Faden war eine gewisse ... sagen wir mal Abneigung gegen Sofortüberweisung, die ja auch bei mir im Blog nie gut weggekommen sind. Am Ende stand dann in der QA-Session jemand auf und meinte, er arbeite ja für Sofort, und sie seien ja alle gemeinsam daran interessiert, dass das besser würde. Das ist für mich der Balls of Steel Award diees Congresses.
Plundervolt war so ein bisschen zu klamaukig für meinen Geschmack aber inhaltlich haben sie schon eine Wunde gerissen. Und zwar kann man bei Intel-CPUs per MSR per Software Undervolting aktivieren. Wenn man das gezielt macht, kann man Glitches erzeugen. So haben sie die Intel-Secure-Enclave-Technologie angegriffen und u.a. Crypto-Keys extrahiert. Die tatsächlichen Auswirkungen werden glaube ich eher gering sein, weil m.W. so gut wie niemand diesen Enclave-Kram tatsächlich verwendet. Aber für Intel ist das halt ein weiterer Messerstich. Praktisch alles, was in den letzten 10 Jahren von Intel kam, hat sich seit dem als Katastrophe herausgestellt.
Danach saß ich im Vortrag über die Intel Management Engine, der aber ein bisschen unorganisiert wirkte. Wenn man vorher nicht verstanden hatte, worum es da ging, hat man es nachher auch nicht verstanden. Inhaltlich hat der Typ vor allem Exploits der Forscher von Positive Technologies veröffentlicht und seine Eigenleistung war dann, einen Loader zu hacken, mit dem man Management-Engine-Code unter Linux in einem Prozess "emulieren" kann, dann wenn man möchte in einem Debugger. Das ist schon geile Scheiße, ich will das nicht kleinreden. Aber das kam in dem Vortrag erst so gegen Ende und weil der Vortragende das Zeitmanagement verkackt hatte, musste die Vorführung davon dann auch noch gestrichen werden. Schade.
Ich habe da immer dankend abgelehnt und lieber HDMI haben wollen, obwohl auch bei HDMI auf Host-Seite Parsing stattfindet und es auch da schon Probleme gegeben hat.
F-Secure hat sich das mal angeguckt und es ist ungefähr so schlimm, wie man befürchten würde. Wobei die meisten der Lücken das Gerät selbst betreffen, nicht was das mit dem Host macht. Auf dem Gerät haben sie anscheinend eine Firmware mit einem Linux gefunden, das lässt sich dann relativ gut reverse engineeren. Auch ohne Quellcode. Auf Hostseite macht so einen Treiber reversen macht deutlich weniger Spaß. Ich vermute mal, dass das der Grund sein wird, wieso deren meisten Fundstücke auf Geräteseite sind.
Ich würde auch zukünftig davor warnen, auf Zuruf in einem Konferenzzimmer ein USB-Gerät anzustöpseln, das da immer rumliegt, und dann auch noch Ja zu klicken, wenn das Treiber installieren will.
Heute als Doppel-Einschlag: Cisco-Schlangenöl!
A vulnerability in the implementation of the Lua interpreter integrated in Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an authenticated, remote attacker to execute arbitrary code with root privileges on the underlying Linux operating system of an affected device.Das setzt Maßstäbe. Der Scheiß läuft als root! Als root!!Ich sollte die Gelegenheit nutzen, mal grundsätzlich vor Appliances zu warnen. Es gibt da ein verbreitetes Missverständnis. Spezialisten sind nicht gut darin, etwas gut zu machen, sondern die sind gut darin, etwas schnell und billig anzubieten. Leute, die Appliances anbieten, sind gut darin, Appliances günstig anzubieten. Und Appliances haben den "Vorteil", dass Kunden im Allgemeinen nicht reingucken dürfen. Da kann man als Hersteller also ganz andere Pfusch-Level fahren (obwohl es da erschütternderweise auch bei Nicht-Appliances wenig Zurückhaltung gibt).
Dass da zentrale Dienste ohne Not als root laufen, das ist im Appliance-Umfeld nicht selten. (Danke, Martin)
Aber ihr habt euch nicht getraut, weil ihr da keinen Windows Defender habt, um euch für der bösen Malware zu schützen?
Dann habe ich großartige Nachrichten für euch: Microsoft portiert ihr Schlangenöl gerade nach Linux und nennt es "Microsoft Defender".
Endlich wird Linux Enterprise-fähig und telefoniert auch mal industrie-standard-konform ständig nach Redmond!!1!
Unter anderem erzählt er von einem Spontan-Besuch von Steve Ballmer, der dafür extra seinen Skiurlaub in der Schweiz unterbrach.
Aber dann sagte er, ich stünde vor einer katastrophalen Fehlentscheidung, die ich niemals vor irgendwem verantworten könne, vor allem vor keinem Steuerzahler.Aber nicht nur Ballmer kam vorbei, auch Bill Gates himself.Er machte witzigerweise während des Gesprächs ständig neue finanzielle Angebote, was Microsoft noch alles zusätzlich dazugäbe, für das Schulreferat zum Beispiel. Laufend wurden die um eine Million und noch eine Million und noch eine Million und später ein Dutzend Millionen günstiger als zuvor. So wichtig war Microsoft die international als IT-Hochburg wahrgenommene abtrünnige Landeshauptstadt München als Symbol.
Nachdem ich jetzt nicht der hartgesottene IT-Spezialist bin, der einem Bill Gates gewachsen wäre bei jedem Detail, habe ich nur gesagt: „Bitte nehmen Sie zur Kenntnis, es geht uns um die Unabhängigkeit. Wir wollen nicht abhängig sein.“ Dann sagte er: „So ein Unsinn, von wem denn abhängig?“ „Weil Sie schon mal da sind: Von Ihnen natürlich!“ Das hat ihn richtig in sich zusammenfallen lassen, und er hat gesagt: „Es ist für mich unbegreiflich, das ist Ideologie.“Dabei ist die Idee für die Migration überhaupt erst dadurch entstanden, dass Microsoft unilateral den Support einstellte und München sich dadurch von ihnen erpresst fühlte.
Ich entwickle mein Forth ja unter Linux, und die Windows-Variante ist unter den Windows-Anhängern nicht so wahnsinnig populär. Ich habe dafür trotzdem so einen Signatur-Voodoo-Key, was einem ganz gut hilft gegen false positives, denn mir sind auch schon Windows-Distributionen weggelöscht worden von diesem Snake-Oil-Zeugs. Das tut anscheinend, jedenfalls ist die gforth.exe nicht verbrannt. Ähnlich bin ich mit bigForth vorgegangen, und das hat auch geklappt (also, derzeit keine false positives, obwohl das mal früher schon ein Problem war).Die Leute, die Win32Forth entwickeln, sind da viel unbedarfter drangegangen, haben sich kein Zertifikat besorgt, und nichts gegen die ersten false positives unternommen. Deren System wird inzwischen von 14 recht populären Snakeoils erkannt, wobei Microsoft dabei ist. Da hat man dann kaum noch Chancen, damit durchzukommen. Die sind jetzt ziemlich verzweifelt, und überlegen sich, ob sie einfach alle auf Linux umsteigen, und ihr Forth unter Wine weiterbetreiben (wobei natürlich die Frage ist, wozu sie das dann noch da dran weiterentwickeln — aber als Windows-Nutzer kommen sie halt mit der GPL sehr grundsätzlich nicht klar, und ich habe auch irgendwie den Eindruck, dass es auch noch andere Gründe gibt, warum die an Windows festgepappt sind, und die hängen an der generellen Kompetenz — die ursprünglichen Entwickler von Win32Forth sind längst nicht mehr dabei).
Mein Blog unterstützt das jetzt in den ganzen CSS-Varianten, die ich gemacht habe (und nicht eingeschickt wurden), und ich kann unter Linux nicht nutzen.
In about:config gibt es ein Setting browser.in-design.dark-mode, aber das schaltet nicht den Dark Mode an, sondern sagt Firefox, dass er das in die Webseiten propagieren soll, wo man es im CSS abfragen und reagieren kann. Aber wie man es anschalten soll, darüber hat offenbar noch keiner nachgedacht.
For the record: In chrome kann man das über die Kommandozeile anschalten:
--enable-features=WebUIDarkMode --force-dark-mode
Die offizielle Antwort scheint zu sein, dass man eine Webextension installiert. m(
Update: Ein Leser hat die Lösung: Man muss einen neuen Key anlegen: ui.systemUsesDarkTheme = 1
Das funktioniert hier auch gerade tatsächlich.
Das hab ich jetzt davon, dass ich neulich rumscherzte, ping of death gelte als ausgestorben.
Hier ist mal ein praktisches Beispiel:
We started in .NET Core 1.0 with a very minimal API set that only included ~18K of the .NET Framework APIs.Zum Vergleich: Linux hat so um die 300 Syscalls. Und ich kenne niemanden, der das API für minmal hält. 18k ist nicht minimal, nach keiner Definition irgendwo. Nichts an 18k ist minimal.With .NET Standard 2.0, we tried to make it much more viable to share code between .NET Framework, .NET Core, and Xamarin which resulted in approximately 38K .NET Frameworks APIs being available in .NET Core 2.0.Kann irgendjemand hier auch nur 18k Funktionsnamen gleichzeitig im Kopf haben? Wie ist es mit 38k?We also built the Windows Compatibility Pack which made another 21K .NET Framework APIs available to .NET Core, resulting in almost 60K additional APIs.Oh super, 60k! Wenn ich "völlig außer Kontrolle geraten" visualisieren müsste: So würde ich es visualisieren.And in .NET Core 3.0 we added WPF and WinForms, which increased the number of .NET Framework APIs ported to .NET Core to over 120k, which is more than half of all .NET Framework APIs.Fuck yeah! 120k! Damit sind wir über der Hälfte der APIs im .NET-Framework!!1!Wie absurd.
Und dann tun die auch noch so, als könne irgendjemand das verstehen oder warten oder für die Funktionsfähigkeit davon garantieren. Wer baut denn bitte auf so einem Komplexitätsmonster noch seine Business-Software auf, die nochmal einen Komplexitäts-Wolkenkratzer draufpackt?
Creating tomorrow's legacy, today!
Das ist übrigens auch der Hintergrund hinter der GPL und freier Software. Dass die Hersteller nicht willens oder zu inkompetent sind, ihre zahlenden Kunden mit Fixes zu beliefern, und man daher eine Lizenz braucht, bei der der Kunde das zur Not selber machen kann. Stallman hat jahrzehntelang die Story von einem Drucker am MIT erzählt. Das war (ohne Scheiß jetzt) der Auslöser für das GNU-Projekt. Und was haben wir heute? Zwar GPL-Linux auf allen Android-Geräten, aber niemand aktualisiert die Kernel. Da ist überall noch irgendein 3.x-Kernel von vor gefühlt 20 Jahren drauf. Bei dem irgendein armes Schwein in einem schlecht belüfteten Büro Patches nachpflegen soll.
Nur geht das halt nicht. An Security-Patches steht nicht unbedingt dran, dass es sich um solche handelt. Und selbst wenn es dransteht, verkacken sie es.
Dafür, dass bei Google ja angeblich so viele superschlaue Menschen arbeiten, würde man ja schon denken, dass denen das irgendwann auffällt.
Meine Vermutung: Die Schlauen arbeiten nicht an Android sondern an der Online-Werbung.
Richard Stallman ist der Begründer des GNU-Projektes, dem wir unter anderem GCC und Linux zu verdanken haben, und eine absolute Legende unter Hackern, auch wenn er persönlich etwas schwierig ist (Klassiker, see also). Der Mann ist ein Ideologe und ein Fanatiker, und kompromisslos für freie Software (nicht Open Source, das ist eine fiese Gegenideologie, um sein Baby freie Software zu verwässern). Das klingt jetzt negativ, und es gibt über Stallman sicher viel negatives zu sagen, aber in meinen Augen ist er doch ein Held.
Stallman hat seit ewigen Zeiten beim CSAIL einen Posten, und man erzählt sich Geschichten, dass er da jahrelang im Terminalraum unter dem Tisch geschlafen hat.
Sein Rücktritt jetzt liegt aber an einer anderen Sache. Und zwar hat das MIT Spenden von Jeffrey Epstein angenommen, für das Media Lab. Zuständig war Joi Ito, der Chef des Media Lab, weltbekannt für seine Arbeit dort und allen Erzählungen nach ein exzeptionell gutherziger Mensch. Nun ist das Media Lab aber auf Drittmittel angewiesen (obwohl das MIT auf einem Geldberg sitzt), und so hat Joi Ito da eine Weile gegrübelt, ob er das Geld annehmen soll, und u.a. seinen Freund Lawrence Lessig gefragt, dessen Entschuldigsschreiben dazu ihr hier lesen könnt (empfehle ich, das ist echt der einzige positive Aspekt an dieser ganzen Nummer). Das MIT hat jetzt enorm öffentlichen Ärger abgekriegt, weil der Epstein ja vor vielen Jahren verurteilt wurde für was sich aus heutiger Sicht wie eine Randnotiz seiner Karriere als Zuhälter und Menschenhändler von Minderjährigen für Sexorgien mit Epsteins einflußreichen Promi-Kunden herausstellte — aber bevor das aktenkundig war, ist Epstein unter mysteriösen Umständen im Knast erselbstmordet worden. Er war zwar in dem Selbstmord-Gefahr-Programm, aber gerade zu dem Zeitpunkt waren genau die Kameras vor seiner Zelle ausgefallen und die Wächter waren eingeschlafen. Ja nee, klar.
Und da hat sich der Ärger halt in Richtung MIT entladen. Ironischerweise haben sie dem MIT vorgeworfen, dass sie die Spenden anonym angenommen haben. Lawrence Lessig erklärt sehr eloquent, dass das genau die einzige Waffe des MIT ist, um potentielles Blutgeld anzunehmen — damit man wenigstens dafür sorgt, dass derjenige sich nicht damit schmücken oder reinwaschen kann.
Viele Ultrareiche haben in ihrer zweiten Lebenshälfte ein schlechtes Gewissen und werden plötzlich zu Philanthropen, machen eine Spende nach der anderen, gründen Stiftungen und so weiter. Joi Ito wollte verhindern, dass der Epstein sich mit seinen Spenden für sein Lab von seinem schlechten Ruf reinwäscht und bestand daher darauf, das anonym zu machen.
Jedenfalls hat das nicht gereicht und Ito musste seinen Posten räumen, inzwischen wackeln sogar schon die Stühle seiner Vorgesetzten in der Uni-Verwaltung. Und unter den Leuten, die ihm zur Seite sprangen, war Stallman. Auf einer nicht öffentlichen Mailingliste, aber ein Berufsempörter war schockiert — SCHOCKIERT!!! — und hat das geleakt. Es ging darum, dass unter den Promis, die als Kumpels von Epstein angeblich in den Genuss von Sex mit Epsteins Harem aus Minderjährigen wurden, auch Marvin Minsky sein sollte, der inzwischen verstorben ist, und eine noch größere Legende als Stallman ist, eine der wichtigsten Figuren in der KI-Forschung. Um den Teil geht es aber gar nicht, sondern es geht darum, dass der Vorwurf war, Minsky habe "Sexual Assault" begangen. Stallman findet den Term ungeeignet, weil er häufig auf vergleichsweise geringe Tatbestände angewendet wird, um beim Leser die Vermutung und Emotionen für weit größere Sünden herbeizuführen.
Die Frau, um die es hier geht, war zu dem Zeitpunkt 17.
Stallman sagt jetzt, die werden dem Minsky nicht gesagt haben, dass sie minderjährig ist und das nicht freiwillig macht, und dann wäre Sexual Assault der falsche Begriff.
Stallman sagte auch noch, er finde, dass es nicht OK sei, einen wertenden Begriff wie "Vergewaltigung" zu benutzen, wenn es juristisch von +-1 Jahr Altersunterschied und/oder welchem Land die Tat stattfand abhängt. Das ist eine Ansicht, die ja auch bei Julian Assange und Schweden das eine oder andere Mal zu hören war.
Ich fühle mich ja bei solchen Meldungen immer an dieses Blogposting von 2015 erinnert.
Update: Von seinem Posten im Vorstand der Free Software Foundation ist er auch zurückgetreten.
Ich finde es tragisch, dass immer die falschen Leute genug moralischen Kompass für einen Rücktritt haben, während die, bei denen ein Rücktritt wirklich wichtig gewesen wäre, den Scheiß immer einfach aussitzen können.
Update: Lesenswerter Twitter-Rant über das Media Lab, Epstein und Sugar Daddy Science (toller Begriff, finde ich). Stellt sich raus: Epstein war Eugenik-Fan und erst in zweiter Linie pädophil. Und seine Drittmittel haben das Media Lab korrumpiert, nicht bloß wegen der Quelle sondern auch weil sie genug Kohle hatten, sich nicht mehr anstrengen zu müssen.
Update: Oh angeblich hat die Frau selbst ausgesagt, von niemandem gezwungen worden zu sein. Das spielt natürlich juristisch keine Rolle in einer Jurisdiktion, die bei Minderjährigen annimmt, dass sie nicht zugestimmt haben können.
Es stellt sich nämlich raus, dass Back-Porting eher nicht von fähigen Spezialisten gemacht wird, weil die am aktuellen Kernel arbeiten.
Als ich "100% reliable preauth RCE VPN exploit using format strings" gelesen habe, wurde ich neugierig. Auf modernen Linux-Systemen ist das nämlich nicht ganz so einfach, also habe ich mich auf die Lektüre eines schönen Exploits gefreut. Stattdessen finde ich so ziemlich das einfachste, was so geht. Daher mal ein paar Worte dazu, damit auch Laien das etwas besser einordnen können:Dazu ein bisschen Kommentar von mir: Format String Bugs sind in der Tat vergleichsweise einfach zu finden. Wer die in seinem Code hat, hat wenig Ausreden vorzubringen. Aber ganz so trivial ist es dann doch nicht. In der Praxis findet man häufig irgendwelche Präprozessor-Makro-Höllen und Ketten von Funktionen und am besten noch nichts const deklariert. Insofern: Vergleichsweise einfach, aber nicht unbedingt trivial.Format-String-Lücken sind sehr einfach über statische Codechecker zu finden. Quasi jeder Audit hätte das finden sollen. Mit entsprechenden Compiler-Optionen gibt es da auch Warnings.
Bei modernen Linux-Systemen wird sowas auch zur Laufzeit abgefangen: da wird dann nachgeschaut, ob %n in schreibbarem Speicher liegt (= nicht fest einkompiliert, also eventuell von einem Angreifer). Falls ja, wird abgebrochen. Dadurch ist die Lücke nicht komplett weg, aber zumindest Code-Execution wird erheblich erschwert bis unmöglich gemacht, da %n das Arbeitspferd für Code-Execution-Exploits ist. Dazu muss man nicht einmal am Quellcode schrauben.
Der Exploit scheint feste Offsets zu benutzen. Also gibt es da auch keine Address Space Layout Randomization?
Zudem treibt deren Exploit Schindluder mit Global Offset Table und Procedure Linkage Table. Dagegen gibt es RELRO: entsprechende Bereiche sind zu normalen Laufzeit nicht mehr schreibbar, wodurch es nochmal etwas schwieriger wird, einen Exploit zu erstellen.
Ich habe keinen Zugang zum Produkt, daher sind das alles unverifizierte Vermutungen. Aber scheinbar sind die echt noch in der Steinzeit, unfassbar. Oh, und je nach CPU-Architektur sind diese Sachen auch gut in Binärcode zu finden. Ich würde also davon ausgehen, dass kompetente Geheimdienste das kannten.
Die printf-Implementation der dietlibc unterstützt %n schlicht gar nicht. Microsoft hatte das aus der Visual Studio Runtime auch per Default deaktiviert und man muss das von Hand anschalten.
Der Punkt mit ASLR und RELRO stimmt auch, aber das ist halt eine Mitigation-Schlacht am Ende. Da bin ich kein Fan von. Damit wird das Exploiten dann schwieriger, ja, aber der Bug ist nicht weg. Und durch die großartige Softwarequalität da draußen haben wir die User konditioniert, dass sie sich selbst nach Crashes neustartende Software nicht nur tolerieren sondern gutheißen, und dass die Leute sich an ständige Segfaults in ihren Logs gewöhnt haben und kaum noch jemand überhaupt guckt. Im Übrigen hat RELRO auch Nachteile. Die Relokationen müssen alle am Anfang gemacht werden, damit danach die Relokationstabelle read-only sein kann, und das führt bei manchen Szenarios zu merkbaren (nicht nur messbaren) Verlangsamungen, besonders bei großen C++-Programmen mit Tonnen von Shared Libraries, z.B. KDE oder so.
Insofern: Ja, der Punkt mit RELRO ist korrekt, und die Linux-Distributionen haben angefangen, komplett auf RELRO umzustellen. Die CPUs sind ja auch schnell genug. Ich erinnere mich noch, als man kleinere Programme statisch gelinkt hat, weil dynamisches Linken zu langsameren Startup-Zeiten geführt hat. Deshalb ja auch dietlibc als statische Library für kleine Programme.
Ich würde die aber viel lieber dafür kritisieren, dass ihre Software kacke ist, als dass sie auch noch die Best Practices bei den Compiler-Flags verkackt haben. Nicht dass da draußen jemand denkt, Format-String-Bugs seien nicht so schlimm, wenn man RELRO anmacht oder so. Fixt eure fucking Bugs.
Früher war der Developer für die Bugs und der Ops-Typ für das Bauen und Ausrollen zuständig, und der hat sich dann um RELRO gekümmert. Heute mit Devops oder gar Devsecops machen das dieselben Gestalten, und damit ist dann plötzlich Zeit für RELRO nicht mehr für das Fixen von Bugs da. Das ist zum Kotzen und einer der Gründe, wieso Devops und Devsecops Mist ist.
Nun bin ich kein Freund von systemd, aber in diesem Fall haben die bloß eine dokumentierte Instruktion namens rdrand aufgerufen, um sich Zufallszahlen von der Hardware geben zu lassen. Dafür ist eigentlich eine Kernelabstraktion da, die systemd hätte verwenden sollen, dann wären sie jetzt nicht "Schuld" gewesen. /dev/urandom oder getentropy sind der bessere Weg.
Aber daraus, eine Instruktion aufzurufen, kann man ihnen keinen Strick drehen.
Das Problem ist schon länger bekannt und scheint irgendein Initialisierungsproblem bei Ryzen zu sein, wo irgendwelche Prozessor-Status-Flags nicht ordentlich gesetzt werden beim Booten. Das ist im Moment alles Spekulation, aber so sieht es aus, und wenn das stimmt, dann ist das mit einem Bios-Update zu reparieren. Da muss man sich aber schon fragen, wieso AMD ihre Validierung so verkackt. rdrand ist eine für eine Menge Sicherheits-Dinge absolut kritische Instruktion. Alle möglichen Krypto-Protokolle und -Verfahren brauchen Zufallszahlen. rdrand setzt ein Flag, ob es erfolgreich war, und liefert dann einen Wert. Bei AMD setzt es das Erfolg-Flag aber liefert immer alle Bits gesetzt zurück im "Zufallswert". Das ist der Worst fucking Case für diese Instruktion. Die meisten weniger guten Krypto-Implementationen werden keine Prüfung haben, ob der Zufall auch wirklich zufällig ist.
Der einzige Grund, wieso das nicht ein Total-Desaster ist gerade, ist dass eh niemand dem ursprünglichen Intel-rdrand vertraut hat, weil die NSA gerade ein Snowden-Vertrauensproblem hatte und der Zufallszahlengenerator der offensichtliche Geheimdienst-Angriffsvektor auf Open Source Kryptosysteme ist. Daher nimmt der Kernel das auch nur zusätzlich zu anderen Zufallsquellen in /dev/urandom. Hätte systemd also den Zufall vom Kernel bezogen, wäre alles gut gewesen. Auf der anderen Seite hätten wir dann vielleicht gar nicht von diesem Bug gehört. Insofern bin ich systemd doch dankbar. Und bin froh, dass meine Distro nicht auf systemd basiert :-)
Daraufhin gab es Widerspruch bei Golem und jetzt rudert auch Heise zurück. Dabei spielt das doch mal sowas von überhaupt gar keine Rolle, wie irgendwelche Malware-Samples nach Hause telefonieren. Wenn eie Malware nach Hause telefoniert, ist das Kind schon im Brunnen und ist schon blau angelaufen.
Das Problem bei DNS-over-HTTPS ist auch nicht, dass man damit verschlüsselt kommunizieren kann, sondern dass ... ich hatte das hier schonmal ausgeführt ... die Komplexität mehrere Größenordnungen höher ist, ohne dass es tatsächlich einen echten Privacy-Mehrwert bringt. Außer in einem Szenario. Bei einem WLAN, das man sich mit Fremden teilt.
Mein Hauptproblem mit DNS-over-HTTPS war aber, dass das den gesamten Traffic über Cloudflare lenken wollte. Nun halte ich Cloudflare für einen Haufen inkompetente Clowns, aber selbst wenn sie wüssten, was sie täten, was wie gesagt jedenfalls aus meiner Warte nicht der Fall zu sein scheint, selbst dann wäre es eine schlechte Idee, allen DNS-Traffic aller Mozilla-Kunden über Cloudflare zu tunneln. Das macht dann nämlich das Abgreifen der DNS-Daten noch einfacher für die Geheimdienste. Die müssen nur bei Cloudflare den Schnorchel ansetzen. Gerade für US-Geheimdienste, in deren Jurisdiktion Cloudflare liegt, wäre dafür nicht mal Hacking-Aufwand vonnöten.
Also, nochmal zum Mitmeißeln. DOH ist schlecht, weil es so furchtbar komplex ist, nicht weil Malware darüber reden könnte. DOH zu Cloudflare ist schlecht, weil Cloudflare alle Nase lang irgendwelche katastrophalen Ausfälle hat, und weil zentralisiertes DNS-Routing für die Dienste das Abschnorcheln zu einfach macht. Und hört endlich auf, Malware zu analysieren, was sie nach der Infektion macht. Nach der Infektion ist es zu spät. Findet lieber raus, wie die Malware auf das System kommen kann, und macht das zu.
Liebe uninformierten Twitter-Hassprediger! Wenn ihr euch schon über mich aufregt, und zur Illustration Screenshots von mir postet, dann … nehmt doch wenigstens ein CSS dafür. Der hier eignet sich z.B. gut, da vermittelt der Screenshot schon optisch keine inhaltliche Kompetenz. Oder der hier. Oder je nach eurer Font-Sammlung Charter (gibt es hier), Linux Libertine (gibt es hier) oder Alegreya (gibt es hier). Das sind alles schöne Schriftarten, die jeder installiert haben sollte. Und wir sollten endlich mal alle aufhören, unsere User irgendwelchen Font-CDNs ans Messer zu liefern.
Inhaltlich könnt ihr euch ruhig weiter gerne zum Stück Brot machen. Wie heißt es so schön? Was Klaus über Peter sagt, sagt mehr über Klaus als über Peter aus.
Mein persönlicher Favorit ist ja immer, wenn mir so ein an seinem ersten Bartwuchs arbeitender Teenager mangelnde Lebenserfahrung vorwirft. Oder dass ich ja "von Wirtschaft" oder "von Politik" keine Ahnung hätte. Wunderbar! Weitermachen! Das Popcorn muss weg!
PS: Mein erster Blogpost über den tiefen Staat war übrigens 2013.
Ich habe hier einen Kunden-Laptop, auf dem ich mal ein clang-tidy laufen lassen wollte. Also erstmal WSL mit ubuntu geholt. apt-get install clang-tidy gab mit 6.0. Aktuelles Release ist 8.0, ich arbeite sonst mit dem HEAD, das meldet sich als 9.0. Ja, nee, Ubuntu.
OK, dann update ich halt mal das Ubuntu von LTS auf unstable. Dachte ich mir. In meinem jugendlichen Leichtsinn. Erstens will deren CLI-Distro-Upgrade-Tool erst auf Devel upgraden, wenn man vorher auf die aktuelle Stable geupgraded hat. Und das Stable will er erst upgraden, wenn man vorher updated. Ich musste mir also drei komplette Distros ziehen für ein Upgrade. Danke, Ubuntu.
Aber das war nicht, weshalb ich das hier schreibe. Die Upgrades brauchen EWIG. Ich vermute, dass das an der schwachbrüstigen Hardware auf dem Kundenlaptop liegt, und daran, dass die Bitlocker anhaben, und dass da zwei fucking Schlangenöle parall laufen und sich gegenseitig behindern.
Da fiel es mir wie Schuppen von den Augen.
Was wenn WSL2 bloß dazu da ist, das Schlangenöl bei Filesystemzugriffen aus dem kritischen Pfad zu optimieren?
Diese Updates laufen jetzt hier seit über vier Stunden. Und die Pakete kamen mit 100 MBit reingeflutscht, daran lag es nicht.
Update: Dev-Ubuntu kommt mit gcc 8.3 und clang 7. WTF Ubuntu?! Was muss man denn bei euch nehmen, wenn man aktuelle Versionen haben will? Ubuntu Futur?
noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=offMan könnte fast denken, dass die Leute, die die Mitigations bauen, einem neue CPUs verkaufen wollen!1!! (Danke, Kristian)
Linux sagt einem da ja beim Booten dann freundlicherweise ein paar Metadaten. Hier sind sie für meinen Reiselaptop:
microcode: microcode updated early to revision 0x2e, date = 2019-01-02Wait, what? 2. Januar?! Seit dem 2. Januar hat Intel den Fix und wir kriegen ihn erst jetzt!?!?
Äh, wie alt ist denn die Lücke dann? Normalerweise dauert ja schon das Erstellen des Fixes den Hauptteil der Zeit!
Kann natürlich auch sein, dass meine CPU nicht betroffen ist. Ist ein Pentium Silver N5000 in einem passiv gekühlten Acer Swift 1, was ich übrigens gar nicht genug empfehlen kann. Passiv gekühlt, Akkulaufzeit jenseits von einem Tag. Selbst mit Fullscreen-Videoabspielen oder make -j4 hält das Teil stundenlang durch. Ist jetzt kein Performance-Wunder, aber ich baue damit immerhin LLVM und Firefox in erträglicher Zeit. Ich glaube ich muss mir davon ein paar auf Halde kaufen. Das ist das beste Arbeitsgerät, das ich je hatte.
Eigentlich geht es aber bei GnuPG in Behörden gar nicht um Verschlusssachen sondern um normale Behördenkommunikation, z.B. Abgeben der Steuererklärung oder so. Aus der BSI-Zulassung folgt jetzt nicht, dass irgendeine Behörde Maßnahmen einleiten wird, um das zu unterstützen. Aber sie könnten.
Update: Leserbrief dazu:
Das Unternehmen, für das ich arbeite, hat praktisch nur Kunden im Bereich der BOS (Behörden und Organisation für Sicherheitsaufgaben). Zum einen muss man sagen, dass das Wort "zertifiziert" vollkommen falsch ist. Wir reden hier von einer "Zulassung". BSI Zertifizierungen sind was völlig anderes. Den Fehler macht leider auch heise.
Zudem ist diese Zulassung ein Meilenstein. Tatsächlich! Bisher durfte man nur via "CHIASMUS" verschlüsseln. Das ist ein EXTREM in die Jahre gekommenes Tool vom BSI, mit denen nur Dateien (bis max VSNFD) verschlüsselt werden konnten. Eine Email mit VSNFD sah dann halt so aus, dass man diese als TXT-Datei geschrieben, mit besagtem Tool verschlüsselt und als Anlage einer ansonst leeren EMail beigefügt hat. Nix Integration von Outlook. Nix Linux. Jeder, der VSNFD mit Behörden ausgetauscht hat, musste Windows einsetzen. Und an Chiasmus zu kommen ist gar nicht so einfach. Da wurden (OHNE SCHEIß!) CDs rumgeschickt.
Außerdem schreibst du, dass es für Steuererklärungen relevant werden kann. Auch das ist extrem unwahrscheinlich, denn die ist ja nicht VSNFD. VSNFD kann nur sein, wo eine Behörde eine Einstufung vorgenommen hat. Hier geht es um materiellen Geheimschutz.
Du schreibst zwar, dass VSNFD die "niedrigsten Stufe von Verschlusssache" ist. Aber eine Zulassung vom BSI zu bekommen für höhere VS-Grade im Bereich der EMail-Kommunikation übers Internet (wozu dieser Anwendungsfall nun mal gehört) ist praktisch nicht möglich. Hier kommen dann noch Sicherheitsanforderungen dazu, die keine Verschlüsselungssoftware erfüllen kann (außer 1-2 HDD-Encrypter). Auf der Liste der zugelassenen Produkte findest du dazu bspw. nix.
Es gibt in Deutschland C++ Users Groups, aber offenbar ist keine von denen ambitioniert genug, ihre Vorträge mal auf Youtube zu packen. Das ist erstaunlich, denn es gibt diverse mehr oder weniger hochkarätige und überregional bekannte C++-Vortragende aus Deutschland, die auf Konferenzen im Ausland sprechen.
Oder vielleicht bin ich nur zu doof zum Suchen :-)
Die Developer-Konferenzen, die es im deutschsprachigen Raum so gibt, scheinen alle eine deutlich kommerziellere Ausrichtung zu haben. Vergleichsweise teure Eintrittspreise, und dann aber Vorträge, die nicht inhaltlich weiterbringen, oder Debattenbeiträge für wichtige Diskussionen liefern, sondern eher so "die Neuigkeiten in C++17" oder so Hype-Porn, wo Leute total begeistert irgendein Wundermittelchen anpreisen, seien es jetzt Kommerz-Tools oder irgendwas mit agile.
Was ich übrigens auch echt furchtbar finde, ist wenn Deutsche im Ausland Grusel-"Englisch" vortragen. Mein Englisch ist auch akzentbehaftet, aber come on, versucht es wenigstens! Bei C++ Russia kriegt man verständlicheres Englisch als bei so einigen deutschen Vortragenden!
Oder so Leute, die dann nach 90% der Zeit merken, dass sie erst 30% der Einleitung durch haben. Übt ihr eure Vorträge vorher nicht zuhause vor dem Spiegel oder Testpublikum!?
Ich bin auch inhaltlich ein bisschen am Verzweifeln mit C++, weil die so überhaupt keine Grenzen zu kennen scheinen bezüglich der Komplexität der Sprache. Ein statisch gegen LLVM gelinktes clang reißt unter Linux die 100 MB Grenze für ein Binary. Das Ausmaß an Cleverness und Hirnschmalz im C++-Compiler heutzutage fühlt sich an, als würde man mit einer KI interagieren. Und der Trend geht weiter in die Richtung, per Ausweitung dessen, was man per constexpr zur Compile-Zeit im Compiler an Code ausführen kann. Auf der anderen Seite scheint mir C++ gerade den Anschluss an Go und Rust zu verlieren. Die Multicore-Elemente der Sprache sind alle Parallelism, nicht Concurrency. So triviale Primitive wie Channels oder effiziente Fan-In- und Fan-Out-Mechanismen fehlen. Man kann sein Problem gar nicht concurrent ausdrücken, man verliert sich stattdessen in Details der Parallelism-Implementation. Wer den Unterschied nicht kennt, kann es sich hier von Rob Pike erklären lassen. In der Praxis sieht man dann entweder Contention-Hotspots, weil jemand eine Queue mit einem Mutex drum baut, oder man sieht Leute mit Atomics herumpfuschen und dann Corner Cases verkacken. Wenn ich das richtig sehe, ist auch C++20 an der Stelle noch unbekleidet. Ist mir ein Rätsel. Haben die alle Angst, dass normale Leute effizienten Code schreiben könnten, und ihr eigener Code dann nicht mehr so besonders aussieht? Oder was!?
Update: Mehrere Leser haben auf die Meeting C++ verwiesen. Deren Videos hatte ich gesehen, aber irgendwie dachte ich, die sei in Budapest gewesen. Muss ich falsch verstanden haben. Die sind insofern gut, dass sie ihre Videos kostenlos bei Youtube hochladen und auch internationale Vortragende einladen, aber irgendwie hat mich das inhaltlich nicht so vom Hocker gehauen. Da war irgendwie kein Vortrag, der so richtig was Neues hatte, fand ich. Alles schon woanders gehört, oder halt so Zusammenfassungs-Kram (wo ich immer finde: überlasst das lieber cppreference.com, außer ihr habt etwas wirklich Tolles).
Update: Leserbrief:
die Münchner C++ User Group hat einen Youtube-Channel:
https://www.youtube.com/channel/UCf3tX0nf8EFIwmgQBH6PIGw
Die Audio-Qualität könnte (deutlich) besser sein, aber inhaltlich reicht die Spannbreite von eher oberflächlichen Lightning-Talks bis hin Vorträgen von Prominenten.
Aus gegebenem Anlass: Für München sucht die Gruppe regelmäßig Locations wo mal mehr als 300 Leute reingehen. Der Andrang zu den Meetings ist oft größer als die Resourcen. Würdest Du da einen Aufruf machen?
In Bochum gibt es die embo++, die auch einen Channel haben:
ImpactNa dann ist ja alles in Butter. Boah du, ein Glück dass wir von Debian und diesem stinkenden APT weg sind!1!! Und diesem entsetzlichen RPM erst!!1!
======
A remote attacker in the position of man-in-the-middle or a malicious
server is able to execute arbitrary code as root when a user installs a
remote package via a specified URL.
Wie? Nein, nein, der Gestank, den ihr gerade in der Nase habt, der ist völlig normal. Das soll so riechen. Das heißt, dass alles wie gewünscht läuft. (Danke, Martina)
Als Gegenstelle zum Spielen eignet sich Youtube, wo man das anschalten kann. Und beim Rumspielen kamen in der Tat schon einige Videos in AV1, als ich das angeschaltet habe.
Der Encoder ist aber noch vergleichsweise unakzeptabel langsam gewesen bei meinen Tests — es gibt andererseits einen Alternativ-Encoder in Rust, der angeblich schneller ist. Ich denke mal, von AV1 werden wir in Zukunft noch mehr hören.
Chrome kann schon länger AV1, aber wer benutzt schon Chrome.
To the best of our knowledge, all systemd-based Linux distributions are vulnerable, but SUSE Linux Enterprise 15, openSUSE Leap 15.0, and Fedora 28 and 29 are not exploitable because their user space is compiled with GCC's -fstack-clash-protection.
Drittens: Die Hersteller der Geräte bauen ihre Software alle ohne -fPIE, ohne -fstack-protector und ohne RELRO. Über Stack Protector und RELRO kann man unter Umständen verhandeln, weil die eine Abwägung beinhalten. Aber PIE sollte echt immer an sein, da gibt es keine Ausreden.
Wer sich jetzt denkt, hey, die haben da bestimmt schwarze Magie angewendet, um diese Messungen durchzuführen! Für den habe ich gute Nachrichten: Es gibt da ein einfaches Tool für und hier gibt es eine knappe Erklärung, was die einzelnen Teile bedeuten.
Update: Hier gibt es eine noch gewartete Version von checksec.sh.
Ich muss also noch irgendwas im Startup-Code machen oder vielleicht in eine ELF-Sektion schreiben, das ich nicht kenne. Ich bin mir aber auch nicht sicher, in welchem Dokument das dokumentiert ist. Langfristig würde ich natürlich gerne gucken, ob ich nicht den ganzen Kram ersetzen kann, denn nur den Support für throw/catch und Stack Unwinding reinzuladen, das kostet im Moment mal eben 100k Binary. Zum Vergleich: Der Rest der dietlibc zusammen ist ~150k. Für das Unwinding muss man unter Linux leider vergleichsweise viel Aufwand treiben, inklusive Parsen von DWARF-Debuginformationen, soviel habe ich schon herausgefunden. Aber 100k Code erscheint mir so vom Bauchgefühl her nicht angemessen.
Update:Zum Vergleich:
-rwxr-xr-x 1 leitner users 74840 Dec 10 22:08 tinyldap
Update: Auflösung: Ich muss im Start-Code __register_frame_info aufrufen.
Hat sich am Ende doch Open Source durchgesetzt im Browsermarkt auf Windows. Wer hätte das gedacht.
Hoffen wir mal, dass Microsofts Präsenz im Chromium-Projekt dazu führt, Googles Dominanz dort zurückzufahren. Google macht mit Chrome gerade genau dasselbe, wofür wir früher Microsoft gehasst haben. Entscheidungen nach Gutsherrenart, Einführen von "Features", anch denen nie jemand gefragt hat, Entscheiden über den Kopf der User hinweg. Ich bin daher seit Jahren Firefox-User, auch auf dem Smartphone. Leider ist der Marktanteil von Firefox gerade unter 10% gefallen — auf dem Desktop. Insgesamt ist es noch weniger, da die Plattformbetreiber alle alles in ihrer Macht stehende tun, um Firefox auf ihren Plattformen zu behindern, damit es ihrem Durchmarsch gegen die User nicht im Wege steht. Leider hat Firefox auch gefühlt jede Gelegenheit genutzt, ihren Usern das Gefühl zu geben, bei ihnen sei das alles dasselbe in Grün. Ich sagen nur: Werbung auf dem Startbildschirm, Tonnen von Tracking-Bullshit, und jetzt auch noch "Pocket".
Und dieser ganze dauernde Ärger verhindert dann, dass man an dem Rest Spaß hat. Mozilla macht ja eine Menge coole Scheiße, so ist das nicht. Rust zum Beispiel ist ein Lichtblick für die ganze Software-Entwicklungs-Branche. Es ist ein Wunder, dass das so weit gekommen ist, wie es ist. Da hätte ich dagegen gewettet, wenn mich jemand gefragt hätte.
Und es kann nicht darüber hinwegtäuschen, dass Firefox es nicht packt, unter Linux Hardware-Video-Playback hinzukriegen. Das verdoppelt mal eben den Stromverbrauch. Kriegt auch Chrome nicht hin unter Linux, übrigens. Aber wisst ihr, wer das hinkriegt? Ja richtig! Edge!
Update: Habt ihr eigentlich schon gehört? QUIC soll HTTP/3 werden! Ein weiteres beschissenes Google-Komplexitäts-Monster, nach dem keiner gefragt hat. Bei Microsoft haben die Leute wenigstens noch gemerkt, dass sie mit Microsoft Network gearbeitet haben und nicht mit dem Internet. Bei Google fahren alle Chrome und benutzen Google-Infrastruktur mit Google-Protokollen in der Google-Cloud, am besten noch über Google Fiber.
a malicious user could use the Kubernetes API server to connect to a backend server to send arbitrary requests, authenticated by the API server's TLS credentials.The API server is the main management entity in Kubernetes. It talks to the distributed storage controller etcd and to kublets, the agents overseeing each node in a cluster of software containers.
Das ist ein Container-Ausbruch-Szenario. Kubernetes ist ja seit Tag 1 Opfer seiner eigenen unnötigen Komplexität. Die Prämisse ist ja eigentlich relativ einfach. Man beschreibt ein System aus mehreren Containern deklarativ und ein Tool baut das dann auf. Ein Tool, um einen Container zu starten, geht in deutlich unter 100k statisches Binary. Ein Tool, um aus einer Beschreibung ein Image zu bauen, und sich die Bestandteile aus dem Internet zu ziehen, ist sagen wir mal 2 MB, da ist dann auch ein fettes OpenSSL mit drin.Aber Kubernetes hat da noch eine monströse Management-Infrastruktur draufgepackt, und alles riesige Go-Binaries natürlich. Ich habe hier gerade mal das aktuelle Kubernetes mit dem aktuellen Go gebaut -- da fallen 1.8 GB Binaries raus. Ja, Gigabytes! Kein Typo! Das ist völlig absurd. Und natürlich geht ohne die Management-Infrastruktur der Rest nicht. Aus meiner Sicht ein Architektur-Fuckup sondergleichen. Auf der anderen Seite tickt Docker ja genau so. Da muss man auch die ganze Zeit einen Docker-Daemon laufen haben. Was die sich dabei wohl gedacht haben? Ich glaube: Der läuft da hauptsächlich aus Branding-Gründen. Damit die Leute den Eindruck haben, Container sei eine hochkomplexe Docker-Tech, keine vergleichsweise einfache Linux-Kernel-Tech.
Man muss dem mal gegenüberhalten, wieviel Aufpreis Intel am oberen Ende für auch nur 10% Performance-Plus verlangt.
Spannend an dem finde ich vor allem den Teil hier:
[Feel free to send this to the FreeBSD lists or whatever to get it fixed. I honestly can't be bothered making a throwaway email and going through the subscription process, nor do I want "TheGrandSchlonging" to appear in FreeBSD commit logs.]TheGrandSchlonging is sein Reddit-Username.Und inhaltlich geht mir das ja ähnlich. Ich ärgere mich jedes Mal, wenn ich irgendwo einen Bug melden will, und die mich erstmal durch irgendeine Account-Prozedur durchtrichtern wollen. Das ist ja nicht so, als bin ich hier der Bittsteller, der was von euch will. Im Gegenteil. Ihr wollt was von mir. Nämlich dass ich euch von dem Bug erzähle, den ich gefunden habe. Also hört mal bitte auf, mir künstliche Barrieren in den Weg zu legen.
Ich hab eh schon vor Jahren völlig aufgehört, nach Bugs in kommerziellen Produkten zu suchen, außer ich werde dafür bezahlt. Und dieser Account-Bullshit und wie die Leute in den Bugtrackern dann teilweise mit ihren Usern umgehen, das ist echt abschreckend und führt nicht zu mehr gemeldeten Bugs.
Aktuelles Beispiel, auch wenn das kein Security-Bug ist, war für mich mpv. mpv ist das Nachfolge-Projekt von mplayer. Mit mplayer oder mpv spiele ich seit gefühlt 20 Jahren meine Video-Dateien ab und hören mir meine mp3-Sammlung unter Linux an. Das Programm ist für mich also eher wichtig. Ich hatte mir ja kürzlich einen Acer Swift 1 gekauft, weil der besonders gute Akkulaufzeit hat und sich besonders gut zum Video-Abspielen eignet dank Hardware-Decoding von H.264, H.265 inklusive 10-Bit Farbtiefe, und VP9. Linux unterstützt das. mpv unterstützt das. Ich spiele also mit mpv ein Video ab und kriege massives Stottern und Frame Dropping. Das habe ich sehr vielen Jahren nicht mehr erlebt, dass ein Player Frames droppt, weil die Performance nicht reicht. Da kommt dann noch so eine von-oben-herab-Fehlermeldung, dass dann wohl das System kacke sei, auf dem man gerade arbeitet, oder zumindest die Treiber, die man verwendet.
Ich habe also vlc probiert, und das flutscht. Da stottert nichts. Stellt sich raus: mpv hat zwar -vo vaapi und -vo xv (dekodiert mit CPU aber macht Farbraumkonvertierung und Skalierung in Hardware) und kann damit stotterfrei dekodieren, aber besteht per Default auf -vo gpu, und der macht irgendwelchen Shader-Kram, der auf Gamer-Hardware prima tut und womöglich auch bessere Qualität liefert (nicht dass ich das hätte beobachten können), und zusätzliche Filter erlaubt, die ich noch nie benutzt habe. Aber auf dem Gemini Lake Atom-Derivat in dem Swift 1 flutscht das halt nicht. Ich habe also einen Bug gefiled, dass sie in der Fehlermeldung möglicherweise auf -vo vaapi hinweisen könnten statt dem Benutzer die am wenigsten hilfreiche Meldung aller Zeiten zu geben ("du hast wohl Scheiß Hardware").
Es gibt auch ein mpv-Wiki, wo drinsteht, dass niemand jemals etwas anderes also -vo gpu nehmen soll, weil das so geil ist, und andere Alternativen werden dort auch gar nicht erwähnt.
Nun kann mir das ja eigentlich alles egal sein. Ich hab ja die Lösung gefunden, nämlich -vo vaapi (damit spielt das Gerät auf Akku über 10h am Stück Video ab und hat dabei eine CPU-Auslastung von unter 5%). Aber das Projekt liegt mir halt am Herzen. Schreiben die zurück: Deine Hardware ist kacke, nein wir ändern das nicht, und wenn wir da ranschreiben, dass vaapi weniger Strom verbraucht als gpu, dann benutzt ja niemand jemals gpu.
Ich kommentierte dann noch, dass wenn sie das nicht fixen, dass die Kunden dann halt zu vlc abwandern, wenn mpv "zu lahm" ist, was es ja nicht wirklich ist, aber es sieht halt so aus. Und sie sollen mal lieber ehrlich sein mit ihren Kunden. Daraufhin meinte dann jemand, ich könne ja gehen, wenn mir mpv nicht gefällt, und machte den Bug zu.
Liebe Leser, wenn ihr jemals in der Situation seit, einen Bugtracker zu pflegen, dann macht lieber gar nichts als euch so zu verhalten. User verprellen ist so das schlechteste, was man tun kann. Fragt euch mal selbst, ob ihr einem Projekt helfen wollen würdet, das euch beim ersten Versuch so den Stinkefinger ins Gesicht hält.
Ich erwähne das, weil FreeBSD so das Gegenteil davon ist. FreeBSD, PostgreSQL und LLVM sind Projekte, die mit Bugreports professionell, zeitnah und sauber umgehen, und wenig überraschend sind die auch echt erfolgreich am Ende. Projekte wie gcc, bei denen auf dem Bugtracker häufig eher User-Abwehr statt Bug-Beseitigung betrieben wird, geraten halt ins Hintertreffen. Und mpv, wenn es sich so verhält, wird als Privatprojekt von irgendeinem Frickel-Nerd in seinem Keller enden, das niemand kennt und niemand benutzt. Schade eigentlich, denn die verspielen da über Jahre aufgebautes Karma.
Update: Ein Einsender kommentiert:
es wird deutlich darauf lhingewiesen (https://www.freebsd.org/security/), dass security-related Krams per Mail an secteam@ berichtet werden soll/kann. Der Link steht auch im Default-motd, sollte also jeder FreeBSD-User mal gesehen haben :)
Oh das wusste ich nicht. Dann gibt es in der Tat nicht so viele Ausreden, den Bug auf reddit zu posten statt den FreeBSDlern zu mailen.
Update: mpv hat den Bug nicht nur geschlossen sondern als "too heated" gelockt, womit weitere Kommentare von Externen nicht mehr erlaubt sind. Gute Arbeit, Jungs. So strahlt man Souveränität aus.
Update: Haha, geil, jetzt werde ich da auch noch als Lügner bezeichnet. Natürlich schön nachdem man mir die Kommentiermöglichkeit weggenommen hat. Tolles Projekt, dieses mpv. Da will man doch mithelfen!1!!
Aber ein Detail noch: In der Zwischenzeit hat sich gezeigt, dass auch -vo gpu flutschen kann, wenn man bloß auch noch --hwdec=auto macht. Ja, ich bin genau so belustigt wie ihr. Die haben eine auto-Option für den Hardware-Decoder und machen die dann nicht an. Der Lacher ist ja, dass -vo xv auch Software-Decoding macht und bei weitem schnell genug ist. Wir wissen also zwei Dinge jetzt: Die CPU ist schnell genug für Software-Decoding, und das OpenGL ist schnell genug fürs Rendering. Aber in Kombination verkackt mpv es. Ich hätte ihnen ja beim Debuggen geholfen. Aber ich helfe nur Projekten, die ihren Usern Menschenwürde zugestehen.
Meine Vermutung ist, dass die Hersteller noch nicht mitgekriegt haben, dass man ihre Firmware extrahieren und reverse engineeren kann.
Ich sage gleich mal voraus, dass die Firmware ab jetzt verschlüsselt kommt, damit sie kein Geld ausgeben müssen, um die Software in der Firmware ordentlich zu machen.
Update: Christian, der von Crypto mehr versteht als ich, erklärt:
Bitlocker macht OPAL, zumindest die Samsungs die ich seit eh und jeh empfehle, unterstützen DEK-Ranges. Das tun Sie auch hier. Damit ist die Sache safe. Im ATA-Security Modus das Master Passwort mit read-Recht so umzusetzen ist sehr ungünstig aber fixbar, wer OPAL nutzt ist davon aber auch nicht betroffen. [...]
Die DEKs liegen mit dem „Passwort“ (genauer in dem Fall TPM Key) verschlüsselt vor. Völlig normales Vorgehen, keine Hintertür, kein Incident. Fig. 8 hilft Dir weiter.
Das Paper ist in seiner Argumentation und Darstellung undurchsichtig und Verzeihung – unsauber.
Da jetzt pauschale Ableitungen wie am Beginn des Papers draus zu postulieren ist Blödsinn.
Zur Erläuterung: OPAL ist der Standard für SSD-Verschlüsselung. DEK ist der Schlüssel, mit dem die Daten verschlüsselt sind. Da nimmt man einen separaten Schlüssel und nicht einfach den Hash des Passworts, damit man das Passwort ändern kann, ohne alle Daten zu verlieren. Die Grundlagen erklärt das Arch-Linux Wiki, das m.E. zum Weltkulturerbe zählen sollte, soviel hilfreiche Dinge, wie da immer wieder drin stehen.
Update: Ich habe mich nochmal mit Kollegen unterhalten und die finden, dass doch das Paper Recht hatte und nicht Christian. Das Paper geht darum, dass jemand deine Platte klaut und du nicht kooperierst. Die Anforderung ist, dass das Laufwerk die Daten mit einem zufälligen Key verschlüsselt, der nicht auslesbar ist, und den sonst keiner kennt. Das lässt sich natürlich auch nicht prüfen, ob nicht alle Laufwerke von Baureihe XY statisch immer denselben Key verwenden oder so. Aber an sich haben die Laufwerke alle einen Zufallszahlengenerator (der auch häufig Müll ist, aber das ist ein anderes Thema). Man schließt die Platte jetzt mit einem Passwort auf. Die Platte kann aber nicht einfach den Schlüssel aus dem Passwort ableiten, weil man sonst das Passwort nicht ändern könnte, ohne alle Daten zu verlieren. Idealerweise will man daher aus dem Passwort einen Zwischenschlüssel ableiten, und mit dem den eigentlichen Schlüssel verschlüsselt haben. Das Paper hat jetzt rausgefunden, dass das bei den meisten Laufwerken nicht so ist, sondern dass die halt Code haben, der guckt, ob das Passwort stimmt, und dann den Key nehmen, der eh rumliegt. Dann kann ein Angreifer kommen und die Firmware manipulieren, dass der jedes Passwort reinlässt.
New hotness: Micro-Apps. Weil dann, äh, *raschel* *knister* dann kümmert sich jedes Team um seine eigenen Micro-Apps und *umblätter* … mehr steht hier nicht.
Na DAS wird bestimmt GROSSARTIG! Wenn jedes Team seinen eigenen Scheiß deployed und die müssen dann miteinander Nachrichten austauschen. Was kann da schon schiefgehen. Die sollen auch noch alle ihre eigenen Datenmodelle pflegen. Hey, wenn es eine funktionierende, skalierende Lösung für reibungsarme Zusammenarbeit gibt, dann ja wohl "jeder macht seinen eigenen Scheiß"!1!!
Oh Mann ey. Die müssen uns wohl für echt blöde halten. Die "Lösungen" aus den Hipster-Firmen ist jetzt seit Jahren "wir brauchen mehr Agilität". Funktioniert nicht? Dann war es noch nicht genug Agilität!!1! Und raus kommen dann so super-agile schlanke "Lösungen" wir die Facebook-App. Oh warte, nein, nicht die von Facebook. Die von Twitter! Oh, nee, warte, sagte ich Twitter? Ist auch zu bloatig. Ich meine Snapchat!!1!
Das ist bisher ein einziges Horrorkabinett, was aus diesem ganzen Agilitätsgepfusche rausgekommen ist. Ein Sediment aus unzureichenden Quick Hacks, die dann aufgegeben wurden, als sie "gut genug" waren. Und dann Workarounds auf der Ebene darüber, die um die Warzen der Schnellschüsse darunter herumnavigieren. Und am Ende braucht es mindestens täglich Updates und alle wundern sich, wieso 1 GB Trafficvolumen auf dem Handy so schnell alle ist.
Als ich meine erste Linux-Distribution gezogen habe, musste ich über einen Tag lang an den 12 oder so Disketten-Images downloaden. Heute hat eine Spiegel-Online-Homepage schon mehr Daten als damals mein Linux-Kernel.
Und was passiert? Wir müssen noch agiler werden!!1! Ja super. Rumhampeln war schon immer die Gewinner-Strategie im Leben.
The new Code of Conduct explicitly says discrimination and harassment on the basis of sex or gender is not allowed. One Linux Foundation Technical Advisory Board member who did not sign off on the patch is Ted Tso, who is a rape apologistMit "Beweis"-Link zu geekfeminism. Ja nee klar. Ted Ts'o ist übrigens der hier. Der Hauptmaintainer von ext2, ext3 und ext4. Leiter des Kerberos-Teams am MIT. Preisträger des FSF Award. Und (ich hab den mal persönlich getroffen) einer der freundlichsten und liebenswürdigen Menschen, die man sich nur vorstellen kann. Rape Apologist, my ass. Wie sieht denn die Beweislage aus?Theodore Ts'o made statements (full email archived here) in which he argued that categorising statutory rape, child abuse, intimate partner abuse or rape without physical force with stranger rape of adult women with physical force is “hyperbolic and misleading”Heräsie!! Das sehen nur Perverse so! Perverse wie … das bürgerliche Gesetzbuch und der US Code of Law. Hier ist das Beweisstück von einer Mailingliste:Please note, I am not diminishing what rape is, and or any particular person's experience. However, I *am* challenging the use of statistics that may be hyperbolic and misleadingLYNCHT IHN!!1!
Ich habe mehrere Mails gekriegt, wieso ich mich denn so habe, denen den kleinen Finger hinzuhalten.
Das ist der Grund.
Ist Blut im Wasser, kommen die Haie.
Update: Wisst ihr, wass Sage Sharp beruflich macht? Kommt ihr NIE drauf!
Update: Oh und: Valerie Aurora macht auch hauptberuflich Diversity.
Na egal. Mache ich sie halt jetzt auf. :-)
Erster Eintrag: Dieser wohlerzogene Golem-Forist:
Fefe hat keine Ahnung, und ist ohnehin seit langem der Ober-Bully der deutschen Bloggerszene, und wenn du dich mit Androzentrismus und der neuen Rechten ungerechtfertigt in Verbindunggebracht fühlst, dann ist es etwas ungeschickt, einen der lautesten und asozialsten Wortgeber der deutschen Maskulistenszene, einem besonders widerlichen Teil der neuen rechten Bewegungen, als Quelle anzuführen.Wie und meinen offensichtlichen Antisemitismus findet er nicht erwähneswert!? Ich bin enttäuscht!
Geht weiter unten noch weiter. Gefragt, ob Antikapitalismus, Antirassismus, Eintreten für gerechtere Verteilung der Vermögen und Kampf gegen Massenüberwachung mich nicht eher zu einem Linken machen, kommt diese bedenkenswerte Beobachtung:
Rechter Antikapitalismus ist halt gerade en vogue. Und wenn er dabei noch so viele richtige Ideefragmente hätte, macht das die asozial-reaktionäre Tendenz seiner unsäglichen Tiraden gegen wesentliche zivilisatorische Errungenschaften im Umgang miteinander, und Ansätze, diese weiter zu verbessern, keinen Millimeter besser.Dem ist halt der zwischenmenschliche Umgang besonders wichtig! Das erkennt man auch an Worten wie *hochscroll* "Ober-Bully" und "asozialster Wortgeber der deutschen Maskulistenszene". Wenn ich von solchen Leuten ernst genommen werden möchte, muss ich einfach auch auf dem Niveau agieren! Ganz einfach!
Update: Seid ihr eigentich auch so froh, dass Hate Speech-Bekämpfung bei uns in Deutschland jetzt Chefsache ist? Endlich nimmt das mal jemand ernst!
Update: Hah, ein anderer Einsender schreibt:
Nunja, wieso ich mich eingentlich nochmal melde, ist dass einige meiner Golem Posts (mit nahezu dem gleichen Inhalt der Mail an dich) verschwunden sind, und heute lese in in der Inbox:
Re: RIP Linux
Von [zensiert] (Golem.de) 20.09.18 09:45
An: [zensiert]Hallo [zensiert],
da der Begriff SWJ derzeit vor allem als Provokation benutzt wird,
möchten wir den auch in unserem Forum nicht zulassen, wenn er
entsprechend benutzt wird. Wir wollen damit keine Meinungen
unterdrücken, es geht lediglich darum, dass niemand diskriminiert wird
und sachlich-faire Diskussionen möglich sind. Um Missverständnisse zu
vermeiden, bitte ich auch in diesem Fall um Verständnis.Mit freundlichen Grüßen,
[zensiert] (Golem.de)
Oh ach soooo! Es geht hier um sachlich-faire Diskussionen! Daher muss Hate-Speech wie "SJW" entfernt werden! Pro-Tipp: Beschimpf die Gegenseite lieber als "Ober-Bully" oder "asozialster Wortgeber der deutschen Maskulistenszene". Das drückt Respekt und Hochachtung aus und dient dem positiven Gesprächsverlauf.
Update: Ein Leser hat die Kategorie wiedergefunden. Sie hieß "Subject: Du Nazifreund"! (Danke, Julian)
Torvalds’s decision to step aside came after The New Yorker asked him a series of questions about his conduct for a story on complaints about his abusive behavior discouraging women from working as Linux-kernel programmers.Wow, geil. Nein er hat sich nicht Frauen gegenüber verhalten, wie die hier durch geschickten Satzbau implizieren wollen. Und sie haben auch keine Frauen gefunden, die wegen Linus nicht bei Linux mitmachen wollten. 10% der Linux-Kontributoren sind Frauen. Für den Laien klingt das wie eine furchtbar schlechte Quote. An meinem Informatik-Uni-Jahrgang damals war der Frauenanteil noch deutlich geringer.Und wie weisen sie den Abuse nach? Sie fragen eine Professorin, die das hier zu Protokoll gibt:
“Everyone in tech knows about it, but Linus gets a pass,” Megan Squire, a computer-science professor at Elon University, told me, referring to Torvalds’s abusive behavior. “He’s built up this cult of personality, this cult of importance.”OK, und? Wo kommen die Frauen ins Spiel? Hier!For a research project, Squire used e-mails from Torvalds to train a computer to recognize insults. According to Squire’s tabulations, more than a thousand of the twenty-one thousand e-mails Torvalds sent in a four-year period used the word “crap.”Wenn ihr noch auf den frauenfeindlichen Teil wartet, seid ihr nicht alleine.“Slut,” “bitch,” and “bastard” were employed much less frequently during that period.Öhm…!?Squire told me that she found few examples of gender bias.Well, …!?!?!? Wo bleibt die Story?“He is an equal-opportunity abuser,” she said. Squire added, though, that for non-male programmers the hostility and public humiliation is more isolating.Oooooh, verstehe! Das ist der sagenumwobene strukturelle Sexismus! Post hoc ergo propter hoc! Wir sehen weniger als 100% Frauen, also muss dieser fiese Torvalds die alle weggescheucht haben!1!!Oh Mann.
Update: Weiter unten geht es genau so weiter. Sarah Sharp wird als Kronzeugin herangeholt, aber kann natürlich auch keinen einzigen Fall vorzeigen, wo Linus eine Frau weggemobbt hat. Stattdessen wieder geschickter Satzbau ala "I received a lot of harassment because of it". Von wem? Spielt keine Rolle! Ist ein Artikel über Linus, ein bisschen Hundekacke wird schon kleben bleiben!
Und dann natürlich Valerie Aurora, bei deren Statement offensichtlich der Zensor pinkeln war:
Valerie Aurora, a former Linux-kernel contributor, told me that a decade of working in the Linux community convinced her that she could not rise in its hierarchy as a woman.
Community? Und dann "rise through the hierarchy"? Da hat ihr wohl die Ada Initiative die falschen Talking Points mitgegeben! Das war das angeblich Argument in Firmen, nicht in der Community! Die Idee bei der Community ist, dass du dich einbringst, nicht dass du "aufsteigst". WTF? Was kommt als nächstes? "Mein Community-Gehalt ist nicht hochgegangen"?! Das Gender Pay Gap bei Freiwilligen in der Community? Au weia.
Update: Sarah Sharp war hier auch schonmal im Blog.
(First they came for "master/slave replication", and I did not speak up because I was not a DBA.)Ich krieg weiche Knie :)
Erzählt mir also nicht, es gäbe da unüberwindliche Barrieren und MLP-Fans würden weggemobbt. (Danke, Rolf)
Ich für meinen Teil kann kaum erwarten, wie viel besser die Codequalität wird, wenn jetzt endlich auch die ganzen blauhaarigen Schneeflocken und Einhorn-Bronies einchecken können, die bisher von Linus weggeekelt wurden. Das wird bestimmt ein FEST!Frage 1: Steht da, dass blauhaarige Schneeflocken und Einhorn-Bronies nicht programmieren können?
Frage 2: Steht da, dass Linus Schneeflocken und Bronies nicht mag?
Frage 3: Steht da, dass der Autor Schneeflocken oder Bronies nicht mag?
Frage 4: Ist da vielleicht verstecker Sarkasmus, der die Leser irregeführt hat?
(Spoiler: Nein, nein, nein, und der Sarkasmus ist nicht versteckt und hat niemanden irregeführt)
Ich bin einigermaßen entsetzt, wie viele Zuschriften völlig unreflektiert davon ausgehen, dass Bronies nicht programmieren können, und ich sie hier bloßstellen würde. Das Gegenteil ist der Fall. Ich kenne überhaupt keine Bronies ohne Programmiererfahrung. Wo kommt eure Homo- und Transphobie her?! Und wieso projiziert ihr die ausgerechnet auf mich? Unfassbar. Ich dachte, diese Zeiten seien vorbei.
Was steht da wirklich? Da steht, dass es eine Teilmenge an Schneeflocken und Bronies gibt, die sich von Linus weggeekelt fühlten, und die jetzt Code einreichen könnten, und das wird bestimmt ganz schlimm. Das ist keine Aussage über die Codequalität von Bronies, sondern das eine humoristische Anspielung darauf, dass mir unter denen, die sich marginalisiert fühlen und lieber anderen Vorwürfe machen als selbst am positiven Ausgang ihrer Gesamtsituation zu arbeiten, dass unter denen blauhaarige Schneeflocken und Einhorn-Bronies stark überrepräsentiert erscheinen.
Und, um das nochmal explizit anzusagen. In der Geschichte von Linux ist NOCH NIE jemandes Code nicht genommen worden, weil der Einsender $IRGENDWAS war. Entscheidend ist der Code. Wenn den ein Hund einreicht, aber der Code gut ist, wird er genommen. Genaugenommen ist Code im Internet einsenden DIE EINE GELEGENHEIT im Leben, wo die Person des Einreichers keine Rolle spielt. Linus kann deine Haarfarbe gar nicht sehen, wenn du was einreichst. Ich weiß aus 1. Hand, dass im Linux-Kernel Code von blauhaarigen Schneeflocken eingeflossen ist. Warum auch nicht? Völlig absurd, da auf die Haarfarbe zu gucken.
So und wer bleibt jetzt übrig, der Code in den Kernel reinbrechstangen will, aber an Linus nicht vorbeigekommen ist? Na die, deren Code nicht gut genug war. Und DAS ist ein Grund zur Sorge.
Haben glaube ich auch alle auf Anhieb richtig verstanden. Aber die beste Reaktion auf absichtliches Missverstehen zur besseren Als-Nazi-Beschimpfung ist m.E., das nochmal zu erklären. Und nochmal. Und nochmal, wenn es sein muss. Genau was Linus immer getan hat, bis ihm nach Monaten des abusive behavior irgendwann die Hutschnut platzt.
So und jetzt hört mal bitte mit eurer Homo- und Transphobie gegenüber blauhaarigen Schneeflocken und Bronies auf. Ist ja widerlich. Echt mal. Ekelhaft, sowas.
Ein Beispiel dafür war eine Spielefirma, die so im Text Anspielungen und Witzchen vermeiden kann, die in belieferten Kulturkreisen keiner versteht. Das finde ich ein gutes Argument allerdings noch nicht durchschlagend, weil es sich nicht so gut verallgemeinern lässt, z.B. auf VW-Fließbandarbeiter oder Burger-Flipper bei McDonald's oder einen SAP-Programmierer.
Ein anderer Einsender ist Lehrer und wies darauf hin, dass die unter partiell ähnlichen Annahmen eingeführte "Kinder nicht korrigieren, Lesenlernen nach Aussprache"-Methode wohl voll in die Hose ging.
Ein dritter Einsender zitierte einige bekannte Fälle wie den Seifespender, der nur bei weißer Haut Seife spendet.
Ich persönlich betrachte Kritik an meiner Arbeit nicht als negativ, im Gegenteil. Von Lob lernt man nichts. Mein Ziel ist, zu lernen. Daher ist ehrliche Kritik das viel größere Lob, besonders wenn man ihr anmerkt, dass derjenige sich mit meiner Arbeit auseinandergesetzt hat, als irgendein rituelles Hohl-Lob. Aus meiner Sicht machen sich Leute, die bei Kritik nur darüber nachdenken, wie ungerecht sie behandelt werden, ihre Wachstumsmöglichkeiten kaputt, und ich würde alleine deshalb lieber jemand kritikfähigen einstellen. Nicht nur ihre eigenen Wachstumschancen, die des ganzen Teams.
Ich habe einige so Zuckerwatte-Teams erlebt. Eine häufige Gemeinsamkeit ist, dass die aus Furcht vor Kritik auch externe Vergleiche scheuen, und dann in einer Blase vor sich hin arbeiten, sich gar nicht dessen bewusst seiend, dass sich die Welt seit ihren Berufanfangs weitergedreht hat, und es inzwischen bessere Verfahren gibt.
Insofern wäre mein auszuräumendes Problem auch nicht damit, ob es da jetzt Diversität und Inklusion gibt, sondern ob man sich radikale Kritik und Kritikfähigkeit aufrecht erhalten hat. Und das sehe ich halt bei keiner der üblichen Inklusions-Initiativen gegeben, eher im Gegenteil.
Um mal das geflügelte Wort zu zitieren: Klar, kann man so machen. Wird dann halt Kacke.
Update: Ich finde es an der Stelle übrigens brandgefährlich, Leute zur Selbstverwirklichung Code beisteuern zu lassen. Wir reden hier vom Linux-Kernel, der ist in Telefonen drin, mit denen man im Notfall zuverlässig die Feuerwehr rufen können muss. Der ist in Steuerungen für Kraftwerke drin, und in selbstfahrenden Autos. Da hängen Menschenleben von ab. Nein, da darfst du nicht an die Wand pinkeln, weil das toll in deinem Lebenslauf aussehen würde. Man hätte euch auch nicht bei der Brücke in Genua mitfrickeln lassen, weil ihr ein marginalisiertes Einhorn seid, mit dem alle Mitleid haben. Habt mal ein bisschen Respekt vor Code! Wir kriegen es schon mit ausgewiesenen und erfahrenen Experten nicht zuverlässig hin, sauberen und sicheren Code zu schreiben! Das ist kein Kunstwerk, das ist ein Stück Infrastruktur, von dem wir hier reden!
Update: Übrigens halte ich es für unerlässlich, dass wir uns einigen, was wir meinen, wenn wir Linus kritisieren. Hier ist sein glaube ich übelster Ausfall. Das ist keine öffentliche Niedermachung einer spezifischen Person. Die Person ist nicht genannt (und ihm wohl auch nicht bekannt). Es geht um Verhalten, nicht die Person. Ich finde diese Aussage von Linus auch nicht akzeptabel und werde sie nicht verteidigen. Aber das ist eben nicht "der Bronie da drüben ist ein Idiot und darf nicht einchecken" sondern "OMG wer schreibt denn bitte SOLCHEN CODE!?!?". Das ist nicht "Soldat Müller ist ein Mörder" sondern eher "Soldaten sind Mörder". Immer noch inakzeptabel, allerdings hat das eine Vorgeschichte. Wer die nicht kennt, hält bitte mal gepflegt die Klappe. Linus entgleiste in der Vergangenheit nie jemandem direkt ins Gesicht, sondern er fährt eine mehr oder weniger kontrollierte Eskalationsstrategie gegen Leute, die wieder und wieder ankommen und ihm Mist einreichen. Wer das nicht gut findet, soll mir mal bitte sagen, wie Linus sonst reagieren soll. Wir reden hier auch von Leuten, die dafür bezahlt werden, Code für Linux zu schreiben. In diesem Fall von Redhat, in dem anderen bekannten Fall waren das die Security-Leute von Google, die lauter Patches eingereicht haben, die den Kernel platzen lassen, wenn sie Speicherkorruption diagnostizieren. Ich bin in der Debatte auf Seiten der Google-Leute, aber ich bin nicht der Kernel-Maintainer. Wenn Linus das nicht mag, dann ist das seine Entscheidung. Google kann ja einen Fork betreiben (tun sie ja auch). Google wollte aber die Wartung für ihren Kram dem Upstream-Kernel überhelfen. Und dann müssen sie sich halt auch an die Regeln dort halten. Ganz einfach. Aber das Problem ist halt, wenn die dafür bezahlt werden, das zu tun, dass die dann auch nicht weggehen, wenn Linus seine normale Strategie fährt und sie kritisiert. Die haben von ihrem Boss halt andere Vorgaben und tun, wofür sie bezahlt werden. Ich sehe da keinen guten Ausweg. Linus könnte öffentlich Google anpinkeln. Oder erkönnte Mails von den Leuten filtern. Oder sie ignorieren. Ist alles noch schlechter, finde ich. Als mal Butter bei die Fische. Was hätte Linus besser tun sollen?
Update: Ein Einsender schlägt den Lehrerberuf als Beipiel für sinnvolle Diversität vor. Wenn die Schüler alle homogene Hintergründe haben, es es besser für sie, einem Lehrerkollegium mit diversen Hintergründen exponiert zu sein. das finde ich ein gutes Argument, aber es verallgemeinert sich wieder nur schlecht.
Und Linus nimmt sich eine Auszeit. Klingt sogar so, als begäbe er sich in psychologische Behandlung:
This is more like the time I got out of kernel development for a while
because I needed to write a little tool called "git". I need to take
a break to get help on how to behave differently and fix some issues
in my tooling and workflow.Sieht aus, als hätten die SJW gewonnen. Thor stehe uns bei.
Ich für meinen Teil kann kaum erwarten, wie viel besser die Codequalität wird, wenn jetzt endlich auch die ganzen blauhaarigen Schneeflocken und Einhorn-Bronies einchecken können, die bisher von Linus weggeekelt wurden. Das wird bestimmt ein FEST!
Mein Gefühl dazu ist, dass IKE sich zu TLS verhält, wie S/MIME sich zu PGP verhält.
Insofern war ich ganz froh, dass jemand an was neuem arbeitet. Das ist im Moment ein Linux-Alleingang, dafür ist es AFAIK im Standardkernel angekommen. Ich habe damit noch nicht herumgespielt, aber beim oberflächlichen gucken her gingen da erstmal keine Alarmlampen an.
Aber hey, es gibt da Bewegung: AMD hat anscheinend einen Weg gefunden, wie sie die Zen-Architektur nach China verkaufen konnten, ohne ihre (bestimmt knallharten Knebel-)Verträge mit Intel zu brechen. Jedenfalls gibt es jetzt in China "Dhyana"-Prozessoren, die so nah an EPYC dran sind, dass der Linux-Kernel praktisch ohne Änderungen direkt auf ihnen läuft. Einziger Nachteil (für den Rest der Welt): Die Chips dürfen nur in China verkauft werden. Aber hey, das könnte heißen, dass Intel aus dem Markt so gut wie raus ist. Je nach dem wie lange dieser Wirtschaftskrieg sich hinzieht.
Bei Security hätte ich an ARMs Stelle auch lieber die Klappe gehalten, nachdem Trustzone so ein Totalschaden war.
Für mich sieht das aus wie dieser Spruch: Erst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich, dann gewinnst du. Nächster Schritt dann wohl: RISC-V gewinnt.
Update: Und weg ist die Site!
Jetzt kann ich endlich mit dem Kernel-TLS herumexperimentieren, den sie frisch eingebaut haben. Das ist m.E. ein zentraler Baustein, um ordentlich TLS-Privilege-Separation zu implementieren, ohne dabei krass Performance zu verlieren. Könnte sogar besser werden, die Performance.
So, bleibt nur noch ein Problem. Wieso das olle Chromebook einen Suspend wie ein Ausschalten behandelt. Das nervt schon ziemlich. Das ist die einzige PC-Hardware hier im Haus, auf der ich Suspend wirklich mal benutzt habe.
Der Ansatz ist bei Itanium aus mehreren Gründen gescheitert. Erstens waren die Compiler nicht so weit und haben sehr ineffizienten Code erzeugt. Zweitens hat damals der Umschwung von Pentium 4 (das muss schnell sein, scheiß auf Abwärme!!1!) hin zu dem heutigen Ansatz begonnen, dass man möglichst auf Stromsparen und Effizienz achten soll und die Performance kommt dann schon von alleine. EPIC war in der Praxis eine Heiz-Architektur.
Nun sehe ich keinen Grund, wieso explizites Scheduling energie-ineffizienter sein sollte als spekulative Ausführung in regulären CPUs. Microsoft hat keine Hardware sondern lässt das im Moment in einem FPGA laufen, aber sie sind wohl in Gesprächen mit Qualcomm und haben Windows und Linux darauf portiert (und .NET ist in Arbeit).
Sie haben dafür sowohl für Visual Studio als auch für LLVM ein Backend für ihre Architektur gehackt. Ich bin ziemlich beeindruckt. Das ist harte Arbeit und alles andere als ein Selbstläufer.
Ich habe ja vor inzwischen vielen Jahren eine Abstraktionsschicht über diverse Netzwerk-Event-APIs der verschiedenen Plattformen geschrieben, und darauf meinen Webserver gatling aufgebaut. Seit dem hat sich im Internet einiges verschoben. Web ohne TLS spricht niemand mehr, also habe ich TLS nachgerüstet. Für Web mit TLS ist aber das Skalierungsproblem ein ganz anderes. Da geht es nicht mehr darum, dass jemand viele Verbindungen aufbaut und dein Server damit nicht klarkommt, sondern es geht darum, dass jemand viele TLS-Handshakes lostritt und dein Server die ganze Zeit mit 100% CPU läuft.
Seit dem hat sich auch eine andere Sache verändert: CPUs mit nur einem Core gibt es nicht mehr. Es liegt also auf der Hand, dass ich mal das Modell von gatling und der Abstraktionsschicht ändern sollte, damit es sich auf mehrere Cores verteilen lässt. Das ist leider kein Selbstläufer, weil die unterliegenden APIs teilweise nervige Probleme haben. So gibt es einmal die fundamentale Frage, ob man edge triggered oder level triggered arbeiten soll. Level Triggering ist, was poll macht. Wenn du nach Deskriptor 3 fragst, und 3 ist lesbar, und du tust nichts mit ihm sondern rufst wieder poll auf und fragst nach Deskriptor 3, dann sagt dir poll wieder, dass er lesbar ist. epoll und kqueue arbeiten genau so, lassen sich aber umschalten. Edge Triggering heißt, dass das API dir nur einmal Bescheid sagt, dass ein Deskriptor lesbar ist. So funktioniert der Vorläufer von epoll, SIGIO, den meine Abstraktion unterstützt. Das verkompliziert aber das Programmiermodell massiv, weil ich jetzt darüber Buch führen muss, welche Deskriptoren lesbar sind und welche nicht. Dafür hat es aber den großen Vorteil, dass multithreading sozusagen von alleine geht.
Nehmen wir mal an, du hast vier Threads, und alle rufen epoll auf. Deskriptor 3 wird lesbar. Dann kommen alle Threads zurück und melden das. Das ist natürlich Unsinn, weil nur einer zum Zuge kommt und die anderen sinnlos Strom verbraucht haben.
Daher macht man das entweder so, dass nur ein Thread epoll aufruft und eine Datenstruktur befüllt, die dann von Worker Threads abgearbeitet wird. Oder man macht es so, dass jeder Thread einen eigenen Pool aus disjunkten Verbindungen verwaltet und die jeweils mit einem eigenen epoll bearbeitet. Die bessere Skalierbarkeit hat auf jeden Fall Variante 2, aber dann sollte man keine Threads sondern Prozesse nehmen.
gatling hat Fälle, z.B. CGI oder Proxy-Modus, bei denen mehr als ein Deskriptor zu einer Verbindung gehört. Das naive aufteilen der Deskriptoren auf Pools funktioniert also nicht, denn zusammengehörende Verbindungen müssen auch im selben Pool sein. Oder man baut ein API, um nachträglich Deskriptoren hin- und herzuschieben. Das wäre auch die bessere Lastverteilung gut, aber zieht einen Rattenschwanz an Komplexität nach sich. Ist daher aus meiner Sicht gerade erstmal unattraktiv.
Ich habe mich daher entschieden, lieber jeweils nur einen Thread zu haben, der epoll macht (oder halt kqueue, whatever), und der befüllt eine Datenstruktur, und aus der bedienen sich dann die Worker-Threads. Die Threads handeln das on the fly untereinander aus, wer gerade für Event-Abholen zuständig ist, und wer auf die Datenstruktur wartet. Damit das API nach außen einfach bleibt.
Das sieht ganz gut aus und scheint auch schön zu flutschen und vor allem ist das API viel einfacher als was ich vorher hatte. Aber ich kam ins Grübeln. Wenn ich hier schon einen neuen Webserver mache, dann soll der aber auch nicht nur TLS machen, sondern TLS mit Privilege Separation. Wenn jemandem ein Angriff auf den Webserver gelingt, möchte ich gerne möglichst minimieren, was er damit anstellen kann. In erster Näherung stelle ich mir vor, dass der Private Key von dem Server in einem separaten Prozess liegt (und ich per seccomp-filter o.ä. verhindere, dass man da ptrace o.ä. machen kann). Aber je mehr ich darüber nachdenke, desto weniger gangbar sieht das aus. Das erste Problem ist, und dafür kann TLS jetzt nichts, wenn ich den Handshake-Teil in einen Prozess tue und nur die Session Keys in den anderen Teil rüberreiche, dann hat ein Angreifer immer noch alle Session Keys im Zugriff. Das ist immer noch ziemlich schlimm. Gut, dank Forward Secrecy ist es kein Super-GAU, aber gut wäre es nicht.
Ein möglicher Ausweg wäre, dass man das gesamte TLS auslagert, und sozusagen durch einen TLS-Proxy-Prozess kommuniziert. Das riecht erstmal nach einem prohibitiv teuren Performance-Nachteil. Und gewonnen hätte man damit auch nicht viel, denn ein Angreifer könnte trotzdem allen Verkehr aller anderen Leute sehen und ihnen Müll senden, um sie anzugreifen, er könnte bloß nicht den schon gelaufenen Teil der Verbindung entschlüsseln. Ich glaube, das wäre die Kosten nicht wert.
Aber was, wenn man das TLS in den Kernel schieben kann. Linux hat seit kurzem ein API für Kernel-TLS. Da gibt man dem Kernel per setsockopt den Schlüssel und dann kann man auf dem Socket ganz normal Daten rausschreiben. Das klingt sehr attraktiv, denn den setsockopt könnte der TLS-Handshake-Prozess machen und dann den Socket rüberreichen zu dem Web-Prozess. Nachteil: Der Kernel-Support ist rudimentär und kann nur Daten rausschreiben. Kann nicht lesen, und kann keine Kontrollnachrichten schicken. Das muss man über ein krudes Spezial-API machen. Das müsste man dann zurück an den TLS-Handshake-Prozess delegieren. Gut, wäre denkbar. Schlimmer noch: Lesen kann der Kernel-TLS auch nicht. Das ist schon eher hinderlich.
OK, nehmen wir an, ich habe meinen Webserver aufgeteilt. Ein Prozess macht HTTP, einer macht TLS-Handshake. TLS hat aus Performance-Gründen ein Feature namens Session Resumption. Der Server behält die Krypto-Parameter für Verbindungen eine Weile vorrätig, und gibt dem Client ein Cookie. Wenn derselbe Client wieder kommt, kann er einfach den Cookie vorzeigen, und der Server findet dann die Krypto-Parameter und benutzt die weiter. Spart eine Menge teure Public-Key-Krypto und ist super für die Performance. Aber auf der anderen Seite heißt das eben, dass ein Angriff auf den Server auch diese ganzen gespeicherten Krypto-Kontexte im Speicher finden kann, und mit ihnen mitgesniffte Daten anderer Leute entschlüsseln kann. Das ist mal richtig doll Scheiße. Die Frage ist, ob sich Privilege Separation überhaupt lohnt, wenn man dieses Problem mit sich rumschleppt?
Und da denke ich mir gerade: Hey, was, wenn man die Tickets (so heißen die Cookies bei TLS) und die Krypto-Kontexte in einen dritten separaten Prozess packt. Grundsätzlich könnte das sogar sowas wie ein Redis auf einem anderen Server sein, dann könnten alle Frontends in einem Loadbalancer untereinander Session Resumption machen. Cloudflare hat vor ner Weile mal einen Hack in die Richtung angekündigt. Die Sicherheit von den Tokens basiert darauf, dass sie lang und zufällig und damit nicht vorhersagbar oder ratbar sind. Da müsste man gucken, wie man verhindert, dass ein Angreifer den Redis-Traffic mitsnifft, sonst hat man nichts gewonnen.
Naja und fundamental gibt es natürlich auch noch das Problem, dass die ganzen TLS-Libraries da draußen gar nicht vorsehen, dass man in ihren Interna herumpfuscht, und sowas macht wie nach einem Handshake die Krypto-Keys extrahieren und in einen anderen Prozess schieben, oder auf der anderen Seite einen bestehenden Krypto-Kontext entgegennehmen, aber ohne Public-Key-Teil des Kontexts, und dann damit symmetrisch Krypto zu machen.
Die nächste Frage ist natürlich auch, was eigentlich mehr CPU frisst, die Handshakes oder der symmetrische Teil. Das wird vermutlich von der Traffic-Load auf dem Server abhängen, ob der Videostreaming macht oder sowas wie mein Blog, was aus lauter kleinen kurzen Verbindungs-Bursts besteht.
Was ich sagen will: Ist alles nicht so einfach, und es ist auch nicht klar, ob sich der ganze Aufwand am Ende lohnen würde. Sollte aber glaube ich trotzdem mal jemand machen.
Update: Und es stellt sich natürlich die Frage, wen man hier eigentlich vor wem beschützen möchte. Muss man nicht eher befürchten, dass jemand den TLS-Stack hackt, als dass jemand den Webserver hackt?
Update: Vielleicht muss man sich aus Sicherheitsgesichtspunkten einfach generell von der Idee verabschieden, in einem Serverprozess mehrere Verbindungen zu multiplexen. Vielleicht sollte ich mal ein Extremkonzept implementieren, um zu gucken, wie schlimm das performt. Einfach damit man mal einen Datenpunkt hat. So pro Verbindung einen httpd-Prozess und einen TLS-Privilege-Separation-Prozess. Aber nicht abforken sondern schön fork+exec, damit die alle eigenes ASLR kriegen. Rein intuitiv kann das nicht gut performen, aber auf der anderen Seite gehen Rechnerarchitekturen ja gerade hin zu 256-Core-ARM-Servern. So würde man die ganzen Cores immerhin sinnvoll nutzen.
Auf der einen Seite ist das natürlich schockierend, dass ext4 so einen Bug hat. Nach all den Jahren sollte man denken, dass die Filesystem-Leute verstanden haben, dass man Längen in Strukturen nicht einfach trauen kann. Besonders ext4, denn das ist im Wesentlichen der Grund, wieso die Leute (auch ich) ext4 verwenden: Dass die einen fsck haben, der auch verlässlich funktioniert und die Lage nicht schlimmer macht.
Auf der anderen Seite war die Reaktion der Linux-Kernel-Leute innerhalb 24h, den Bug öffentlich zu machen in ihrem Bugtracker. Die machen also kein Security-Geheimhaltungs-Brimborium. Das ist schonmal gut. Und wenn man nach dem Problem googelt, findet man heraus, dass dieses Codestück als stinkend bekannt ist und da schon drei-vier Patches durchiteriert wurden, um das zu fixen. Ich frage mich, wieso man das Feature dann nicht wieder rausgeschmissen hat, wenn klar war, dass der Code stinkt.
Jetzt hatte jemand die Idee, man könnte ja den starren Kernel-Filtercode durch BPF ersetzen. Es stellt sich nämlich raus, dass es Netzwerkkarten gibt, die BPF unterstützen, d.h. da kann man dann seinen Firewall-Filter hochladen und dann muss der Host nicht mehr involviert werden.
Auf der anderen Seite ist das halt noch mal eine Schicht mehr Komplexität. Und man muss den BPF-Code im Userspace aus den Regeln generieren, d.h. man braucht neues Tooling.
Update: Es gibt übrigens noch mehr solche Vorstöße, jetzt nicht mit BPF aber ähnlicher Natur. Google hat kürzlich "gVisor" vorgestellt, das ist auch eine ganz doll schlechte Idee. Das ist von der Idee her sowas wie User Mode Linux, falls ihr das kennt. Ein "Kernel", der aber in Wirklichkeit ein Userspace-Prozess ist, der andere Prozesse (in diesem Fall einen Docker-Container) laufen lässt und deren Syscalls emuliert. Also nicht durchreicht sondern nachbaut. Im User Space. In Go. Wenig überraschend verlieren sie viele Worte über die Features und keine Worte über die Performanceeinbußen. Und noch weniger Worte darüber, wieso wir ihren Go-Code mehr trauen sollten als dem jahrzehntelang abgehangenen und durchauditierten Kernel-Code.
Stellt sich raus, dass die im Kernel das fsync-Verhalten verkackt haben, und Postgres daher Daten verlieren kann, wenn fsync fehlschlägt. Wenn man fsync aufruft, und das failed, und dann ruft man es später nochmal auf, dann erwartet der Kernel anscheinend von einem, dass man die writes dazwischen auch nochmal gemacht hat. Das ist völlig unerwartet und Postgres tut es nicht.
Die SZ hat eine neue Schriftart ausgerollt und bat um Kommentare. Ich habe einen Kommentar geschrieben. Ich finde, in Firefox unter Linux sehen die i-, und ä- und ü-Punkte leicht nach rechts verschoben aus. Ansonsten mag ich die Schriftart. Weniger mag ich die Sans Serif, die sie ausgerollt haben. Die ist mir zu breit. Wenn jemand Schriftarten breiter macht, habe ich immer den Eindruck, der schämt sich für seinen Inhalt und will ihn toller aussehen lassen als er ist.
Aber hey. Geschmackssache.
Jedenfalls kriege ich hier gerade eine Bounce-Mail. :-)
Fehler bei der Nachrichtenzustellung an folgende Empfänger oder Gruppen: [1]szdm.digitalesdesign@sz.de Ihre Nachricht kann nicht übermittelt werden, weil die Übermittlung an diese Adresse eingeschränkt ist. Diagnoseinformationen für Administratoren: Generierender Server: ad.sv.intern szdm.digitalesdesign@sz.de #550 5.7.1 RESOLVER.RST.AuthRequired; authentication required ##rfc822;szdm.digitalesdesign@sz.de
Erstens amüsiere ich mich über das "eingeschränkt". DAHER haben die Scammer also immer ihre Wortwahl! Von kaputt eingedeutschten Exchange-Fehlermeldungen! Die Fehlermeldung kam übrigens als HTML. Was besonders lustig ist, weil da auch die Mail von mir drin war, und da war ein Spam-Erkennungs-Header drin, der zeigt, dass sie u.a. Spam daran erkennen, dass der Content als HTML kommt.
Ja super, liebe Süddeutsche! Immerhin war ein Postfix davor, und der Exchange hängt nicht direkt mit nacktem Arsch im Internet.
Wenn ihr Linux benutzt, dann ist die Antwort wahrscheinlich: Ja. Firefox und Chrome basieren darauf.
Cairo ist anscheinend in keinem guten Zustand. Money Quote:
My immediate problem with Cairo is that it explodes when called with floating-point coordinates that fall outside the range that its internal fixed-point numbers can represent. There is no validation of incoming data, so the polygon intersector ends up with data that makes no sense, and it crashes.Das ist immer voll super, wenn man mit ungültigen Eingaben crasht. Das ist gute Alzheimer-Vorbeugung. Man muss die Leute in Bewegung halten.Money Quote 2:
Cairo has a very thorough test suite… that doesn't pass.Ja prima!
Decker räumt inzwischen freimütig ein, dass er beim Einhalten der Linux-Lizenz GPLv2 (GNU General Public License) zunächst geschlampt habe.Und wie verteidigt er sich? Beißholz bereithalten!
Geniatech-Chef Decker weist darauf hin, wie kompliziert es sei, die Linux-Lizenz vollständig einzuhalten.Äh … srsly? Ob seine Firma das bei ihren Produkten auch mit der Selbstzertifizierung nach CE so hält? Einhalten der komplexen Regeln ist schwierig, let's go shopping?!
Oder dem Finanzamt gegenüber? Steuern zahlen ist so kompliziert, also zahlen wir lieber gar nichts?!
Unfassbar.
Ich kenne diesen McHardy nicht, den Heise da als Feindbild aufzubauen versucht. Möglicherweise versucht der sich zu bereichern. Ja, äh, wieso ist das denn bei dem plötzlich verwerflich aber bei dem S. Fischer-Verlag nicht?! Ist die Profitmaximierung nicht auch das Ziel des Heise-Verlags?!?
Gut, dass sie da keine peinlichen Geheimnisse finden konnten, weil unsere Regierung nicht genug gearbeitet hat, um peinliche Geheimnisse zu produzieren.
Lacher am Rande:
Ausländische Hacker sind nach Informationen der Deutschen Presse-Agentur in das bislang als sicher geltende Datennetzwerk des Bundes und der Sicherheitsbehörden eingedrungen.Ja, äh, nee. Wer zu irgendeinem Netz annimmt, es sei schon sicher, ist inkompetent und sollte gefeuert werden. Erst recht, wenn das Netz von einem externen Dienstleister betrieben wird, wie T-Systems in diesem Fall.
Die Angreifer sollen Sicherheitskreisen zufolge der Gruppe "APT28" angehören, die viele Fachleute russischen Regierungsstellen zurechnen.Äh, nein. Schlangenöl-Verkäufer mit Panikschürmotiv verbreiten Ammenmärchen. Niemand hat da irgendwas zuordnen können. Es gibt da bloß unbelastbares Hörensagen aus nicht ernstzunehmenden Quellen mit kommerziellem Panikschürhintergrund.
Was für eine Farce mal wieder.
Hey, wisst ihr noch damals, als München auf Linux umgestellt wurde und von den Russen gehackt wurde? Nicht? WEIL ES NICHT PASSIERT IST. Ja warum bloß!1!!
Die Lösung für mehr Windows-Malware ist mehr Windows. Genau wie bei School Shootings in den USA. Die Lösung für mehr Gun Violence sind mehr Guns.
ZFS hat ein ähnliches Lizenzproblem. Vielleicht lenkt Oracle da ja auch noch ein?
Auf der anderen Seite wissen dann auch Hacker, wo was ist. Und weil die Softwareentwicklungsbranche vor vielen Jahren entschieden hat, dass sauber Programmieren zu schwer ist und wir lieber Hacker ärgern wollen, ging die Entwicklung dann dahin, dass man das Programm halt bei jedem Programmstart woanders hin tut im Adressraum. Das nennt sich dann PIE.
Technisch läuft das über einen gruseligen Hack im ELF-Dateiformat, denn das kennt nur Binary (Programm, an statischer Adresse) und Shared Object (Shared Library, an dynamischer Adresse). Das ist schlicht nicht vorgesehen, dass ein Programm an einer zufälligen Adresse geladen wird. Selbst wenn man den Code so formuliert, dass das ginge (was bei Intel/AMD bei 64-bit-Programmen viel einfacher und effizienter geworden ist als bei 32-bit-Programmen, weil der Befehlssatz da ein anderer ist, der darauf ausgelegt ist). Kurz gesagt gibt es bei 64-bit-Programmen eigentlich keine Effizienz-Ausrede mehr, um die nicht positionsunabhängig zu machen. Es gibt natürlich, wenn man genau hinguckt, doch einen Performancenachteil, aber den will ich hier mal außen vor lassen :-)
Der Hack ist jetzt so, dass man in der Datei einträgt, es sei eine Shared Library, kein Programm. Der Kernel lädt die trotzdem und alles ist gut. Das ist leider ein Opt-In-Ding. Wenn ihr unter Linux Software baut, tut mal bitte immer schön -fPIE auf die Compiler-Kommandozeile.
Nun bin ich aber nicht an regulären Binaries interessiert, sondern an statischen Binaries (das ist die Zielgruppe für meine libc). Und der Hack mit dem PIE geht zwar vom Dateiformat her auch bei statisch gelinkten Programmen, aber in der Praxis halt nicht. Ich habe mal ein paar Tage lang versucht, das doch zum Laufen zu kriegen, und bin am Ende gescheitert. Es geht aber prinzipiell. Das weiß ich, weil es jemand anderes geschafft hat: Der Autor der musl-libc. Der gute Mann hat irgendwann bei GNU ein paar Bugs eingetragen, ob es nicht toll wäre, wenn man da nicht so gruselig hacken müsste, wie er es getan hat. Und gcc 8 hat jetzt die Option -static-pie, die genau das tun soll.
Die wollte ich also auch direkt mal ausprobieren, und baute erstmal die neuen binutils, dann den neuen gcc, und jetzt die neue glibc. Und dann fiel mir auf, dass plötzlich meine dietlibc-Binaries größer waren. /bin/true macht im Wesentlichen nichts und sollte eigentlich nur ein paar Bytes groß sein (ein paar ELF-Header brauchen Binaries schon, aber so Größenordnung 200 Bytes ist eigentlich realistisch). War es aber nicht, sondern es war plötzlich über 4k groß. Gut, es war auch vorher weit davon entfernt, weil die dietlibc inzwischen eben eine Menge anderen Kram supportet, der die Startup-Code größer macht. Z.B. den Stack Protector initialisieren, und Thread Local Storage. Aber das true-Binary hätte trotzdem deutlich unter 4k sein müssen.
Ich habe also ein bisschen rumgeguckt, und es stellte sich raus, dass das nur mit dem binutils-bfd-ld so war. binutils ist das Paket unter Linux, aus dem der Assembler und der Linker kommen. binutils hat aber zwei Linker. Den alten mit bfd (der fetten Abstraktionsschicht von binutils) und den neuen, in C++ geschriebenen, der weniger kann, das dafür angeblich besser: GNU gold. Den habe ich normalerweise nicht im Einsatz, weil der bei mir vor Jahren mal Probleme gemacht hat beim Firefox-Linken. Egal. Mit dem gold ist das true-Binary nur 1,3 KB groß. Ich habe also mal reingeguckt und fand in dem statischen Binary von dem bfd-ld eine PLT. PLT steht für Procedure Linkage Table und ist für die Zusammenarbeit (und Umbiegbarkeit mittels LD_PRELOAD) von Shared Libraries da. Das hat in einem statischen Binary nichts verloren. Ich habe mal einen Bug aufgemacht bei binutils.
Ich stellte also auf GNU gold um, und wollte fluchs die neue glibc bauen — aber die baut mit ihrem neuen static-pie-Support für gcc 8 nicht mit gold, nur mit dem bfd-ld. *SEUFZ*
Aber jetzt wo die Infrastruktur da Support für hat, hoffe ich mal, dass auch für die dietlibc static PIE nur noch eine Frage der Zeit ist, möglichst kurzer Zeit. Das will man schon haben, besonders auf 64-bit-x86-Systemen, wo das kaum noch was kostet gegenüber Nicht-PIE.
Aus Frust hab ich jetzt mal true und false in Assembler gehackt für x86/x64 :-)
Update: Stellt sich raus: static pie mit gcc 8 funktioniert auf Anhieb, auch mit dietlibc. Cool!
Update: Gestern Bug gefiled, heute Patch da. Binutils rockt!
Die Benchmark-Parameter waren:
./bench -n 1000 -c 10 -k -K 5 http://127.0.0.1/testfileDas heißt: 1000 Mal diese Datei laden, über 10 Verbindungen parallel, mit 5 Downloads pro TCP-Verbindung via HTTP-Keepalive. Sowohl das Benchmark-Tool als auch gatling sind Single-Threaded und laufen auf jeweils einem Core nebeneinander. Es sollte also nicht zu vielen Context Switches kommen, aber natürlich sehr viele Wechsel vom User Space in den Kernel und zurück. Und die sind genau das, was durch den Fix langsamer werden. Die CPU ist ein Haswell (noch ohne Microcode-Update). Das sollte also ziemlich nahe am Worst Case sein. Und in der Tat. Mit dem alten Kernel:
bench: 164835678432 bytes in 24.7616 seconds. bench: Throughput: 6.2GiB/sec bench: Requests per second: 40und mit dem neuen Kernel:
bench: 164870699232 bytes in 39.3921 seconds. bench: Throughput: 3.9GiB/sec bench: Requests per second: 25Das ist ein ziemlich krasser Einbruch. Und da ist kein SSD beteiligt, das ist alles Buffer Cache ohne tatsächlichen I/O zu tatsächlicher Hardware.
Update: Nach Einspielen des neuen Microcodes wird es ein bisschen weniger schlimm (4.5GiB/sec), aber das ist immer noch katastrophal viel schlechter als vorher. Kann mir mal jemand erzählen, wieso das jetzt keinen Recall gibt?
Ich hatte übrigens den 4.15 mit Retpoline-Support gebaut, aber ohne einen gcc mit Retpoline-Support. Laut Dokumentation werden dann von Hand an einigen Stellen Assembler-Fixes eingebaut.
Update: Intel hatte den Microcode zurückgezogen. Stellt sich raus: Das Microcode-Update, das ich probiert habe, war gar nicht der Meltdown-Fix. Hatte mich schon gewundert, wieso da 2017 dran stand. Damit ist der Unterschied zwischen den 3,9 und den 4,5 GiB/sec anscheinend Messvarianz Messfehler.
Update: Ach und der gcc 7.3, mit dem ich den Kernel gebaut hatte, kann doch Retpolines. Haben sie nur nicht für relevant genug gehalten, um es im Changelog online zu erwähnen.
Update: Haswell ist gar nicht der Worst Case, wie sich rausstellt. Ich habe schon pcid und invpcid im /proc/cpuinfo. Bei Sandy Bridge und co ist das wohl noch deutlich schlimmer.
Wieso nutzen Firmen das eigentlich nicht aus? Firmen geben ein Heidengeld aus, um Mitarbeiter an sich zu binden, damit die nicht nach der Ausbildung woanders hin gehen. Aber bei Software tolerieren die Kreativität- und Lebensfreude-vernichtende Krückenlösungen. Schlechte Stühle, schlechte Tische, Großraumbüros, das hatte ich ja schon in meinem Antipatterns-Vortrag. Aber erweitert das mal auf Software und bürokratische Prozesse. Stellt euch mal vor, in einer Firma funktionieren die Prozesse von alleine, völlig stressfrei. Du brauchst irgendwas? Die Dokumentation ist verfügbar und auffindbar, das Formular fragt dich nicht nach Dingen, die die Firma eh schon über dich weiß, du musst nicht Internet Explorer 8 benutzen, damit die Seite funktioniert, sowas.
Das erstreckt sich auch auf ganz praktische Aspekte bei der Softwareentwicklung.
Normalerweise, wenn ich zum Kunden gehe, vergeht der erste Tag damit, dass die ihre Bürokratie auf die Reihe kriegen. Und das ist der gute Fall, nachdem die schon in Vorarbeit gegangen sind. Das ist nur noch sowas wie Badges abholen, Account aktivieren, Netzwerkzugang kriegen, Zugang zum Quellcode, etc. Aber ich habe einmal erlebt, bei VMware, dass dieser ganze Kram schon fertig war, bzw. "mal eben schnell geklickt wurde" in dem Meeting am Anfang. So ala "Was brauchen wir? Einen Server mit dem Quellcode? Braucht ihr den auf einer festen IP? Wollt ihr Windows mit Visual Studio? Eclipse? Linux? Alles einmal?" und während wir die Frage beantworteten, klickten die da kurz zusammen, Instanzen fuhren irgendwo hoch, und fertig war die Laube.
Na gut, denkt ihr euch jetzt vielleicht, das ist ja auch deren Kerngeschäft. VMs hochfahren. Ja und nein. Ich habe schon Datenbankhersteller erlebt, wo es mehrere Tage dauerte, bis ein Account im System war, und dann nach Abholen des Badges dauerte es nochmal einen Tag, bis das Aktiv-Flag sich durchs System repliziert hatte und man sich auch einloggen konnte. Und das ist noch nicht einer der schlimmsten Fälle. In den meisten Firmen da draußen ist die Infrastruktur in bemitleidenswertem Zustand, und die Leute arrangieren sich einfach damit.
Ich frage mich gerade, ob man das nicht ändern könnte, wenn man da bloß aus einer anderen Perspektive draufguckt. Wenn man das als Maßnahme zur Mitarbeiterbindung sieht. Denn wer einmal in einer Firma war, wo so Lebensqualitätsvernichtungsscheiß nicht mehr vorkommt, der geht doch nie wieder woanders hin! Was meint ihr?
Hier ist DragonflyBSD dazu. Money Quote:
Unfortunately, the only mitigation possible is to remove the
kernel memory mappings from the user MMU map, which means that every single
system call and interrupt (and the related return to userland later) must
reload the MMU twice. This will add 150ns - 250ns of overhead to every
system call and interrupt. System calls usually have an overhead of only
100ns, so now it will be 250nS - 350nS of overhead on Intel CPUs.[…]
I should note that we kernel programmers have spent decades trying to
reduce system call overheads, so to be sure, we are all pretty pissed off
at Intel right now. Intel's press releases have also been HIGHLY DECEPTIVE.
[…]
These bugs (both Meltdown and Spectre) really have to be fixed in the CPUs
themselves. Meltdown is the 1000 pound gorilla. I won't be buying any new Intel chips that require the mitigation. I'm really pissed off at Intel.
OpenBSD macht drei Kreuze, dass sie zumindest auf ARM nicht betroffen sind.Und von FreeBSD hört man, dass Intel ihnen einen Tag vor Weihnachten (!) Bescheid gegeben hat. Hey, äh, Jungs, öhm, ihr müsst da mal kurz euren Code ein bisschen umschreiben!1!! Ja super!
Update: Hier ein Statement der Linux-Leute, die auch eher unzufrieden wirken.
Der Dirty-Cow-Patch hat einen Nachfolger-Bug ausgeliefert.
Ein Einsender meint, ihm habe das das Filesystem zersägt (er hatte ein Backup von direkt vor dem Kernelupdate). Also Vorsicht!
Copy avoidance is not a free lunch. As implemented, with page pinning, it replaces per byte copy cost with page accounting and completion notification overhead. As a result, MSG_ZEROCOPY is generally only effective at writes over around 10 KB.Dieser Fall kommt nicht vor. gatling sendet einen kleinen Header, unter 1KB, und dann die Datei. Die Datei ist häufig größer als 10 KB, aber das Senden der Datei findet nicht per write oder sendmsg statt, sondern per sendfile, und das ist bereits zero-copy.Ich könnte das für den Proxy-Modus implementieren, aber ehrlich gesagt sehe ich den Payoff nicht. Die Latenz kommt da nicht vom Kopieren sondern vom gzip der Daten, und dem https (im https-Modus geht zero-copy eh nicht, außer man macht Kernel-TLS, und das unterstützt im Moment noch niemand). In der Praxis halte ich die Auswirkungen von diesem Code daher für Null. Die Entwickler davon mussten auch einen synthetischen Benchmark bemühen, um einen Vorteil nachweisen zu können.
Ich ignoriere das jetzt mal, bis mir jemand zeigt, dass das was bringt.
Das USB-Subsystem scheint in beklagenswertem Zustand zu sein. Hier sind die Bugs, die das Tool gefunden hat. Ja, das ist ein Fuzzer. Ja, der Code ist so beschissen, dass man mit einem Fuzzer Bugs findet.
Hier ist ein Talk, den das Team kürzlich gehalten hat (Folien dazu, Video dazu)
In den Chromebooks benutzen sie Coreboot, das hier ist ein anderer Ansatz.
Das gab übrigens, wie ihr euch sicher vorstellen könnt, einige interessante Gespräche mit Microsoft-Mitarbeitern, als ich da beruflich vor Ort war :-)
Jedenfalls hätte ich mir damals nicht träumen lassen, wenn ich meine Software nicht nach Windows portiere, dass Microsoft dann halt Windows zu meiner Software portieren würde. Das Windows Fall Creators Update kommt mit dem "Windows Subsystem for Linux". Das habe ich gerade mal ausprobiert und darin eines meiner dietlibc-Binaries gestartet, das ls von embutils. Das erste Binary, das ich probiert habe, segfaultete direkt. Also habe ich nochmal alles make clean gemacht, neu gebaut, das neue Binary mit Debug Info rüberkopiert, aufgerufen, und es tat einfach.
Jetzt bin ich ja doch ziemlich geflasht, muss ich euch sagen.
Das muss ich erstmal verdauen.
Der Intel Compiler kommt mit neueren glibc Versionen nicht zurecht, da diese einen Bug im Intel Compiler exponieren, der zu "unpredictable system behaviour" führt. Bei uns auf dem HPC Cluster hat sich das so manifestiert, dass unsere Benutzer nach dem Update von CentOS 7.3 auf CentOS 7.4 (dieses Update der glibc exponiert den Intel Bug) bei Simulationen (z.B. mit Kommerziellen "Finite Element" Applikationen wie ANSYS CFX, 3DS Abaqus etc.) falsche Resultate bekamen:Und weil das so grandios ist, kommt hier die technische Erklärung, was da vor sich geht:
- Simulationen die vor dem Update konvergierten tun dies nicht mehr
- Simulationen brechen ab, weil an verschiedenen Stellen NaN's raus kommen wo das nicht sein sollte.
- Bei Simulationen kommen andere Zahlen raus als vor dem Update
Der Bug betrifft potenziell alle mit Intel (Versionen älter als 17.0 Update 5) kompilierten Binaries und Bibliotheken auf Systemen mit Intel CPUs, welche AVX unterstützen.
According to x86-64 psABI, xmm0-xmm7 can be used to pass functionKeine weiteren Fragen, Euer Ehren!
parameters. But ICC also uses xmm8-xmm15 to pass function parameters
which violates x86-64 psABI. As a workaround, you can set environment
variable LD_BIND_NOW=1 by# export LD_BIND_NOW=1
Update: Ich sollte vielleicht mal erklären, was hier vor sich geht. Das ABI ist die Spezifikation dafür, wie man auf einer gegebenen Plattform auf Maschinencode-Ebene Argumente an Funktionen übergibt, und welche Registerinhalte Funktionen überschreiben dürfen, welche sie sichern müssen. Intel hat die Spec gesehen und gesagt "Hold my beer! Die Register dahinten benutzt keiner! Die nehm ich mal!" Das ABI hat aber ganz klar gesagt, dass die eben nicht frei sind.
Das Szenario hier ist: Der Compiler generiert Code für einen Funktionsaufruf. Nun könnte man sagen, hey, wenn der Intel-Compiler beide Seiten erzeugt hat, dann kann ja nichts schiefgehen. Aber es kann halt doch was schiefgehen. Wenn man ein dynamisch gelinktes Binary hat, dann geht der Funktionsaufruf eben nicht zur Funktion, sondern zum Wert in einer Tabelle. Die Einträge in der Tabelle zeigen initial auf ein Stück Code in der glibc, der dann die Adresse für das Symbol herausfindet und in die Tabelle einträgt und dann dahin springt. Die Idee ist, dass so eine Tabelle mehrere Zehntausend Einträge enthalten kann bei großen Binaries, und wenn man die alle beim Start von dem Binary auflöst, dann ergibt das eine spürbare Verzögerung. Denkt hier mal an sowas wie Firefox oder clang von LLVM. Daher löst man erst beim ersten Aufruf auf. Mit LD_BIND_NOW=1 kann man der glibc sagen, dass er bitte alles am Anfang auflösen soll, nicht erst später.
Was hier also passiert ist, ist dass der glibc-Code, der die Symbolauflösung macht, sich an das ABI gehalten hat und die u.a. für ihn reservierte Register benutzt hat. Und da hatte der Intel-Compiler aber Argumente reingetan. Die hat der Code zum Symbolauflösen dann mit Müll überschrieben. Die glibc wäscht hier ihre Hände in Unschuld (und ich hätte nicht gedacht, dass ich DAS nochmal sagen würde). (Danke, Samuel)
Das Pixelbook scheint das alles zu haben. Kennt jemand andere Geräte mit vergleichbaren Features? Mir wäre wichtig, als CPU mindestens Kaby Lake zu haben, damit der HEVC in Hardware abspielen kann. Viele Nachteile kann ich da gerade nicht sehen, außer dass das Gerät nicht in Deutschland auf den Markt kommt und ich daher mit US-Tastaturlayout leben müsste. Ich habe im Wesentlichen zwei Anwendungsszenarien, für die ich das Gerät haben wollen würde. Erstens aufm Bett liegen und Filme gucken, ohne alle halbe Stunde nervös auf die Akkuanzeige zu gucken. Zweitens zu Veranstaltungen mitnehmen und damit im Publikum sitzen, ohne alle halbe Stunde nervös auf die Akkuanzeige zu gucken.
Chromebooks haben den großen Vorteil, dass die Hardware perfekt von Linux unterstützt wird, und dass der Bootloader ein Coreboot ist. Da kann man auch was anderes booten, wenn man Lust hat. Früher musste man noch ein Hardware-Siegel brechen, um in den Developer-Mode zu kommen, das ist seit Jahren nicht mehr nötig. Das könnte das ideale Linux-Gerät sein. Oh und lüfterlos ist es auch noch. Ich sehe gerade nur zwei Dinge, die für mich praktisch ein Nachteil wären: Nur noch Type-C USB (Maus anschließen bräuchte also einen Adapter) und keinen SD-Card-Reader mehr. Den habe ich bei meinem aktuellen Gerät immer benutzt, um die abzuspielenden Mediendateien aufs Gerät zu bringen.
$999 ist natürlich eine Menge Holz für einen glorifiziertes Videoabspielgerät. Auf der anderen Seite zahlen andere Leute soviel für ihre Telefone. In Europa kann man das dann wohl in UK ordern, aber hat dann mal eben 45% Preisaufschlag. Als ob es den Briten nicht schlecht genug ginge! Schäm dich, Google!
Jetzt muss man den Kernel updaten, wenn es mal wieder ein TLS-Update gibt!? Ein Bug im TLS-Code liefert jetzt Kernel-Privilegien?! Der Kernel macht X.509 und ASN.1?! Womit so ziemlich jeder andere auf die Fresse geflogen ist, der das probiert hat?!?
Daher dachte ich mir, ich gebe mal zu Protokoll, dass ich das für eine tolle Idee halte. Und zwar ist nicht das Handshake im Kernel (das ist der komplexe Teil am Anfang, der mit den ganzen Protokollunwägbarkeiten), sondern der Kernel übernimmt lediglich die Transportverschlüsselung, nachdem der Schlüssel ausgetauscht ist. Ein bisschen Einkapseln, symmetrische Krypto drüberlaufen lassen, fertig. Da kann man immer noch was falsch machen, klar, aber das ist, von der Angriffsoberfläche her, sowas wie 1% von TLS. Da mache ich mir wenig Sorgen.
Und auf der anderen Seite steht der Vorteil. Wenn man im Moment einen Client hat, der irgendwas verkackt, dann kann man da mit beim System beliegenden Tools wie strace die System Calls tracen lassen. Da steht dann sowas wie:
write(3,"GET /foo.txt HTTP/1.1\r\nHost: example.com:80\r\n\r\n",47)Da kann man sehen, was der Client zu tun versucht hat. Und man kann die Antwort des Servers sehen. Wenn der Client TLS benutzt, dann sieht man bei strace nur noch die verschlüsselten Daten.
Wenn ich den Zugriff habe, den strace benötigt, kann ich natürlich auch die unverschlüsselten Daten abgreifen. Das ist also kein Schutz gegen jemanden mit diesem Level an Zugriff. Aber es macht Debugging und Tracing halt sehr schwierig. Mit TLS im Kernel würde man wieder den Klartext in read und write sehen.
ALLEINE DAFÜR ist das schon eine Sache, die ich haben will.
Es gibt noch einen weiteren Vorteil, der ist mir aber nicht so wichtig. Der Webserver kann dann wieder zero-copy TCP mit sendfile() machen. Das ist dann nicht wirklich zero copy, weil der Kernel ja verschlüsselt. Der kann also nicht einfach DMA aus dem Buffer Cache machen. Aber immerhin, eine Kopie weniger. Das war auch der Grund, wieso dieser Patch überhaupt gemacht wurde.
Und der andere Vorteil ist, dass man mit Debugging-Zugriff im System dann auch die Daten im Transit verändern kann. Das ist wichtig für Pentesting, aber auch für automatisiertes Testing kann das nützlich sein. Im Moment muss man dann einen Proxy aufsetzen und im System dessen Zertifikat als Trusted eintragen und so weiter.
Diese Eingriffe gehen wohlgemerkt auch jetzt schon alle mit Debugging-Rechten. Sie sind nur viel anstrengender umzusetzen.
Allerdings gibt es halt beim Selberbauen immer mal wieder Stress.
Eine Weile gab es Konflikte, weil Firefox auf einer über 10 Jahre alten Version von GNU autoconf bestand, die ich nicht hatte.
Dann gab es Ärger, weil Firefox H.264-Playback (Youtube und co) nur abspielen wollte, wenn man gstreamer installierte — aber es bestand auf einer 10 Jahre alten Gammelversion, die schon längst nicht mehr gewartet wurde.
Inzwischen hat Firefox auf ffmpeg umgestellt, und das tat auch eine Weile ganz gut, aber vor ein paar Tagen stellte es die Arbeit ein. Ich bin dann auf die Vorversion und zurück und habe mir das für das Wochenende vorgenommen. Jetzt ist Wochenende, und ich habe erstmal die neue glibc 2.26 installiert (die endlich reallocarray von OpenBSD übernommen hat, und einen per-Thread malloc-Cache hat, was die Performance massiv verbessern sollte in Programmen mit mehreren Threads).
Das brach mir dann erstmal alles.
Die Shell konnte plötzlich nicht mehr meinen Usernamen herausfinden, screen wurde konkreter und sagte, getpwuid könne meinen User nicht auflösen. Sowas gibt es bei glibc häufiger, weil die gerne mal Dinge als "deprecated" markieren, für die es keinen Ersatz gibt. Zum Beispiel pt_chown vor einer Weile. Das war halt unsicher, also haben sie es weggemacht. pt_chown ist das Vehikel, über das die einschlägigen libc-Routinen (grantpt) ein PTY allozieren, und es liegt in /usr/libexec, wenn es denn überhaupt liegt. Und plötzlich kam mein X nicht mehr hoch, weil mein X solange läuft, wie mein Terminal in X läuft, und das konnte kein PTY mehr allozieren.
Später hat glibc dann Sun RPC rausgeschmissen, und dann ließ sich mount(8) nicht mehr bauen. Ja super. Und jetzt haben sie nsl für obsolet erklärt und in nss ausgemistet (NIS rausgekantet und so). Gut, NIS verwende ich nicht. Als das nicht ging, habe ich halt neu gebaut, diesmal mit --enable-obsolete-nsl, aber das brauchte auch nichts. Stellt sich raus: in meine /etc/nsswitch.conf stand drin:
passwd: compatUnd das sorgte dafür, dass die glibc libnss_compat.so oder so zu laden versuchte, und das gibt es nicht mehr. Die glückbringende Änderung war dann:
shadow: compat
group: compat
passwd: filesSeufz. Bei solchen Gelegenheiten bin ich ja immer froh, dass mein getty und mein login gegen dietlibc gelinkt sind, und für Notfälle noch eine diet-shell rumliegt. So komm ich auch nach solchen glibc-Sabotageakten immer noch irgendwie ans System ran und kann Dinge fixen.
shadow: files
group: files
Aber eigentlich wollte ich ja von Firefox erzählen. Nach dem glibc-Update baut auch Firefox nicht mehr, weil glibc in sys/ucontext.h eine struct von struct ucontext zu struct ucontext_t umbenannt hat. Ich bin mir sicher, dass es da Gründe für gab, aber meine Phantasie reicht nicht, um mir welche auszudenken. Was für ein Scheiß ist DAS denn bitte?! Firefox hat einen Crash Reporter, und der will halt in diesen Strukturen herumfuhrwerken, weil man das tun muss, wenn man sehen will, in welchem Zustand das Programm beim Crashen war.
Gut, nur ein Dutzend Dateien musste ich anfassen, dann baute Firefox wieder. Aber H.264 war immer noch kaputt.
Und die Story ist richtig interessant, daher will ich sie hier mal bloggen. Wenn man so ein Problem hat, dann ist unter Linux eine der ersten und besten Debugmöglichkeiten, dass man strace benutzt. Programme unter Linux laufen im User Space, und die interagieren mit dem Kernel über Syscalls. strace fängt die Syscalls ab und gibt ihre Argumente und Ergebnisse aus. Hier ist ein Beispiel:
$ strace /opt/diet/bin/cat true.cHier sieht man ganz gut, was cat tut. execve gehört noch nicht zu dem cat selber, das ist der Aufruf von dem cat. arch_prctl ist ein Implementationsdetail, das man auf x86_64 macht, um thread local storage einzurichten (die libc weiß an der Stelle nicht, dass cat das nicht benutzt). strace auf Firefox ist natürlich viel umfangreicher, aber mit ein bisschen Geduld kann man da trotzdem sehen, was passiert, bzw. was nicht passiert. Und zwar sah ich das hier:
execve("/opt/diet/bin/cat", ["/opt/diet/bin/cat", "true.c"], [/* 60 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7fff5e690f70) = 0
open("true.c", O_RDONLY) = 3
read(3, "int main() {\n return 0;\n}\n", 65536) = 27
write(1, "int main() {\n return 0;\n}\n", 27int main() {
return 0;
}
) = 27
read(3, "", 65536) = 0
close(3) = 0
exit(0) = ?
+++ exited with 0 +++
7194 openat(AT_FDCWD, "/usr/lib64/libavcodec-ffmpeg.so.57", O_RDONLY|O_CLOEXEC) = 257
7194 --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_errno=EEXIST, si_call_addr=0x7fc218252840, si_syscall=__NR_openat, si_arch=AUDIT_ARCH_X86_64} ---
7194 socketpair(AF_UNIX, SOCK_SEQPACKET, 0, [39, 40]) = 0
7194 sendmsg(36, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\10\0\0\0\0\0\0\0\0\0", iov_len=16}, {iov_base="/usr/lib64/libavcodec-ffmpeg.so."…, iov_len=35}, {iov_base=NULL, iov_len=0}], msg_iovlen=3, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[40]}], msg_controllen=24, msg_flags=0}, MSG_NOSIGNAL <unfinished …>
7196 <… recvmsg resumed> {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\10\0\0\0\0\0\0\0\0\0", iov_len=16}, {iov_base="/usr/lib64/libavcodec-ffmpeg.so."…, iov_len=8194}], msg_iovlen=2, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET,cmsg_type=SCM_RIGHTS, cmsg_data=[66]}], msg_controllen=24, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 51
7194 <… sendmsg resumed> ) = 51
7196 openat(AT_FDCWD, "/usr/lib64/libavcodec-ffmpeg.so.57", O_RDONLY|O_NOCTTY|O_CLOEXEC <unfinished …>
7194 close(40 <unfinished …>
7196 <… openat resumed> ) = 95
7194 <… close resumed> ) = 0
7196 sendmsg(66, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0", iov_len=4}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[95]}], msg_controllen=24, msg_flags=0}, MSG_NOSIGNAL <unfinished …>
7194 recvmsg(39, <unfinished …>
7196 <… sendmsg resumed> ) = 4
7194 <… recvmsg resumed> {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0", iov_len=4}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[40]}], msg_controllen=24, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 4
Die Ausgabe ist ein bisschen verwirrend mit dem unfinished und resumed; das kommt daher, dass Firefox mehr als einen Prozess/Thread aufmacht, und die miteinander reden, und ich alle von denen auf einmal beobachte. Aber mal grob: Prozess A ruft openat(AT_FDCWD,…) auf, das ist äquivalent zu open(…). Kriegt als Ergebnis 257 und direkt ein Signal SIGSYS mit si_code SYS_SECCOMP.Das ist ziemlich coole Scheiße, weil das genau das ist, was ich auf dem 32c3 in meinem Vortrag "Check your privileges" als Broker-Architektur vorgestellt hatte. Die haben das aber nicht über Überladen von openat gemacht, sondern die haben das so gemacht, dass SECCOMP nicht den Prozess abbricht sondern dieses Signal schickt. Das Signal fangen sie dann ab, und der Handler von dem Signal kann dann nachvollziehen, was der Code zu tun versucht hatte, in diesem Fall openat, und das anders lösen — nämlich über sendmsg an den Broker, wie wir in dem strace schön sehen können. Der Broker macht recvmsg, kriegt die Anfrage (und wir sehen in den Daten von dem sendmsg auch schön den Dateinamen), und öffnet die dann. Die Zahl am Anfang ist übrigens die PID bzw. Thread-ID.
Der Broker macht dann selber nochmal openat, hat keinen SECCOMP-Filter installiert, das openat läuft durch, und dann schickt der Broker mit dem zweiten sendmsg oben den Deskriptor 95 zurück an den anfragenden Prozess in der Sandbox. Der kriegt das dann in dem recvmsg als Deskriptor 40 reingereicht (Deskriptoren sind immer relativ zum Prozess, daher findet hier im Kernel eine Übersetzung statt). Das ist mal echt coole Scheiße, und ich bin einigermaßen schockiert, dass Firefox so Bleeding-Edge-Kram überhaupt implementiert hat. Sehr cool!
Warum ich das hier alles erwähne: weil das bei mir auf die Nase fiel, denn zum Abspielen von H.264 lädt Firefox libavcodec von ffmpeg, und ffmpeg ist gegen einen Haufen Codecs und Libraries gelinkt, und die liegen bei mir eben nicht alle in /usr/lib64, sondern beispielsweise liegt libva in /usr/X11R7/lib64 (libva macht hardware-assistierte Dekodierung und Anzeige von u.a. H.264-Videos). Und es stellt sich raus, dass Firefox in dem Broker eine Liste von erlaubten Verzeichnissen hat, aus denen Dateien geöffnet werden können, und die wird nicht aus /etc/ld.so.conf oder so generiert, sondern die ist hardkodiert im Quellcode. Falls jemand mal selbst gucken will: Das ist in security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp (nach policy->AddDir gucken).
Nachdem ich da meine Pfade eingetragen habe, kann der Firefox ffmpeg laden — aber das Video immer noch nicht spielen. Das sei jetzt korrupt, sagt er. Ist es natürlich nicht. Mist. Na mal schauen. Fortschritt ist immer nur ein Schritt zur Zeit.
Update: Ein Einsender zur glibc-Situation:
Das Update habe ich für unsere cross-gebauten Umgebungen diese Woche auch gemacht. Mal so ein paar Sachen, die aufgefallen sind:
- gcc 5.4 baut dann nicht mehr (ucontext_t, auch ein paar Stack-Sachen), betrifft auch neuere Versionen von gcc
- iproute2 4.11 baut auch nicht mehr (4.12 schon, also mir egal). IIRC haben sie irgendwo vergessen stdint.h für UINT16_MAX einzubinden, und das muss vorher zufällig über irgendeinen anderen Header mit reingekommen sein (also ganz klar nicht die Schuld von glibc)
- gdb 8.0 baut nicht mehr auf x64 (ARM geht), irgendwas mit putc(), das nur ein Argument bekommt oder so.
Ganz großes Kino.
In der Tat. o_O
On Ryzen there is some sort of interaction between code running at the top of user memory address space and interrupts that can cause FreeBSD to either hang or silently reset.Update: Und unter Linux hat Ryzen wohl unter Last zufällige Segfaults.
Man kann durch geschickt gefälschte Pakete beide seiten einer TCP-Verbindung so verwirren, dass sie sich endlos gegenseitig mit ACK-Paketen bombardieren. Google hat das in ihrem Rechenzentrum mal (anscheinend durch kaputte Hardware) erlebt und Patches für Linux gebaut.
Nun, äh, mein Kumpel Ilja hat mal nachgeguckt und die Ergebnisse sprechen eher nicht für BSD.
Schenker-Notebooks sind, wie auch diverse andere Notebooks auch, ursprünglich Barebones von Clevo. Die Symptome sind spontane Bluescreens unter Windows in SynTP.sys mit Fehler DRIVER_IRQL_NOT_LESS_OR_EQUAL (gelegentlich auch ein anderer Fehler aber auch in SynTP.sys).
Das passiert im Allgemeinen während hoher Systembelastung, beispielsweise während Videospielen.
Das Internet ist voll von Fehlerbeschreibungen dieser Art, einige wenige (gefühlt die Ausnahme, aber das kann auch an meinem Sample liegen) auch bei anderen Herstellern als Clevo. Lösungen scheint es keine zu geben. Viele Foren schlagen dann so die üblichen hilflosen Verdächtigen vor, GPU-Treiber updaten, Antivirus deinstallieren, Patches einspielen, blablah, das ist alles Bullshit. Also bis auf Antivirus wegmachen jetzt :-)
Das kann man auch nicht auf ein Hardwareproblem schieben, weil das ein völlig eindeutiger Programmierfehler im Treiber ist. Wer sich mit Treiberprogrammierung unter Windows ein bisschen auskennt: Das passiert, wenn ein Treiber in einem kritischen Pfad auf Speicher zugreift, der aus dem Speicherpool mit Paging kommt statt aus dem Non-Paged Pool. Speicher aus dem Paging-Pool kann vom Kernel rausgeswappt werden, und der Zugriff darauf führt dann dazu, dass die Speicherseite nachgeladen werden muss. Unter Linux ist von Kerneltreibern allozierter Speicher grundsätzlich nicht swapbar, unter Windows aus historischen Gründen doch. Nun ist das nicht generell verboten, im Windows-Kernel auf page-baren Speicher zuzugreifen, aber es gibt eben Situationen, in denen es nicht geht. Zum Beispiel wenn man gerade einen Interrupt bearbeitet, oder von jemanden aufgerufen wird, der einen Interrupt bearbeitet. Weil während dieser Operation ein zentraler Mutex im Kernel gehalten wird, würde das Auslösen von Paging zu einem Deadlock führen. Wenn der Kernel das also feststellt, gibt es sofort einen Bluescreen.
Dieser Bug kann auch auftreten, wenn ein Treiber in einer Interrupt-Routine auf völlig ungemappten Speicher zugreift, also einem wilden Zeiger hinterherrennt oder so.
Es gibt, kurz gesagt, keine Entschuldigung für dieses Verhalten. Nein, da ist nicht "das Mainboard zu warm geworden" oder "die Hardware hat ne Macke". Das ist ein Programmierfehler im Treiber. Gut, außer das Mainboard ist so doll zu warm geworden, dass der RAM Mist zurückliefert, aber dann ist auch alles andere zu spät und das würde nicht reproduzierbar im SynTP.sys auftreten.
Weil dieses Problem bei diversen Laptops seit vielen Jahren auftritt, und Synaptics offensichtlich nicht in der Lage ist, einen Treiber ohne diesen Fehler auszuliefern, werde ich in Zukunft vom Erwerb von Laptops mit Synaptics-Touchpad absehen.
Unter Linux ist übrigens alles in Ordnung mit dem Touchpad. Es ist nur der Windows-Treiber von Symaptics, der hier braun ist.
Kann es sein, dass ein Hardware-Problem zu dem speziellen Timing führt, das diesen Bug erst triggert? Ja, theoretisch. Aber ob das jetzt in der Praxis auftritt oder nicht — das ist ein Programmierfehler im Symaptics-Treiber. Schenker kann dafür nichts (außer dass sie Synaptics-Produkte ausliefern). Das einzige, was ich daher an dieser Stelle von Schenker erwarten würde, ist dass sie ab jetzt an ihre Produkte klar ranschreiben, ob da Synaptics-Produkte verbaut wurden oder nicht.
Das Touchpad im Gerätemanager zu deaktivieren hilft übrigens nicht.
Den Treiber manuell zu deinstallieren hilft auch nicht, weil Windows den sofort aus dem Windows Update Repository neu nachinstalliert. Das selbe passiert, wenn man den offiziellen Treiber von der Webseite von Synaptics lädt und zu installieren versucht.
Update: Ein hilfreicher Hinweis kam noch rein: Dass das möglicherweise von einem Filtertreiber ausgelöst wird. Ein Filtertreiber ist ein Treiber, der sich sozusagen zwischen einen anderen Treiber und den Kernel hängt, das kennt man hauptsächlich bei Filesystemen. Bei Clevo-Laptops gibt es aber einen Filtertreiber für Hotkey-Handling. Das ist denkbar, dass der sich vor den Synaptics-Treiber hängt und den kaputtmacht. Zwischen Kernel-Komponenten gibt es keinen Speicherschutz wie zwischen verschiedenen Programmen im Userspace. Wenn der Schuld ist, trifft Synaptics natürlich keine Schuld und ich ziehe meine Kritik zurück. Ich probiere das mal aus, diese Filtertreiber nicht zu laden.
nach deinem Hinweis auf den Evince-Thumbnailer-Bug neulich habe ich mir mal andere Thumbnailer angeschaut. Die meisten sind da eher von mäßiger Qualität, etwa ein Drittel hat offensichtliche Vulnerabilities. Nachdem ich es hinbekam, einen GNOME-Thumbnail-Handler für MSI-Dateien VBScript ausführen zu lassen, habe ich keine Lust mehr, den Schrott anzuschauen.Kann ich verstehen. So geht mir das auch immer, wenn ich mir unter Linux irgendwelchen GUI-Code angucke. Mein persönlicher Höhepunkt war, als ich sah, dass gtk+ bei der Initialisierung guckt, ob das Programm setuid ist, und dann abbricht. Begründung: Wir haben hier gar nicht erst versucht, unseren Code sicher zu machen. JA SUPER!
Update: Einsender helfen aus: Man muss CONFIG_USB_PCI anschalten, wo sich die Beschreibung fälschlicherweise so liest, als sei das bloß für irgendwelche SOCs wichtig.
Hätte uns doch nur vorher jemand gewarnt, dass AV-Engines die Angriffsoberfläche erhöhen!1!!
Ooooooh das gibt Brandwunden in Redmond!
Noch ein zartes Pflänzchen der Hoffnung übrig?
Dem kann ich anhelfen. Ein Leserbrief kam noch rein.
eine kurze Anmerkung zum Laboralltag. Fefe meinte im Blog> Man hörte in letzter Zeit häufiger von irgendwelchen Spektroskopen an > Unis, von Steuersoftware für Großmaschinen. Na dann hängt die halt > nicht ans Netz.Dann sind die Dinger für uns ziemlich nutzlos. Diese Dinger dienen dazu Daten zu sammeln und an andere Computer weiterzuleiten… zur weiteren Auswertung, entweder später, oder sogar unmittelbar zur Prozesssteuerung.
Meßgeräte waren mit so ziemlich die erste Geräteklasse die eine Form von echter Vernetzung implementierten. Späte 1960er, IEEE-488/GPIB, ein Multi-Master-fähiger Bus. Da drüber fährt man üblicherweise ein ziemlich rustikales Protokoll (SCPI) das eigentlich auf OOB-Signaling für Fehler angewiesen ist.
Mittlerweile haben die Kisten alle IP und üblicherweise schickt man SCPI über einen unauthentifizierten, offenen TCP-Stream. Klar könnte man da ein TLS drüber stülpen. Aber die Leute die Meßgeräte verwenden, wollen die üblicherweise mit LabVIEW ansteuern (ein übelstes Stück Software dessen Update-Prozess mit Leichtigkeit jedes andere Produkt da draussen in Sachen Beschissenheit überbietet).
> Wenn die Funktionalität ohne Netzzugang nicht nutzbar ist,Die Dinger funktionieren wunderbar ohne Zugang zum Internet. Wenn man sich irgendwelchen DRM-Mist ans Bein binden will, dann läuft das in diesem Marksegment üblicherweise per SmartCards. Irgendwo innen drinnen gibt es einen Slot für eine SmartCard im SIM-Karten-Format, da tut der Hersteller eine Lizenzkarte rein und die regelt das.
Aber so richtig vom Internet abschotten kann man sie auch nicht. Das Problem mit internen Netzwerken und Firewalls habt ihr ja in Alternativlos 39 angesprochen. Und es ist nun mal sehr oft so, dass man die Dinger in einem internen Labornetz stehen hat, das aber über eine Firewall mit dem normalen Büronetz verbunden ist, damit man per Remote-Desktop nach dem Rechten sehen kann. Und natürlich auch, weil man auf den Geräten auch seine eigenen Programme laufen lassen kann, die man natürlich nicht auf den Geräten selber speichert, sondern auf einem zentralen Server. D.h. SMB ist üblicherweise auch notwendig, damit man vernünftig damit arbeiten kann.
Richtig krass ist es an Teilchenbeschleunigern. Da wird das Experiment aufgebaut, aber Strahlzeit bekommt man meistens erst viel später. Da sind einige Leute darauf angewiesen sich, teilweise vom anderen Ende der Welt, irgendwie Remote mit dem Experiment verbinden zu können um den Leuten vor Ort entweder mit Rat beiseite zu stehen, oder direkt Daten aufzunehmen. Das WWW (also HTTP) wurde nicht durch Zufall am CERN erfunden.
Oder man nehme Radioastronomie. Da werden Experimente einmal quer über den Erdball miteinander verschaltet; die Daten werden lokal aufgezeichnet, mit GPS-Timestamps versehen, aber die Steuerung erfolgt über das Internet.
Computer-Netzwerke waren schon immer lebensnotwendig für Experimentatoren.
> dann hättet ihr die halt nicht kaufen dürfen, ohne euch zu > versichern, dass da für Sicherheit gesorgt ist.Meßgeräte haben die Eigenschaft, dass sie üblicherweise sehr langliebig sind. In vielen Labors findet man Geräte die 15 Jahre oder älter sind. So lange die Hardware noch funktioniert gibt es einfach keinen Grund die auszutauschen.
Nimm zum Beispiel mal das DPO7104 das auf Windows-XP läuft. Das wurde, wenn ich mich recht erinnere, irgendwann so um 2005 herum angeschafft. Zu diesem Zeitpunkt war Vista noch Longhorn. Wenn man da den Hersteller fragt "Wie sieht es mit Updates aus?", kommt als Anwtort "das müssen sie Microsoft fragen."
Als wir letztes Jahr das LeCroy und das Keysight angeschafft haben war einer der entscheidenden Punkte im Anforderungs-Katalog der Ausschreibung, wie denn die Software-Wartungs-Strategie bezüglich Betriebssystem-Updates und dadurch bedingt notwendiger Anpassungen aussieht. Einer der Anbieter hat sich mit folgender Aussage komplett disqualifiziert:
"Falls das System durch Software-Update unbenutzbar wird, kann es mittels dem Acronis-Recovery-Image auf dem System in den Fabrikzustand zurückgesetzt werden." — Themaverfehlung, setzen, 6.
Von zwei anderen Herstellern weiß ich, dass denen Windows-10 die Haarpracht schon ins Mithrandir-Weiß hat ergrauen lassen. Die sind echt nicht "ammused" von dem was Microsoft da fährt. Andererseits können die auch nicht einfach auf Linux oder FreeBSD wechseln, weil um diese Geräte ein regelrechtes Ökosystem aus Ranzsoftware existiert, die nur auf Windows läuft: Matlab, LabVIEW (dafür gibt es zwar eine Linux-Version, aber die ist echt übel), Origin, usw.. Und die Leute wollen auch in 10 Jahren weiterhin ihre Legacy-Software verwenden können.
Ich denke Microsoft wird in den nächsten Jahren der komplette Embedded- und Meßgeräte-Markt wegbrechen. Microsoft wird es nicht jucken. Mit Konsumenten verdient man Geld, nicht mit wenigen großen Fischen.
Ein generelles Problem, gerade was Security und Updates angeht ist, dass diese Geräte auch oft in Langzeitexperimenten stehen die über Wochen oder Monate kontinuierlich Daten aufnehmen sollen. Wenn da ein automatisierter Updateprozess die Kiste unvermittelt herunterfährt, oder sonstigen Mist macht kann das ziemlich schlecht sein. Deshalb sind die automatischen Updates aus solchen Geräten üblicherweise ausgeschaltet.
Was die Sache mit den Treiber-Signaturen angeht und dass man das doch alles sicher portieren könne, das Treibermodell habe sich ja nicht geändert. Nun, teilweise machen die Hersteller von diesen Kisten echt schräges Zeug auf der Hardware-Ebene — Elektroingenieure halt — die auf der Software-Seite zu echt üblen Hacks führen.
Nimm z.B. mal diese Tektronix-DPO-Scopes. Ein Manko das digitale Speicheroszilloskope lange hatten war, dass diese mit Frequenz-Aliasing nicht gut umgehen konnten. Bei analogen Oszis verschmiert einfach nur der Elektronenstrahl auf dem Bildschirm, aber Digitale haben da lange Zeit einfach nur Signal-Müll angezeigt und so getan als wäre das richtig.
Tektronix hat sich dann gedacht: Hey, emulieren wir doch einfach den Elektronenstrahl. Dazu haben die dem Oszi einen zweiten Graphik-Chip (von ATI) eingebaut in dessen Speicher dann die Datenerfassunghardware direkt Pixelwerte hineinmanipuliert. Und dieser Speicher hängt dann irgendwie elektrisch an dem Speicher vom Hauptgraphik-Chip dran. Und entsprechend genau dafür ist die Software ausgelegt. Nun ist das Treibermodell für Graphik-Hardware einer der Teile von Windows der sich schon mehrmals geändert hat. Nicht unbedingt das was im Kernel passiert und auch das Userland ist recht konstant, aber die Schnittstelle zwischen Kernel- und Userland. Und diese Tektronix-DPO-Scopes haben sich das mitten hineingesetzt und wollen eine bestimmte API sehen. Nebeneffekt: Das Programm von denen ist knallhart auf XGA-Auflösung festgenagelt.
Keysight und LeCroy haben solchen Mist zum Glück nie gemacht. Und diese beiden Kisten haben sich auch problemlos updaten lassen. Die Tektronix-Scopes dagegen erfordern echt finsteres Voodoo; der XP-Patch von Microsoft funktioniert nur für SP3, aber das alte Tektronix-Teil verträgt kein SP3. Ich bleibe am Ball.
Was gesetzliche Regelungen angeht: Ich vertrete schon seit Jahren die Ansicht, dass Hersteller im Rahmen der Produkthaftung dazu verdonnert werden sollten für Produkte für die es offiziell keinen Support mehr gibt alle Source-Codes und Hardware-Programmier-Informationen herauszurücken. Keine Diskussion. Falls die Hersteller das nicht wollen, müssen sie halt langfristig Software-Support auf dem aktuellen Stand der Technik anbieten.
Der Fall, dass durch Insolvenz eines Herstellers dies nicht gegeben ist, ist denkbar gering. Die Zahl an relevanten Firmen im Meßgerätebereich kann man an 3 Fingern abzählen (binär) und sind auch Zulieferer für die Rüstung, dass die nicht so schnell verschwinden.
Wobei, Tektronix würde ich keine Träne nachweinen. Früher haben die echt geile analoge Oszilloskope gebaut, aber deren Digital-Scopes waren eigentlich immer eher so "meh". Die DPOs so von vor ca. 15 Jahren waren mal kurzzeitig cool, aber die dümpeln jetzt wieder so vor sich rum.
MS hat seit dem letzten W10 update delta updates, sie nennen es UUPEin zweiter Leserbrief beschreibt die Situation im Digital Signage-Markt:
blogs.windows.com
blogs.windows.com
wenn ihr schon so nett fragt kann ich ja mal ein paar Zeilen schreiben da ich beruflich so ein System entwickelt habe. 2010 brauchte ich einen neuen Job und wurde über einen ehemaligen Kollegen angesprochen ob ich nicht für eine Firma die Digital Signage macht ein Internet basiertes System neu entwickeln will.Ein Dritter berichtet auch aus dem Signage-Markt:
Das VB6 System das die Firma bis dahin bai knapp 1000 Kunden am laufen hatte war in die Jahre gekommen und etwas das über einen Browser von überall her steuern war dringend erforderlich.Wie man sich sicher denken kann lief die alte Software auf Windows also sollte die neue Software auch darauf laufen - hier also schon mal der erste Grund warum Digital Signage auf Windows läuft - weil Version N-1 das getan hat. Hinzu kam das der technisch Verantwortliche (der die VB6 Version entwickelt hatte) darauf bestand verschiedene Teile der VB6 Version weiterzuverwenden (U.A. einen Laufschrift Generator der dank V-Sync seiner Meinung "Broadcastqualität" hatte).
Den Kontrollserver durfte ich glücklicherweise als Linux System bauen. Der Windows-teil in in C# geschrieben.
Seit 2010 hat sich einiges getan auch hardwaremäßig und ich hatte versucht seit 2012 oder so die Client PCs durch etwas sinnvolleres wie einen Raspberry pi oder ein geeignetes Android System zu ersetzen. Leider war dafür nie Zeit bzw. die günstigere Hardware war nie ein genügendes Argument um die knapp 2 Monate in eine neue Player Software zu investieren. (Hier also Grund 2 - "Warum es funktioniert doch").
2013 wurde die kleine Firma durch eine Größere gekauft. Der Kollege der die VB6 Software geschrieben hatte verstarb plötzlich und die Firma wurde praktisch komplett aufgelöst und alle Mitarbeiter einschließlich des Geschäftsführers entlassen. Der einzige verblieben Mitarbeiter bin ich. Das Produkt für Digital Signage in Apotheken wurde einer anderen Größeren Unterfirma mit 150 Mitarbeitern zugeteilt.
Meine neue Firma ist 100% Microsoft. Leute verwenden Windows 10 Handys hier. Ich denke das ist Grund 3 warum digital Signage auf Windows läuft - Die Funktionalität ist mittlerweile zu "klein" um das einzige Produkt einer Firma zu sein. Das heißt das diese Funktionalität als "Zugabe" zu anderer auf Windows basierter Software entwickelt wird. Und keine Firma die Windows Software baut verwendet dann Linux oder etwas anderes.
Damit ist allerdings auch die Zukunft klar - der Kontrollserver wird auf ein Windows System umgestellt. Ich denke ich werde mich nach einen neuen Job umschauen.
Die Frage "Warum ist bei DS Systemen das Update ausgestellt" hat auch ein paar Erklärungen- Digital Signage Systeme haben keine Benutzerinteraktion also fallen die häufigsten Infektionswege komplett weg - der Webbrowser und Email. Das macht es auch dank der Probleme in der jüngeren Vergangenheit mit durch WU installierte Popups (Windows 10 Nag und Office 356) einfach WU einfach auszuschalten weil wirklich die einzige Sicherheitslücke die das System überhaupt beeinträchtigen kann ein Remote Code Excecution Exploit ist - und die sind selten :/
Bei uns war WU standardmäßig angeschaltet. Es gab allerdings immer wieder kleinere Probleme mit den entsprechenden Blasen und Popups die manchmal hoch kamen - die Windows 10 Nagscreens und die Office 356 haben allerdings dafür gesorgt das Windows Update bei allen neuen PCs aus war.
Ich sehe das Nichtupdaten bei Anzeigetafeln und ähnlichem Bullshit (mir fallen Spontan einige Industriesteuerungen ein, die zwar unter Debian laufen, aber im Prinzip das gleiche Problem haben): Gut gemeintes Firewalling.Der nächste Beitrag ist kein Leserbrief aber passt gerade so schön…Diese Kisten erreichen alle anderen Kisten im LAN (müssen sie, denn ich muss die möglicherweise warten), aber nicht das Internet. Daraus folgt, dass die Dinger über die Existenz von Updates überhaupt nicht informiert sind! Jetzt reicht aber, dass eine blöde Kiste im LAN hängt und den Mist verbreitet und alle Kisten fallen um.
Ein ähnliches Problem betrifft Rechner, die (aus Sicherheitsgründen oder weil sie einfach nicht gebraucht werden), garnicht oft am Netz sind.
Ich bin im Übrigen ganz klar gegen Haftungsgeschichten, die haben nämlich schon den Schienenfahrzeugmarkt erfolgreich monopolisiert und zerstört.
Einen hab ich aber noch:
Ich arbeite in einer Organisation (stolz auf ihr HighTech-Image) in der die IT, dass volle Program der Schlangenbeschwörung durchzieht, das ihr skizziert habt. Patches testen bevor man sie ausrollt, kumulieren. Schlangenöl auf allen Rechnern, Internet über Proxy, Microsoft blacklisten für "pöse Websites" (da ist dann auch schon mal das nameserver-config-interface von Schlund gesperrt), you name it…Es hat mich echt überrascht, dass ich bisher intern von einem wannacry-Befall nichts gehört habe.
Ich selbst war lange IT-Leiter in einer grösseren Unterabteilung, mit viel spezial Krams für Geräteansteuerung. So wie ihr das beschrieben habt, nur noch gruseliger.
Diese Lösungen sind oft in-house gestrickt von Leuten, die schon längst in Rente sind und die laufen eben. Und wenn man sie anfasst, fliegt es einem um die Ohren. Die stammen aus einer Zeit, wo es ausschliesslich darauf ankam, das etwas ans Laufen kam. programmiert haben das Leute, die ihre Gehversuche mit FORTRAN gemacht haben. Irgendwann haben sie sich C oder gar C++ beigebogen, aber immer noch Spaghetticode gemacht.
Wenn du das anfassen willst, musst du es von Grund auf neu machen. Also gehst du zu deinem Management und versuchst, ein Budget zu bekommen. Wenn du Glück hast, bist du in ein paar Jahren!!! so weit, dass du deine Kisten mal upgraden kannst. Meist kriegst du aber kein Budget. Und für Security gibt es ja Schlangenöl.
Wer entscheidet in Organisationen über die Bugjets? Das sind Leute, die sich für sehr wichtig halten und die fest daran glauben, was immer zu entscheiden ist, besser entscheiden zu können, als so ein Techie mit seinem schmalspurigen Blick auf die Welt. Das gilt für Produktionsanlagen und gilt erst recht für IT, denn der Manager hat ja daheim selbst einen PC und daher kennt er sich in IT besonders gut aus. Welche Erfahrungen haben diese Typen gemacht? Wenn man updates einspielt, geht danach irgentetwas nicht mehr. Das legt eine Teilaufgabe lahm, kostet Zeit und ist ärgerlich. Updates verändern die Applikation, so dass irgendetwas liebgewonnenes nun nicht mehr oder anders geht. Firmen nutzen Updates, um den Nutzer zu entmachten (die Digikam erkennt plötzlich den Akku aus dem Zubehör und spielt nur nach mit Originalakkus. Der Drucker verlangt nach HP-Patronen.) Kurzum, in ihrer Welt sind Updates von übel. Und das Internet war ehrlich gesagt bis dato nicht wirklich so gefährlich, oder? Mein damaliger Boss hatte nie einen Virus. Er war immerhin clever genug, nicht auf jeden Scheiss zu klicken. Und Backups hat er auch. Diese persönliche Erfahrung bestimmt weitesgehend seinen Managementstil. Also kriegst du kein Budjet, denn an anderen Stellen in der Bude brennt es viel dringender. (Z.B. braucht man Juristen, damit einem nix angeflickt wird oder so ….. jedenfalls keine Scheiss-Updates.)
Nun komme ich zu dem entscheidenden Punkt: Ihr habt das T-shirt mit der Aufschrift "told you so" erwähnt. Wenn du als kompetenter Manager im IT-Bereich auf Risiken hinweist, ist das so lang o.k., wie du nach einiger Quälerei überzeugen kannst und das Budjet zur Umsetzung einer Maßnahme bekommst. Es ist unerquicklich, wenn du dich nicht durchsetzen kannst und du mit dem Risiko weiter leben mußt, weil dir per Order die Hände gebunden sind. Am schlimmsten ist aber, wenn du recht behälst. Vermutlich kannst du, wenn die Katastrophe eintritt sogar noch einen "cover-my-ass-letter" aus denm guten alten Leitzordner ziehen. Das machst du einmal, vielleicht zweimal. Sowas vetragen Manager gar nicht. Ich bin kein IT-Leiter mehr. Zum Glück war für mich das Arbeitsrecht noch so hart, dass ich eine Weile gemütlich auf dem Abstellgleis verbringen durfte und in ein paar Monaten in Rente gehen werde.
Was wir verbreitet in allen Industrien haben, ist eine Managementkrise. Es ist nicht wirklich wichtig für die Zukunft zu denken. Wichtig ist, die Dinge so zu verwalten, dass man nicht persönlich zur Rechenschaft gezogen wird. Das was Gunther Dueck so treffend die anonymisierte Verantwortungslosigkeit nennt. Diese Art von Entscheidungkriterien betreffen auch die Securityfrage. Aber das war bisher eine winzige Baustelle im Vergleich zu anderen Ecken, wo mit dem Feuer gespielt wird.
Zurück zu wannacry. Das einzig wirklich neue ist die Erkenntnis, dass einem so ein Angriff potentiell so abschiessen könnte, dass man nicht mehr auf die Hufe kommt. Da ist er in der öffentlichen Warnehmung der erste Fall. (Falls er überhaupt so wargenommen werden wird. Was sind schon ein paar Krankenhäuser!)
Das ist eine lokale Privilege Escalation von root zu Kernel, d.h. in den meisten Fällen eher akademisch. Allerdings ist das möglicherweise durch Namespaces mancherorts trotzdem auch für Nicht-root zugreifbar? Bin ich mir gerade nicht sicher.
Mir ist bei dem Bug jedenfalls wichtig, dass er in vergleichsweise neuem Code ist. Häufig heißt es, der alte Code ist grausam und gruselig und höllisch, aber dem neuen Code vertrauen wird. Vertraut dem neuen Code nicht!
Gut, "neu" ist relativ. Der Bug ist ursprünglich von 2011, auch nicht sooo neu. Aber ihr wisst schon, was ich meine.
Update: Ein Einsender bestätigt, dass das per Namespaces auch für Nicht-Root zugänglich ist.
udp.c in the Linux kernel before 4.5 allows remote attackers to execute arbitrary code via UDP traffic that triggers an unsafe second checksum calculation during execution of a recv system call with the MSG_PEEK flag.Das klingt jetzt schlimmer als es ist, denn MSG_PEEK wird selten benutzt, UDP wird selten benutzt, und MSG_PEEK bei UDP wird noch seltener benutzt. Mir ist persönlich kein Fall bekannt.Ich habe dieses Flag in meiner Laufbahn 1-2 Mal benutzt. Man nimmt es, wenn man von einem Socket ein paar Bytes lesen will, ohne die zu lesen (d.h. wenn man danach nochmal read aufruft, kriegt man die Bytes wieder). Ich benutze das in gatling, um zu sehen, ob Daten auf einer SSL-Verbindung wirklich wie ein SSL-Handshake aussehen — allerdings auf einem TCP-Socket.
Kurz gesagt: Ich mache mir da jetzt keine großen Sorgen. Die DNS-Implementationen von glibc, dietlibc und djb benutzen jedenfalls nicht MSG_PEEK, und wenn es um UDP geht, ist DNS der übliche Verdächtige.
Ich will das nicht kleinreden, das ist ein ganz übler Bug und die sollten sich was schämen. Aber es ist kein "OMG die NSA hat mich gehackt, ich reinstalliere und mache alle Keys neu"-Bug. Außer ihr fahrt auf eurem Server irgendwelche UDP-basierten Protokolle.
Update: Im OpenVPN-Code findet grep auch kein MSG_PEEK. VPN und VoIP wären die anderen in Frage kommenden Codebasen.
Update: Ein paar Leser haben bei Debian und Gentoo mal ein bisschen rumgesucht und fanden als potentiell verwundbare Pakete dnsmasq und VNC-Implementationen. dnsmasq läuft praktische allen Plasteroutern. Das wäre in der Tat potentiell katastrophal.
Update: Einsender weisen darauf hin, dass systemd angeblich MSG_PEEK benutzt, und dass möglicherweise noch Chrome in Frage kommt als Angriffspunkt, wegen QUIC.
Welche ARM- (oder von mir aus auch MIPS oder PowerPC) Kleingeräte gibt es für wenig Geld zu kaufen, bei denen man dann einen Standard-Kernel selber bauen kann, und der funktioniert auch?
Das andere Gerät, bei dem ich in dieses Problem lief, ist ein Plasterouter, auf dem ich mal ein DD-WRT installieren wollte zum Testen, und da gab es nur eine Version von 2008 oder so, und neuere Kernel gehen nicht. Ja, äh, dann kann ich auch gleich Windows nehmen, wenn ich da keinen eigenen Kernel drauftun kann!
Ich empfinde es als zutiefst unseriös, ein Gerät als "da läuft Linux drauf" zu bewerben, auf dem dann nur ein spezifischer Gammelkernel läuft.
Auch auf Android-Smartphones scheint das ein massives Problem zu sein, wie ich aus zweiter Hand hörte. Sobald da mal was anbootet, ist das halt der Kernel für das Gerät und es wird nur noch das Userland außenrum geupdated, und vielleicht im krassen Notfall mal ein Security-Patch für den Kernel rückportiert.
Das kann doch nicht wahr sein? Ist das wirklich so?!
Update: Einsender empfehlen:
Ein anderer Einsender meint zu Allwinner noch:
ist dein RPI-Clone zufälligerweise ein Allwinner-Gerät? Das sind die beliebtesten China-SoCs. Sie sind ein wunderbares Beispiel für das Problem des "Code Vomittings". Die GPL zwingt Hersteller dazu, Code zu veröffentlichen? Wunderbar, erzeugen wir halt einen Code-Drop auf Github. Es gibt mit linux-sunxi.org eine Seite, auf der der Status für den Support im Upstream-Kernel sowie im eigenen "Fork" dokumentiert sein sollte. Die Situation ist nicht die beste, könnte aber schlimmer sein...
Update: Ein anderer Einsender meint:
the Allwinner ARM Chips do not belong on pole position. Too many critical missing features. A lot has changed in Kernel 4.11 but far from complete especially for the recent Allwinner ARM chips. too much red and WIP...
RaspberryPi is better supported and now also with mainline 64bit Kernel on RPi3.
https://michaelfranzl.com/2016/10/31/raspberry-pi-debian-stretch/
https://github.com/michaelfranzl/rpi23-gen-image
https://michaelfranzl.com/2017/03/21/zero-client-boot-kernel-root-filesystem-network-raspberry-pi2-pi3/
Hintergrund ist, dass ich ein Billo-Laptop mit Win10 als ersten Rechner für die Kinder gekauft habe, dort aber Linux drauf installieren wollte. Dank nicht ausreichender Recherche habe ich nun ein betroffenes Gerät. Es ist faszinierend zu lesen, wie die Intel-Entwickler seit über einem Jahr an diesem Bug herumsuchen, ohne dass die eigentliche Ursache gefunden wurde.
Update: Ein Einsender kommentiert:
den Bay Trail Bug, über den du geschrieben hast, den hat Intel meines Wissens nach schon vor einer Weile gefunden. Im Angehängten Dokument steht er unter VLP52. Kurz zusammengefasst: Wenn die CPU während einer Interrupt Service Routine in den C6-state wechselt, wird das EOI verschluckt, d.h. die Interrupts werden nicht wieder angeschaltet. Damit ist dann natürlich auch der Timer Interrupt weg und die Kiste hängt. Wohlgemerkt: Das betrifft nur C6, C7 ist ok. Der bessere "Fix" ist also, per sysfs alle C6-states zu deaktivieren, dann sind die Hänger weg, ohne dass der Energieverbrauch allzu kriminell wird.
Intel sagt in dem Dokument übrigens auch an, dass das nicht gefixt wird, weil das Problem in der Hardware liegt.
(Danke, Hanno)
Das einstige Prestigeprojekt LiMux war schon 2014 beim neuen Oberbürgermeister Dieter Reiter (SPD) in Ungnade gefallen, der sich unwidersprochen als Fan der Redmonder bezeichnen ließ und zu seiner Zeit als Wirtschaftsreferent dafür sorgte, dass Microsoft Deutschland seine Konzernzentrale von Unterschleißheim nach München verlegte.Oh ach so, die Verräterpartei! Na das ist ja mal wieder eine Überraschung!1!!
Wer jetzt dachte, das habe was mit Kosten zu tun, der möge sich mal dieses Randdetail durchlesen:
Zugleich räumte sie aber ein, dass in der IT-Abteilung in München viele Stellen unbesetzt seien, die Rede ist von 70 von 300. Die Lücken sollen dem Vernehmen nach durch Freiberufler zu Tagessätzen von 1500 Euro geschlossen werden.Was für eine Frechheit!
Mir hatte da übrigens vor einer Weile ein Insider eine lange Mail geschrieben, die ich mir für diesen Zeitpunkt aufgehoben hatte, aber ich finde sie gerade nicht mehr. Mist. Nun, da stand im Wesentlichen drin, was man sich so denken würde über deutsche Behörden. Beschissene Arbeitsatmosphäre, Inkompetenz und Ass Covering auf allen Ebenen, niemand geht irgendwelche Risiken ein, alle Reparatur- und verbesserungsmaßnahmen werden daher von unteren Mitarbeitern auf eigenes Risiko durchgeführt — und wir reden hier von sowas wie "Linux nicht nur einmalig von CD installieren sondern auch Patches einspielen". Das war eine Dystopie sondergleichen, die diese Mail schilderte. So ein Mist. Naja, denkt euch die Details selbst dazu. Kein Wunder, dass die 70 freie Stellen haben. Wer will in so einer Umgebung arbeiten?
Der Punkt der Mail war jedenfalls, dass an genau keinem Punkt Linux irgendeine Schuld hatte. Es gab da so Rahmenbedingungen wie "der Personalrat setzt pro Desktop-Änderung eine Neuschulung aller Angestellten durch", und so weiter. Und daraus folgte dann "keine Updates einspielen, nicht dass das optisch was ändert und wir alle Leute neu schulen müssen".
Die Mail erhob noch weitergehende Vorwürfe über Nepotismus und "die Ausschreibung wird von dem einen Zulieferer formuliert, damit er auch wieder den Zuschlag kriegt", aber betrachtet das mal noch mehr als Gerücht als den Rest der Vorwürfe. Der Einsender machte deutlich den Punkt, dass da keine technischen Probleme mit Linux oder Libreoffice das Problem waren. Wer schonmal mit Libreoffice gearbeitet hat, der wird verstehen, dass das eine starke Aussage ist :-)
Ich weiß nicht, ob der Einsender tatsächlich Insider war, insofern: mit einer Prise Salz nehmen. Aber es klang für mich schon authentisch nach Behördenkoller.
Update: Bei Netzpolitik.org liest sich die selbe Nummer gleich viel weniger endgültig.
Update: Ein Einsender erzählt:
Du musst mal mit jemandem reden, der mit dem Münchner System mit Externen kommunizieren muss oder, noch schlimmer, außerhalb von Büro und Bürostunden das System nutzen will. Hilfsweise tun es auch Anwender anstelle von IT-Experten oder Leuten, die sich dafür halten. Da geht in der Regel noch nicht mal die Mail, weil die das über die Jahre nicht gebacken gekriegt haben bzw. wollten, oder weil die Linux-Jungs und Mädels schlicht und ergreifend nicht begriffen haben, warum das jemand haben wollen könnte.
Das Linux-Projekt ist nicht an Linux gescheitert, sondern an der Ignoranz und der Hybris der IT-Verantwortlichen. Wenn man den Leuten noch nicht einmal in Ansätzen die Funktionalität gibt, die sie draußen oder zuhause haben, dann schieben sie das halt aufs System, und nicht auf die Verantwortlichen.
Ich habe seit einigen Jahren Kontakt zu Leuten in der Stadtverwaltung, die regelmäßig reisen: Wenn die kein privates Equipment mitnehmen, sind sie völlig incommunicado. Tödlich, wenn der Rest der Welt always on ist.
Ich dachte bisher, da gäbe es eine Korrelation mit der Abwärme der CPU/GPU. Aber jetzt habe ich auch den Effekt, dass ich beispielsweise / (also Shift-7 jetzt) zeitweise nicht eingeben kann. Nach ein paar Sekunden repariert sich das dann von selbst.
Meine Theorie war jetzt, dass da vielleicht ein Kontakt korrodiert ist. Also habe ich mal aufgeschraubt (ich muss übrigens sagen: Diese Clevo-Barebones sind in der Beziehung echt wartungsfreundlich. Kann echt nicht meckern) und nachgeguckt, aber die Kontakte sehen OK aus.
Jetzt bräuchte ich mal die Einschätzung eines Hardware-Fricklers. Sprechen die Symptome dafür, dass die Tastatur durch ist und mal getauscht werden sollte, oder wird das eher ein Mainboard-Problem sein? Ich müsste sogar noch Garantie auf das Gerät haben, aber wenn ich kann, würde ich gerne vermeiden, da mit irgendwelchen Support-Leuten unklarer Geschwindigkeit interagieren zu müssen. Eine Tastatur könnte ich auch kurz selber austauschen, wenn es sein müsste.
Update: Das Problem tritt unter Linux und Windows auf, und ist weg, wenn ich eine externe Tastatur benutze. Weil ohne externe Tastatur aber auch mehr Gewicht auf dem Laptop liegt, und damit möglicherweise einen Haarriss im Mainboard strapaziert, könnte es auch das Mainboard sein.
Update: Die Kommentare sagen mit deutlicher Mehrheit, dass das die Tastatur sein wird. Anscheinend ist das insbesondere bei Schenker-Notebooks sogar ein häufiger auftretendes Problem, aber Notebook-Tastaturen sind ja generell Verschleißteile.
getrandom ist ein neuer Syscall, der einem Zufall liefert, als würde man aus /dev/urandom lesen. getentropy ist ein Wrapper um getrandom, der, wenn der Syscall nicht verfügbar ist, halt /dev/urandom öffnet und daraus liest.
In neuen Code solltet ihr getentropy verwenden. Das API kommt von OpenBSD.
Wieso getentropy nehmen und nicht aus /dev/urandom lesen? Weil getentropy, wenn der Syscall verfügbar ist, nicht /dev/urandom öffnen muss, d.h. das Programm funktioniert auch in einem chroot-Jail, in dem der Admin /dev/urandom anzulegen vergessen hat.
Das OpenBSD-API sagt, dass getentropy höchstens 256 Bytes auf einmal liefern kann. Den getrandom-Syscall gibt es seit Linux 3.17.
Ich hatte Support für getrandom und getentropy in der dietlibc, seit ich von dem API gehört hatte, aber ich hatte die Prototypen nach unistd.h getan. glibc tut es nach sys/random.h. Ich habe dietlibc also jetzt geändert, auch sys/random.h zu benutzen.
Update: Oh und noch eine gute Nachricht: Wenn ihr openssh mit der neuen glibc übersetzt, sollte das direkt tun, denn ich habe vor einer Weile bei denen einen Bug gefiled, dass der getrandom-Syscall in ihrer Sandbox freigeschaltet werden muss. Haben sie sofort getan. Müsste also alles out of the box funktionieren.
Update: Es gibt noch andere Gründe für getentropy. Aus der Manpage zu getrandom:
If the urandom source has not yet been initialized, then getrandom()Das umgeht elegant ein wichtiges Sicherheitsproblem, wenn Geräte zum Bootzeitpunkt noch nicht genug Entropie gesammelt haben.
will block, unless GRND_NONBLOCK is specified in flags.
Update: Den Fallback-Code scheint es in glibc nicht zu geben. Ich nahm an, dass die den haben werden, weil glibc sonst für jeden Scheiß einen Fallback-Code hat, und ich natürlich in dietlibc auch einen Fallback implementiert habe.
Heute kauft man ein Telefon und das lädt erstmal ein paar Gigabytes Updates runter. Oder habt ihr mal ein frisches Windows installiert? Oder Linux? Bei Apple sieht das bestimmt auch nicht besser aus. Die Browser updaten sich auch alle erstmal. Was für eine Frechheit, eigentlich.
Ich hab meine Internetleitung für meine Nutzung gekauft, nicht damit Hersteller ihre Qualitätssicherung wegrationalisieren können und dann die Kosten auf mich externalisieren können!
Da gibt es gerade ein paar Details zu, und die sind durchaus spannend.
Die NSA suchte ganz bestimmte Mails, und Yahoo hatte eine Infrastruktur zum automatisierten Finden von Kinderpornos. Da hätte man sich also einklinken können, hat man aber nicht getan. Stattdessen:
The court-ordered search Yahoo conducted, on the other hand, was done by a module attached to the Linux kernel - in other words, it was deeply buried near the core of the email server operating system, far below where mail sorting was handled, according to three former Yahoo employees.Krass. Stellt euch mal vor, ihr findet da ein unerklärtes Kernelmodul auf eurem Mailserver. Was tut ihr da? Mal ne Untersuchung starten, nicht wahr? Hat Yahoo auch gemacht.In the case of Yahoo, company security staff discovered a software program that was scanning email but ended an investigation when they found it had been approved by Chief Executive Officer Marissa Mayer, the sources said.Und das muss man diesen Leuten aus dem Security-Team hoch anrechnen, dass sie dann nicht nur gekündigt haben, sondern diese Details jetzt ausplaudern. Das ist nicht risikofrei für sie.
durch das IT Sicherheitsgesetz ist nahezu der gesamte Mittelstand in heller Aufregung seit nun 1,5 - 2 Jahren und sucht händeringend "BSI zertifizierte Sicherheitsanbieter" um in diversen Audits von Wirtschaftsprüfern o. ä. irgendwelche Zertifikate vorzeigen zu können, dass sie auch wirklich "sicher" sind - genau das wird zur Zeit gefragt.Ich bin ja nicht zertifiziert und kann mich auch nur an eine Anfrage erinnern, wo jemand ein "Pentest-Zertifikat" angefragt hat. Ich habe dann zurückgeschrieben, was für ein Zertifikat ihm denn da vorschwebt, und er schickte mir die URL von irgendeiner Kali-Linux-Showbiz-Bude (die halt rumtourt und "live hacking" vorführt). Ich schrieb zurück, dass der Typ, der diese Bude gegründet hat, mehrere Jahre weniger im Geschäft ist als meine Firma :-)Da in meiner Firma z. B. niemand den Kopf hinhalten wollte CISO (Chief Information Security Officer) zu werden, hatte mein Chef (IT Leiter) die glorreiche Idee, mich (ehem. sehr schlechter Java 'Programmierer', Linux Nutzer, nun IT-compliance Beauftragter und kleinster und billigster IT-Abteilungsleiter in der Firma) kurzerhand per Dekret zum CISO zu ernennen… Ich habe dann zwangsweise einige Verkaufsveranstaltungen besuchen müssen - bei HP, bei der Telekom, usw… das lief dann immer so ab, dass sie dort irgendein Subunternehmen engagiert hatten [alienvault oder so ähnliche], die dann "Livehacks" mit einem Kali-Linux vorgeführt haben und dann gezeigt haben, wie ihre Standard-Linux-Tools mit bunter neuer grafischer Oberfläche und variablem Firmenlogo als gemietete on-premise Lösung hinter der Firmenfirewall (!) das erkennen können und Alarm schlagen. Sie selbst bieten dann 24/7 Support und <30 min Reaktionszeit - der den Mittelstand dann (Zitat) "12 Vollzeitstellen" kosten würde, was sich niemand leisten kann und der Markt - gerade wegen des Sicherheitsgesetzes - diesbezüglich leer ist, und jeder der Sicherheit schreiben und einen Kali-USB-Stick booten kann zur Zeit eingestellt wird.
Ich habe 4 Monate gebraucht, um diesen tollen CISO Titel wieder loswerden zu können. Ich habe meinem Chef belegen können, dass ich als ehemals arbeitsloser Biologe eventuell doch nicht die technische Kompetenz und Ausbildung besitze, diesen verantwortungsvollen Job so auszuführen, wie er nötig wäre und konnte mir dann weitere Verkaufsveranstaltungen ersparen. Wir sind inzwischen bei Antago gelandet.
Ich schreibe das, um zu erklären, warum die Telekom das anbietet - und vor allem zu erklären, warum es wirklich einen sehr großen Markt gibt, der diesen Schwachsinn sogar nachfragt…
Also ich weiß ja echt nicht, was dieser Live-Hacking-Scheiß immer soll. Erkenntnisgewinn ist Null, da ist auch nichts "actionable", wie man so schön sagt. Reine Blender-Veranstaltung und Geldverschwendung, aus meiner Sicht.
Ich saß ja gestern in der Bahn gegenüber von einem Mann, den ich erst für einen Bühnenmagier oder so hielt, von seinem Äußeren her. Dunkler Anzug, hochgegelte Frisur, und trug eine Fliege. Aber die Schuhe waren dann zu teuer für das Bühnenmagier-Klischee, und als der dann zu telefonieren anhob, habe ich mich an einer Stelle hervorragend amüsiert. Da schlug er nämlich der Gegenseite vor:
Laden Sie einfach alle aus, die eh nichts zu sagen haben.Mensch, brillant! Wieso sind wir da nicht selber drauf gekommen? :-)
Aber so kommt mir gerade die ganze Branche vor. Lauter so Showbiz-Leute, die sich gegenseitig zu blenden versuchen, und dann irgendwann merken, dass die Leute, die was zu sagen haben, keinen Bock auf diesen ganzen Showbiz-Scheiß haben und lieber mit seriösen Gesprächspartnern an konkreten Lösungen arbeiten wollen würden.
Aber ja! Microsoft joins the Linux Foundation as a Platinum member.
Update: Außerdem: Google joins Microsoft's .NET Foundation und Visual Studio for Mac gibt es jetzt als Prerelease, und das reguläre Visual Studio kriegt Android-Support und kann Code für Linux erzeugen.
Diese Einsicht ist an sich schon ein paar Monate alt, aber das war irgendwie an mir vorbeigegangen bisher.
Stellt sich natürlich direkt die Frage, ob die Linux-Treiber auch solche Funktionalität beinhalten.
Remote code execution vulnerability in kernel ASN.1 decoder
Remote code execution vulnerability in kernel networking subsystem
Elevation of privilege vulnerability in MediaTek video driver
Elevation of privilege vulnerability in kernel shared memory driver
Vulnerabilities in Qualcomm componentsUnd dazu noch 1-2 Dutzend Privilege Escalations in irgendwelchen Komponenten, über die ich mir aber nicht so viel Sorgen machen würde wie über einen "Remote code execution vulnerability in kernel networking subsystem". WTF? Hat davon jemand schon mal was gehört?Und dass es eine bescheuerte Idee war, einen ASN.1-Parser in den Kernel zu tun, das war ja wohl auch von Tag 1 klar. *Seufz*
Ich finde die Informationspolitik der Linux-Kernel-Leute an der Stelle übrigens absolut unentschuldbar. Wenn ihr eine remote code execution Vuln im Kernel habt, dann SAGT HALT BESCHEID! Meine Güte!
Update: Der RCE im Network Stack sieht beim Angucken von dem diff weit weniger übel aus. Auf den 1. Blick würde ich sagen, das betrifft überhaupt nur Leute, die recvmmsg aufrufen (und ich kenne keinen Code, der das aufruft). Der Call ist Linux-spezifisch und ist ein Performance-Hack, über den man mit einem Syscall Dinge von mehreren Deskriptoren auf einmal lesen kann. Da müsste man aus meiner Sicht also auf der Kiste selbst kaputten Code zum Laufen bringen, und damit ist das "nur" noch ein local privilege escalation. Ich hab jetzt aber auch nicht sooo genau hingeguckt, habe hier ja gerade selber die Hände voll mit dem gatling-Problem :)
We demonstrate that our attack can reliably recover kernel ASLR in about 60 milliseconds when performed on a real Haswell processor running a recent version of Linux.Man muss dazu wissen, wo im Zielcode ein Jump ist, aber häufig weiß man das.
Stellt euch zum Beispiel vor, dass ihr einen Container nicht verändern dürft (und das heißt auch: keine non-const Reference übergeben!), solange noch ein Iterator auf diesem Container existiert. Rust hat einige echt großartige Ideen an der Stelle, und das Versprechen von Rust ist, mit Memory Corruption als Fehlerklasse Schluss zu machen.
Nun ist Rust leider aus dem Mozilla-Umfeld, die eher für Verkacken bekannt sind als dafür, dass in endlicher Zeit etwas rauskommt, das dann auch noch funktioniert. Aber Rust scheint die eine Ausnahme in dem Porfolio von Mozilla zu sein, wo das wirklich so ist.
Ich beobachte das jedenfalls fasziniert aus der Ferne und wünsche alles Gute.
Das Hauptproblem bei sowas ist ja, dass in der Praxis die gruseligen Codebasen, die sowas wirklich brauchen würden, so Dinge wie Firefox sind. Viel zu groß, als dass man da realistisch etwas tun könnte, so jedenfalls der übliche Einwand. Und dann kommen die Mozilla-Leute und schreiben eine HTML5-Layout-Engine in Rust.
Ich bin verhalten optimistisch. Aber naja, eine Layout-Engine ist ja eine Sache, aber was ist denn mit den ganzen Codecs? Und dem Font Rendering? Ich persönlich traue ja den ganzen Font-Render-Engines nicht so weit, wie ich einen Kleinwagen werfen kann.
Und es stellt sich raus: ist in Arbeit (bisher nur der mp4-Container, nicht die tatsächlichen Codecs; aber hey, man muss ja irgendwo anfangen) und Font-Rendering ist auch in Arbeit!
Und dabei kommt dann plötzlich raus, dass Font-Rendering mal eben um fast eine Größenordnung schneller geht als bisher (der Vergleich geht gegen Truetype, was unter Linux und Android die Standard-Engine ist)!
Warum erwähne ich Android extra? Weil der Typ, der das macht, aus der Android-UI-Ecke kommt!
Das heißt auf der einen Seite, dass wir hier schon wieder Google zu danken haben, die ihr Geld für Dinge ausgibt, die uns allen helfen, und zweitens dass Android möglicherweise auf den Rust-Zug aufspringt. Und natürlich alles schön Open Source und auf Github.
Es sind Meldungen wie diese, die mir ein verhaltenes Gefühl der Hoffnung auslösen. Vielleicht kriegen wir den ganzen Scheiß doch noch geregelt.
Update: Es schreiben auch Leute an einem Betriebssystem in Rust.
Das schöne an dem Gerät ist, dass man da auf relatig gut dokumentierte Art und Weise eine größere SSD einbauen und Linux parallel installieren kann, und dann hat man ein nahezu vollwertiges Linux-Netbook. Nachteil: Hat nur 2GB RAM, damit muss man halt klarkommen. Aber war in der Praxis nie ein Problem.
Ich dachte mir gerade, ich kauf da noch einen von, aber die sind wohl ausgelaufen und nur noch hie und da gebraucht verfügbar.
Hat zufällig jemand einen Überblick über die anderen aktuellen Chromebooks, ob es ein Modell mit ähnlichen Rahmenbedingungen gibt?
Das war so ein guter Kauf, dass ich mich rückblickend echt ärgere, nicht gleich zwei gekauft zu haben.
Ich hatte da übrigens zum Testen ein Arch-Linux draufgetan, um das mal irgendwo im Einsatz zu haben, und kann die Distro auch nur empfehlen. Ich fahre sie modifiziert, mit eigenem Kernel und ohne systemd, dafür mit minit. Aber so das Paketierungs- und Update-Konzept überzeugt mich bisher.
Update: OK also es stellt sich raus, dass das C720 Nachfolger-Modelle hat. Das C730 sollte man vermeiden, aber das aktuelle heißt C740 und ist vergleichbar. Das gibt es auch in einer 4GB-Variante, aber nicht in Europa. Überhaupt muss man sagen, dass die Chromebook-Auswahl in Europa nur so ein Drittel bis die Hälfte dessen ist, was man in den USA kriegen kann (nur halt mit US-Keyboard dann; manche stehen auf das US-Keyboard-Layout, ich habe lieber das DE-Layout, fürs Bloggen will ich Umlaute haben). Und dann die Preisunterschiede. Hier in den USA $149.99, hier in Deutschland 380 €. Was für eine Frechheit. Und dann wundern die sich immer, dass der Chromebook-Markt in Deutschland schwächelt.
Update: Jemand weist darauf hin, dass das 720 einen core-Prozessor hat, das 740 einen Atom. Vielleicht gibt es da verschiedene Modelle? Ich sah hier was von Celeron 3205U, und das ist ein Broadwell, kein Atom.
Update: Der eine Amazon-Vergleichslink geht offenbar zu dem falschen Produkt. Seufz.
Besonders beunruhigend:
Remote code execution vulnerability in OpenSSL & BoringSSLNanu? Neue Lücke? Nein! Die hier! Seit Mai bekannt. Redhat hat (um nur mal ein Beispiel für eine andere Linux-Distribution zu nennen) seit dem 10.5. ein Patch draußen. Android wird jetzt gefixt. Ein Bug, den sie als "remote code execution" einschätzen und selbst als kritisch einstufen.
Soll das ein Scherz sein? Ist das der Versuch, Microsoft weniger lahmarschig aussehen zu lassen?
Naja auf der anderen Seite ist das Bulletin auch schon wieder fast nen Monat alt. Keine Ahnung, wieso das jetzt erst die Runde macht.
Wenn man das nicht explizit ausgeschaltet hat, probiert er es dann nochmal ganz ohne Verzeichnisnamen, d.h. direkt foo/bar.html.gz. Das ist schön flexibel, aber der Worst case sind sechs open-Syscalls.
Um das ein bisschen einzuschränken, probiert gatling www.fefe.de:80 bzw. default per chdir, nicht als Pfadbestandteil von open. Aber da ist immer noch viel Optimierungspotential.
Die offensichtliche Optimierung wäre, dass man einen Cache einführt. Die Dateien nicht immer gleich wieder zumachen und neu öffnen, sondern offen behalten. Das hätte auch gleich den Vorteil, dass wenn fünf Leute die selbe Datei downloaden, dass ich die dann nur einmal öffnen muss, und nur ein Handle ausgeben muss. Der Nachteil wäre, neben der dann nötigen Buchhaltung, dass ich mitkriegen muss, wenn eine der Dateien sich ändert oder weg ist. Und das stellt sich als recht aufwendig heraus.
Das Standard-API unter Unix ist, einfach alle paar Sekunden per stat() nochmal nachzugucken. Unix Linux gibt es ein Spezial-API, mit dem man sich unterrichten lassen kann, wenn sich eine Datei ändert. Das klingt gut, aber es ist nicht das, was ihr euch jetzt intuitiv vorstellen mögt.
Nehmen wir mal an, ich öffne die Datei www.fefe.de:80/foo/bar.html.gz und nutze dieses API, um über Änderungen informiert zu werden. Nehmen wir weiter an, eines der Verzeichnisse in dem Pfad wird umbenannt. Dann würde mir dieses API nicht sagen, dass sich die Datei geändert hat, denn sie hat sich ja nicht geändert. Sie ist nur unter dem Namen nicht mehr ansprechbar. Schlimmer noch: Was, wenn es www.fefe.de:80 nicht gab und gatling daher default genommen hat, und dann legt jemand ein Verzeichnis oder Symlink unter dem Namen an?
Ich müsste also mit dem Spezial-API nicht nur die Datei sondern alle Pfade auf dem Weg überwachen. Das ist ja schon mal echt unschön.
Aber jetzt denken wir mal einen Schritt weiter. Was wenn einer der Pfade ein Symlink ist, und der verweist, sagen wir mal, auf /mnt/platz, und jetzt ändert jemand unter /mnt die Namen, so dass sich das Ziel des Symlinks ändert?
Mir erscheint gerade, dass dieses API zwar in der Theorie schön klingt, aber in der Praxis ungeeignet ist.
Ein Ausweg wäre vielleicht, dass man einfach alle gecacheten Deskriptoren nach 10 Sekunden wegschmeißt. Aber das ist ja iiih-bäh.
Kennt zufällig jemand einen httpd, der so eine Optimierung, wie ich sie mir vorstelle, implementiert hat?
Update: nginx hat so eine Option, und lighttpd hat einen stat()-Cache. Allerdings sind die beide so Heuristiken, die ich gerne vermieden hätte. Vielleicht bin ich da unrealistisch, aber mein Anspruch an ein modernes Betriebssystem von 2016 wäre, dass man da ohne so Gammel-Heuristiken und „na ich liefer doch aber höchstens 10 Sekunden lang was falsches aus“ arbeiten kann.
Mich würde mal interessieren, wieviel davon ein reines Windows-Problem ist, und wie doll Chrome plattformübergreifend stinkt an der Stelle. Von Apple-Usern hört man ja auch, dass ein Laptop im Akku-Modus mit Safari deutlich länger durchhält als mit Chrome.
Ich habe das bisher nicht gemessen, aber mir ist unter Linux aufgefallen, dass die Videocodecs in Firefox schlecht sind (wobei das vermutlich vp9 ist). Youtube in Fullscreen (4k) flutscht mit Chrome, aber mit Firefox ruckelt und wackelt es.
Nur mal so als Datenpunkt muss ich aber sagen, dass ich die längste Batteriezeit beim Webklicken bisher mit Chromebooks erlebt habe.
Wie überhaupt jemand auf die Idee kommen konnte, einen ASN.1-Parser in den Kernel zu tun, erschließt sich mir nicht. Das ist auf der Scheißidee-Skala kurz vor "wir tun GDI inklusive Font-Parsen in den Kernel".
Falls jetzt jemand denkt, hey, kleines Fehlerchen, passiert bestimmt nicht wieder: Es gab da noch einen zweiten ASN.1-Parser im Kernel.
Unklar. Darum ging es aber nicht. Es ging um den Ausdruck, mit dem das beworben wird:
Based on proven technology either from Red Hat Enterprise Linux or the CentOS and Fedora projects, Atomic Host is a lightweight, immutable platform, designed with the sole purpose of running containerized applications.Immutable Platform! Mit anderen Worten: Gibt keine Updates, keine Patches. Wenn Bug dann kaputt. Dann rollt man halt eine neue Version komplett von Scratch aus.Das an sich ist ja noch nicht so bemerkenswert, so macht man das ja schon immer, wenn man einen Cluster aus Maschinen hat. Dann hat man pro Maschine ein Image, das wird automatisiert gebaut, und wenn ein Update reinkommt, rollt man das neue Image aus.
Den Begriff "immutable platform" kannte ich dafür aber noch nicht und amüsiere mich gerade darüber, wie "kann nicht geupdated werden" jetzt plötzlich von einem Gegenargument zu einem Marketing-Vorteil umgemünzt wurde.
Wir leben in interessanten Zeiten!
Wer ein diff und patch für Binärdateien sucht, für den gibt es leider kein Standardtool. Es gibt da diverse Tools auf dem Markt, das bekannteste ist xdelta, aber es gibt auch bsdiff, BDelta, bdiff (lag mal auf Sourceforge herum, aber scheint verloren gegangen zu sein; ich hatte hier noch einen Tarball für Version 1.0.4 herumliegen), jptch/jdiff und sicher noch mehr, die ich nicht kenne.
Mein Anwendungsfall war, dass ich hier ein ISO-Image einer Linux-Distribution ändere, und gerne davon wegkommen wollte, immer das ganze ISO übertragen zu müssen. Und so ein ISO, das sind mal eben 4 GB oder so.
Bei solchen Datenmengen trennt sich die Spreu vom Weizen. Ich nehme im Wesentlichen das unveränderte ISO-Image und füge ein paar Dateien dazu. Meine Erwartungshaltung war: Der Patch sollte 1 MB nicht überschreiten.
xdelta rödert länglich herum und erzeugt einen mehrere hundert MB großen Patch (ich nehme das ISO und füge ein paar Dateien dazu, wir reden hier von sowas wie 100 KB zusätzlichen Dateien). Da brach ich ab.
bsdiff versucht, die ganze Datei (mit read statt mmap!) in den Speicher zu lutschen und failed dabei, weil read() von 4 GB unter Linux nur 2 GB liefert. Ich weiß nicht, welcher Vollpfosten das bei Linux entschieden hat. In meinen Augen ist das ein Bug. War wahrscheinlich ein gut gemeintes Security-Theater oder so. bsdiff ist also auch ausgefallen.
jojodiff rödelt anderthalb Minuten und erzeugt dann 1,3 MB. Geht doch!
bdelta braucht 10 Sekunden (!?) und erzeugt einen Patch von 1,6 MB. Der funktioniert dann leider nicht. Wie sich rausstellt, ist das Dateiformat von bdelta hirnrissig und failed nicht wie im README dokumentiert ab 4 GB sondern schon vorher. Für das Abspeichern der relativen Offsets zwischen Quellen für Patches nimmt der 32-bit signed Integer, und prüft natürlich auch nicht, ob der Wert, den er abspeichern will, auch passt. bdelta ist aber ansonsten ausgesprochen sympathisch, weil der Quellcode so winzig und unprätentiös ist, und das Format so trivial. Also habe ich mal einen Patch gemacht, damit er die Integer mit variabler Länge abspeichert (ich nehme dafür das Verfahren von den Google Protocol Buffers, das ist ganz schlau wie ich finde). Das ganze Ding platzt wahrscheinlich immer noch bei Dateien über 4 GB, aber für meinen konkreten Anwendungsfall tut es ganz gut.
Weil das Projekt soweit verlassen wirkt, tu ich den Patch mal auf meinen Webserver, falls das jemand braucht.
Update: Ein langjähriger Leser weist darauf hin, dass ich die Gründe für das 2 GB-Limit schon mal erklärt hatte. Mein Kumpel Erdgeist prüft das übrigens gerade unter BSD, und zumindest OS X hat auch ein 2 GB-Limit, sogar dokumentiert bei readv.
Update: Unter den freien BSDs hat read() auch ein 2GB-Limit. WTF!?
Update: Einige Leser haben herausgefunden, dass man unter FreeBSD das 2GB-Limit mit den sysctls debug.devfs_iosize_max_clamp und debug.iosize_max_clamp abschalten kann.
Und früher war das vielleicht mal ein Argument. Als man für den Einbau einer Festplatte noch SCSI-Kabel legen und eine Blutspende des Admins abgeben musste.
Selbst wenn bösartige USB-Sticks in aller Munde sind, endet die Debatte häufig bei Autoruns. Aber was wenn da jemand ein bösartiges Filesystem drauftut? Ich persönlich fand ja, dass das schon seit iSCSI und Fibre Channel und so nicht mehr wegzudiskutieren ist als Problemklasse.
Und so freut es mich sehr, dass es da jetzt einen konzertierten Anlauf gibt, die Filesysteme unter Linux mal robuster zu machen. Es geht ja nicht nur um Security. Man will ja auch nicht, dass der Kernel panict, nur weil auf einer alten Gammelplatte ein paar Bits geflippt sind.
Die Ergebnisse sind ungefähr, wie ich sie erwartet hätte. ext4 hat am längsten durchgehalten (deshalb setze ich das auch überall ein). Am schnellsten ist btrfs gestorben. XFS hielt erstaunlich lange durch, aber nicht so lange wie ext4. Naja und die ganzen Novelty-Filesysteme sterben natürlich alle recht schnell. Da sind die Autoren ja froh, wenn der Code durch-kompiliert.
Man muss dazu sagen, dass das nicht einfach nur ein Dumb Fuzzer war, sondern AFL, das ist ein adaptiver Fuzzer mit einer Art genetischem Programmieren. Der instrumentiert den Code und baut dann Testcases, um die Coverage zu maximieren, um jede Kombination aus Codepfaden mal genommen zu haben. Das Ding ist State of the Art. Wenn Code das überlebt, haben die Programmierer was richtig gemacht.
Update: Oh und jetzt kann man auch noch mit Visual Studio Linux-Binaries bauen!
This specific flaw in Apple’s iMessage platform likely would not have helped the FBI pull data from an iPhone recovered in December’s San Bernardino, Calif., terrorist attack, but it shatters the notion that strong commercial encryption has left no opening for law enforcement and hackers, said Matthew D. Green, a computer science professor at Johns Hopkins University who led the research team.
Erstmal gibt es von RPM direkt zwei Stränge, RPM 4 und RPM 5, und beide behaupten von sich, das "offizielle" RPM zu sein. Lolwut?
Gut, hole ich mir RPM 4, weil das auf der Zieldistro eingesetzt wird. Kompiliert nicht. Will NSPR und NSS haben, aber guckt nicht in den Default-Install-Pfaden, konsultiert nicht nspr-config, was genau dafür da ist, und fragt nicht pkg-config, was auch genau dafür da ist. Nein. Und findet es dann natürlich nicht.
OK, überschreibe ich $CC, findet er das. Und findet dann Berkeley DB nicht. Berkeley DB? Srsly? Ist systemweit installiert. Klar, könnte man nehmen. Will man aber nicht. Nein, RPM will die Sourcen in seinem Quell-Tree haben und dann neu bauen. Gut, lege ich ihm das hin.
Stellt sich raus: Einfach ein RPM zu den anderen RPMs auf dem Install-ISO tun reicht nicht. Nein. Man muss da auch "repodata" neu erzeugen. Und das kann RPM nicht.
Natürlich nicht! Warum auch?
Dafür braucht man ein externes Tool namens createrepo. Das ist in Python.
Da gehen ja bei mir direkt alle Warnlampen an.
Installiere ich das also. Rufe es auf. Geht nicht. Braucht yum. Auch ein Python-Tool. Die zweite Riege Warnlampen geht an. Installiere ich also yum. Rufe es auf. Geht nicht. Braucht das rpm-Modul. Wie, ist das nicht bei RPM dabei?
Doch, ist es. Aber RPM installiert das nicht, außer man bittet explizit darum.
Also nochmal RPM gebaut. Rufe yum auf. Geht nicht. "No module named sqlitecachec". Oh super! Wo kriegt man das her? Steht da nicht. Warum würde das da auch irgendwo stehen? Ist ja nicht so, als wäre das hier alles die zentrale Software, auf der eine "Enterprise"-Distribution aufsetzt! Warum sollte das einfach so funktionieren?
Googelt man das also, findet keine Homepage. Nee, warum auch. Man findet diverse Distro-Pakete. Oh, das kommt von "yum-metadata-parser"! Na da hätte man ja auch direkt selber drauf kommen können!1!! 2010 zuletzt angefasst.
yum geht. createrepo immer noch nicht. Braucht "deltarpm". Sagt mal, soll das hier ein Scherz sein? Sogar der Rotz von Gnome prüft vor dem Bauen, ob die Abhängigkeiten erfüllt sind!
Oh und wer hat sich denn bitte das RPM-Dateiformat ausgedacht?! Was soll das werden? Soll das außerirdische Invasoren in den Wahnsinn treiben, damit sie nicht die Menschheit ausrotten können? Heilige Scheiße. Dagegen ist ja der Debian-Kram einleuchtend und selbsterklärend! Und selbstdokumentierend gar. Wie ein .deb funktioniert, kann man mit file und Hausmitteln rausfinden, man braucht nicht mal einen Hex-Editor.
Meine Güte. Und ich kenne ansonsten durchaus zurechnungsfähige Leute, die schwören auf CentOS!
Update: Vielleicht sollte ich mal sagen, wie ich mir so ein Paketverwaltungstool vorstelle. Meine Anforderung wäre, dass das immer funktioniert. Python zerschossen? Perl nicht installiert? glibc-Update in der Mitte fehlgeschlagen? Der Paketmanager muss noch gehen und das noch retten können. Und er muss klein genug sein, um mit Metadaten in 5 MB zu passen. Muss auch ohne OpenSSL und curl und wget arbeiten können, zumindest im Notfall. Von den Systemen, die ich bisher gesehen habe, gefällt mir pacman (Arch-Linux) am besten. Aber da geht noch was.
Update: Erwähnte ich, dass repodata dann XML und Sqlite ist? Geht's noch? Wieso habe ich dann Berkeley DB in RPM reinlinken müssen? Oh und wenn mir der Distro-Installer während der Installation Werbung anzeigt, habe ich da überhaupt kein Verständnis für.
Update: Wobei mir die Übung ja wenigsten eine Sache klar gemacht hat. Jetzt verstehe ich, wieso überall diese Cloud-Spezial-Distros aus dem Boden sprießen. Das "Minimal"-Redhat ist 1GB groß nur für Code. Und da ist dann kein netstat bei.
Droid Sans hat den Nachteil, dass O und 0 praktisch nur schwer unterscheidbar sind. Bei Roboto Sans hat die 0 einen Querstrich.
Leider lässt sich unter Windows Roboto Mono nicht auswählen, weil Google beim Erzeugen der Truetype-Dateien ein Flag nicht gesetzt hat.
Früher war man dann aufgeschmissen, weil man größere Ausgaben für ein kommerzielles Tool ausgeben musste. Heute gibt es für solche Minimal-Eingriffe ein Python-Tool namens TTX. Das kann Binär-Fontdateien nach XML und zurück wandeln. So kann man dann mit TTX aus RobotoMono-Regular.ttf ein RobotoMono-Regular.ttx machen, das mit vim oder sed editieren (das Flag heißt isFixedPitch) und dann daraus wieder TTF-Dateien machen, und wenn man die dann unter Windows installiert, dann nimmt auch vim Roboto Mono.
Ich dachte mir, ich erwähne das hier mal, denn das Wissen um TTX scheint mir nicht sehr weit verbreitet zu sein.
Update: Ich wollte mir gerade einen Github-Account machen, um einen Bug melden zu können, aber Github schafft es nicht, mir die Verifikationsmail zuzustellen. Nicht weil mein Spamfilter die abfängt, bei mir kommt nicht mal ein Versuch an.
Das hab ich nicht kommen sehen, und ich frage mich, wie ernst sie das meinen. Bei Skype ist ja die Linux-Version weitgehend eingeschlafen, seit Microsoft die gekauft hat. Ist das jetzt bloß ein Marketing-Gag oder supporten die Linux ernsthaft als Plattform jetzt?
Oh und die nächste Frage ist: Sorgen sie dafür, dass das langsamer läuft als unter Windows? Um ihre Server-Produkte nicht zu gefährden?
Völlig gaga. So langsam frage ich mich, wieso die Leute dann überhaupt noch dynamisch linken.
Viel Spaß beim Spielen!
Eine wichtige Sicherheitstechnologie ist, dass man dafür sorgt, dass die Shared Libraries nicht immer alle an der selben Adresse geladen werden. Es geht darum, Angreifern das Ausnutzen von Sicherheitslücken zu erschweren. Dieses Verfahren heißt ASLR.
Unter Linux ist das umgesetzt, indem mmap die Speicherbereiche randomisiert, d.h. ld.so muss gar nicht viel dafür machen. Jetzt gibt es zwei Probleme. Erstens ist ld.so ein Executable, keine Shared Library, d.h. es wird nicht an eine zufällige Adresse geladen, sondern an eine statische. Zweitens ist das Hauptprogramm ein Executable, keine Shared Library. Der ld.so von glibc ist deshalb jetzt doch eine Shared Library, um dieses Einfallstor zu schließen. Aber das Hauptprogramm landet doch immer noch immer an der selben Adresse, außer — ja außer, man kompiliert es mit -pie. Im Grunde gibt es gar keinen echten Unterschied zwischen Hauptprogramm und Shared Library in ELF, außer dass das Hauptprogramm im Header eine Adresse stehen hat, an die es geladen werden will, und die Shared Library kann irgendwohin geladen werden. Wenn man also ASLR in allen Komponenten haben will, dann müssen alle Komponenten ELF-technisch Shared Libraries werden.
So, was ist jetzt mit dietlibc. dietlibc erzeugt statische Binaries, d.h. ohne ld.so und ohne libc.so. Das ist ja gerade die Idee bei der dietlibc. Ich fragte mich jetzt, ob ich es nicht hinkriegen kann, ein statisches Binary zu erzeugen, dass der Kernel hinladen kann, wo er will. Erstmal geht es mir nur um meine Entwicklungsplattform, AMD64. Dort und bei x86 insgesamt ist es so, dass ein Funktionsaufruf zu "call 1234" wird, aber 1234 ist nicht die absolute Adresse, an die man hinspringen will, sondern relativ zur aktuellen Position des Instruction Pointer. Wenn die Calls alle relativ innerhalb des Code-Moduls sind, dann ist es auch egal, an welcher Stelle im Speicher das liegt.
Speicherzugriffe auf Variablen laufen bei x86 aber über absolute Adressen. Auf dem 32-bit x86 hat man dann ein Problem, denn man kann keine Adressen in Relation zum aktuellen Instruction Pointer konstruieren. Bei AMD64 ist das anders, daher dachte ich, wenn ich mich erstmal darauf konzentrieren, dann ist das ein Selbstläufer. Ist es leider nicht.
Das Problem ist, dass ich anscheinend der erste bin, der das machen will. Alle anderen wollen normale dynamische Binaries erzeugen, und da laufen alle Zugriffe über die Glue-Datenstrukturen. Mein erstes Problem ist, gcc zu sagen, dass er diese Datenstrukturen bitte nicht benutzen soll. Mein aktueller Ansatz dafür ist -fvisibility=hidden, aber das hilft leider nur ein bisschen. Für in Headern als "extern" deklarierte Symbole hilft es nicht.
Gut, dachte ich mir laut seufzend. Dann muss mein Startup-Code halt ran. Ich kompiliere also meinen Code mit -fpic -fvisibility=hidden und linke daraus erfolgreich eine Shared Library. Wenn ich die aufrufe, wird mein Startup-Code ausgeführt. GOT und PLT sind eh schon in den Speicher gemappt (das sind diese Glue-Datenstrukturen). Da stehen nur noch falsche Dinge drin. So schwer kann das ja wohl nicht sein. Ich fange also an, da ein bisschen Code zu schreiben, und scheitere gerade an trivial anmutenden Details.
Und zwar habe ich in meiner "shared library" ja keinen ELF Interpreter ("ld.so") drin. Woher weiß denn mein Code, wo die GOT ist? Das steht in ELF-Datenstrukturen, die Teil der Shared Library sind. Die mappt der Kernel in den Speicher. Ich weiß nur nicht, wo die genau sind. Der Mechanismus dafür heißt AUXVEC. In C ist das Hauptprogramm ja die Funktion main(), und die kriegt die Kommandozeilenargument und das Environment übergeben. Das Environment ist ein Array von char*, und NULL markiert das Ende der Liste. AUXVEC ist einfach dahinter im Speicher. Wer das mal sehen will:
% LD_SHOW_AUXV=1 /usr/bin/trueDa steht bei mir sowas hier:
AT_SYSINFO_EHDR: 0x7ffc0ab78000 AT_HWCAP: bfebfbff AT_PAGESZ: 4096 AT_CLKTCK: 100 AT_PHDR: 0x400040 AT_PHENT: 56 AT_PHNUM: 8 AT_BASE: 0x7fa6e6d65000 AT_FLAGS: 0x0 AT_ENTRY: 0x401460 AT_UID: 1000 AT_EUID: 1000 AT_GID: 100 AT_EGID: 100 AT_SECURE: 0 AT_RANDOM: 0x7ffc0aadb909 AT_EXECFN: /usr/bin/true AT_PLATFORM: x86_64Hier kann man ganz schön sehen, dass AT_PHDR (ein Zeiger auf den ELF Program Header) nicht an ASLR teilgenommen hat, während AT_BASE (die Basisadresse von ld.so) randomisiert wurde. AT_ENTRY ist die Adresse im Speicher, bei dem die Ausführung beginnt. Das ist nicht main() sondern ein Symbol namens "_start", in dem die libc ihren Kram macht und dann main() aufruft.
Gut, dachte ich mir, das ist ja weitgehend was ich haben will. Alles super. Von AT_BASE aus kann ich mich durch die ELF-Strukturen hangeln (und die Werte darin sind alle relativ zur Ladeadresse des Binaries). Da finde ich die GOT und kann mal schauen, was da so drin steht, und was ich relozieren muss. Viel mehr als AT_BASE draufaddieren wird das nicht sein, wenn ich Glück habe.
Und was stelle ich jetzt fest? AT_BASE wird nicht übergeben. AT_BASE ist nämlich die Ladeadresse des ELF Interpreters, also ld.so, und den habe ich ja nicht. Meine eigene Base-Adresse sagt mir der Kernel nicht. Immerhin sagt mir der Kernel immer noch AT_PHDR, und das ist auch schon mal was, aber von da aus finde ich die Basis-Adresse nicht, zu der mein Binary geladen wurde. Also jedenfalls nicht offiziell. In der Praxis runde ich von da auf den Page-Anfang ab und hab es, aber das ist ja iih-bäh. Ich fürchte, ich bin schlicht der Erste, der gerne statische PIE-Binaries haben will.
Seufz.
In den gemappten Datenstrukturen stehen leider überall nur Angaben relativ zum Beginn der Datei drin. Und wo das Mapping losgeht, sagt mir der Kernel nicht.
Sachdienliche Hinweise werden dankend entgegen genommen!
Unter Linux gibt es neben fork() auch noch clone(), das ein paar Flags und optional zusätzliche Argument kriegt. Damit kann man dann den neuen Prozess zu einem Thread machen, und sagen, ob der Speicher geshared werden soll und so weiter. Und mit den User Namespaces kann man jetzt eben auch sagen: Der neue Prozess läuft in einem eigenen Namespace für PIDs, für Dateisystem-Mountpunkte, für den Hostname, das Netzwerk, etc. Der Kniff bei den User Namespaces ist jetzt, dass man innerhalb der neuen Namespaces root-Capabilities hat, also so Dinge darf wie chroot aufrufen oder sein virtuelles Netzwerkinterface konfigurieren. Diese Änderungen gelten dann nur relativ zu dem neuen Namespace.
Durch diesen Mechanismus hat man jetzt also plötzlich auch als Nicht-Root-Prozess die Möglichkeit, sich per chroot wegzusperren, und kann sich per PID-Namespace die Möglichkeit nehmen, per ptrace() oder kill() andere Prozesse zu manipulieren.
Wer auch mal damit herumspielen möchte: Hier ist ein bisschen Code zum Herumspielen:
#define _GNU_SOURCEDa gehört jetzt natürlich noch ordentlich Fehlerbehandlung und so rein, klar. Ein bisschen fummelig ist, dass man dann natürlich seine Capabilities ablegen sollte, bevor man irgendwas tut, und das API könnte schöner sein. Das ist das capset hier in dem Spielcode. Da könnte man auch libcap für nehmen, aber ich habe bei sowas gerne so wenig unnötige Abhängigkeiten wie möglich.
#include <sys/mman.h>
#include <sched.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/capability.h>int clonecallback(void* x) {
struct __user_cap_header_struct ch = { .version=_LINUX_CAPABILITY_VERSION_3, .pid=0 };
struct __user_cap_data_struct cd[2] = { 0 };
chroot(".");
capset(&ch,cd);
printf("uid %u, euid %u, pid %u, parent pid %u\n",getuid(),geteuid(),getpid(),getppid());
exit(0);
}int main() {
char* stack=mmap(NULL, 4096+8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_GROWSDOWN|MAP_STACK,-1,0);
if (stack!=MAP_FAILED) {
mprotect(stack,4096,PROT_NONE); /* guard page */
if (clone(clonecallback, stack+4096+8192, CLONE_NEWIPC|CLONE_NEWNET|CLONE_NEWNS|CLONE_NEWPID|CLONE_NEWUSER|CLONE_NEWUTS, /*arg*/ NULL)==-1) {
perror("clone failed");
return 0;
}
sleep(1);
} else
perror("mmap failed");
}
Viel Spaß beim Ausprobieren!
Update: Das mit den Capabilities ist komplex und fühlt sich für mich sehr unintuitiv an. Hier gibt es einen weiterhelfenden Blogartikel dazu.
So ungefähr alle halbe Jahr haben wir Kernel-Bugs. Und praktisch immer in irgendwelchen neuen esoterischen Komponenten, in diesem Fall sogar in einer Komponente, deren einziger Daseinszweck Security ist, nämlich das Speichern von Krypto-Schlüsseln im Kernel.
Aber eigentlich war das gar nicht der Bug, den ich posten wollte. Denn der hier ist viel cooler :-)
Nun ist das alles relatives Neuland. Wenn jemand sich mit solchen Verfahren auskennt, und ein bisschen Zeit hat, sich per Email mit mir darüber zu unterhalten, dann meldet euch bitte bei der Bloginput-Mailadresse. Ich würde gerne auf der einen Seite verhindern, ein API nicht zu berücksichtigen, weil ich es nicht kannte. Auf der anderen Seite würde ich gerne vermeiden, ein API vorschnell schlechter oder besser zu beurteilen als es ist.
Mein Fokus ist bisher auf den allgemeinen Konzepten und bei den einzelnen Plattform-Implementationen auf Seccomp-Filter, weil man da am meisten verstehen und tun muss.
Ansonsten seid ihr natürlich alle herzlich eingeladen, euch den Vortrag anzuhören :-)
Ich habe daher eine Weile lang gar nicht Profiling mit Profiling-Tools gemacht, sondern mit Coverage-Tools, speziell gcov. Damit kann man sich am Ende zeigen lassen, welche Codezeile wie häufig ausgeführt wurde. Das ist zwar nicht identisch mit der Frage, wo die Zeit verbraucht wurde, aber es hilft trotzdem beim Finden von Hotspots.
perf kann jetzt Sampling-basiertes Profiling machen, mit einstellbarer Samplingrate, und kann einem dann den Code disassemblieren und die heißen Instruktionen zeigen. Ich bin noch nicht sehr weit mit dem Tool, aber mein Eindruck ist, dass das recht viel kann. Mehr jedenfalls als ich gerade benutze :-)
Das Testobjekt für mein Rumspielen war ein Tool, das ich für einen Kunden geschrieben habe. Der nimmt per syslog oder stdin Logdaten entgegen und pseudonymisiert die dann. Der Schlüssel für die Rückzuordnung von Pseudonym und Original wird jede Stunde weggeschmissen und neu gemacht, damit man das auch einfach mitlaufen lassen kann. Ein Teil der Aufgabe des Tools ist, per Regex Usernamen zu erkennen. Dabei ruft das Tool dann regexec auf den String ab dem potentiellen Usernamen auf (und das ist in der Praxis jeder Wortanfang).
Ich erzähle das, weil mir dann auffiel, dass das Tool vergleichsweise viel Zeit im Regex-Matching verbracht hat. Nun muss man über regexec wissen, dass der nicht nur am Anfang des Strings matcht, sondern irgendwo in der Zeile. Aus Performancegründen fängt die Regex für den Usernamen daher mit einem ^ an, d.h. "matche nur am Zeilenanfang". Meine Regex-Implementation ist an der Stelle schön in Schichten aufgeteilt, und der Effekt war, dass regexec natürlich nicht wusste, dass die Regex mit einem ^ beginnt und dann trotzdem für alle weiteren Zeichen im Inputstring zu matchen versucht hat. Diese Matchversuche schlugen natürlich alle fehl, weil es eben nicht der Anfang des Strings war. Aber wie sich rausstellte, verbrachte das Tool in diesen sinnlosen Matches (obwohl die schon jeweils direkt abgebrochen wurden) ca. 3/4 seiner Laufzeit. Ich habe dann eine Ein-Zeilen-Änderung in regexec getan, dass der das Matchen im Rest der Zeile nicht versucht, wenn die Regex mit ^ anfängt, und der Durchsatz des Tools hat sich vervierfacht.
Die Lektion an der Sache ist aber eine Andere. perf zeigte mir vorher an, dass regexec 12% ausmachte. Es zeigte mir das zwar als teuerste Funktion an, aber die Zahlen haben bei weitem nicht die Vermutung gerechtfertigt, dass diese Änderung so viel Einsparen würde. Profiling-Tools sind eben schwierig :-)
Besonders interessant fand ich den Hinweis auf problem-solution ordering issues, eigentlich ein Problem aus dem Design von Spielen. Man muss den Spieler erst in das Problem laufen lassen, bevor man ihm die Lösung zeigt, sonst versteht der Spieler nicht, dass das die Lösung zu dem Problem ist und kommt das nächste Mal nicht weiter, wenn er ein ähnliches Problem hat. Und die Dinge wirken auch weniger sinnlos, wenn man erst das Problem zeigt, das sie lösen. Die Erklärung kann man auch auf den Matheunterricht anwenden.
Jemand anderes wies darauf hin, dass das kein Mathe-Ding ist sondern natürlich auch bei Computern häufig vorkommt, dass Leute es für völlig normal und akzeptabel halten, "von Computern keine Ahnung zu haben" und von dir dann zu erwarten, dass du ihnen mal schnell ihr Problem fixt.
Man steckt da 20-30 Jahre Erfahrung in die Problemlösung rein, aber es wird noch nichteinmal anerkannt.Weitere Einsender meinten, das Problem komme schon aus dem Elternhaus.
Ich bin u.a. Mathelehrer an einem Gymnasium - und da kommt es bei einem Elternsprechtag schonmal vor, dass man eine Mutter vor sich sitzen hat, die die Minderleistung ihrer Tochter mit einem Achselzucken abtut und mit einem Schmunzeln berichtet, dass sie selbst auch schon schlecht in Mathe gewesen wäre. Da könne man wenig machen. - Sprich: Fehlleistungen werden auf eine Art "Mathe-Gen" geschoben und die Notwendigkeit, sich mal intensiver damit zu beschäftigen nicht gesehen. Ist halt nur Mathe!Dann kam noch diese schöne Kabarettnummer in PDF-Form rein, die ich weiterempfehlen kann.
Eine weitere Einsendung äußert die These, dass das Auswendiglernen von irgendwelchen Daten und Fakten bei uns in der Gesellschaft einen höheren Stellenwert zu haben scheint als Fähigkeiten oder die Kenntnis von Verfahren oder "Skills", wie man heute sagen würde. Als Indiz dafür weist die Einsenderin auf TV-Shows wie "Wer wird Millionär" hin, ich würde das noch auf Talkshows und politische Debatten ausweiten. Da punktet man auch mit obskuren Fakten und nicht mit Fähigkeiten oder der Kenntnis von Verfahren. Außerdem sind Fakten im Überfluss frei im Internet verfügbar, aber für Verfahren gilt das in deutlich geringerem Umfang.
Eine weitere Einsendung postuliert, dass Mathematik nicht als Lösung sondern als Problem gesehen wird. Mathematik lernt man nicht, weil es zum Verständnis der Welt beiträgt.
Die Textaufgabe, eigentlich genau das, was am Ende vom Matheunterricht wenigstens übrig bleiben sollte - nämlich ein reales Problem in Zahlen zu übertragen und damit diesem dann bei kommen zu können - ist die gefürchtetste aller Aufgaben und wird daher oft marginalisiert oder weg gelassen, damit das Debakel nicht zu groß wird oder "nicht auch noch der letzte Spaß an der Mathematik verloren geht".Ein Psychologe kommentiert:
Denk bei der Debatte auch daran, WER da stolz auf WAS ist. Menschen, die eher im geisteswissenschaftlichen Bereich unterwegs sind, drücken mit der Mathe-Ablehnung häufig auch eine ideologische Haltung aus. Menschen möchten gerne einzigartig und individuell sein. In der Mathematik sollte bei der selben Frage bitte immer dieselbe Antwort rauskommen, sonst wäre es ja nicht deterministisch.So habe ich Depressionen noch nie gesehen!
[…]Vielen Menschen ist es sehr wichtig, dass ihre Meinung, Intelligenz oder Persönlichkeit nicht erfasst und damit vergleichbar gemacht wird. Bspl Intelligenz. Jeder ist überzeugt er hat genug davon, aber wenn alle getestet würden, wäre offensichtlich, dass manche höhere IQ Werte haben als andere. Intelligenz ist halt ziemlich gut normalverteilt. Die Ablehnung von Mathematik ist häufig verbunden mit einer Argumentation wie „es gibt ja wichtigeres im Leben“. Dieses wichtigere ist oftmals durch Mathe bedroht, weil es einer Überprüfung mittels Mathe entweder nicht zugänglich ist oder nicht standhält. Es kann halt keiner quantifizieren, ob Cicero oder Seneca die bessere Literatur ist. Und manchmal hat die Mathematik auch mal Antworten parat, die eigene Glaubenssysteme in Frage stellen (z.B. bei Homöopathie, global warming, Casinokapitalismus). Da muss man manchmal die Vergleichsdimension abwerten, um damit leben zu können.
[…]Stell Dir mal vor, Du würdest auf Deinem blog diskutieren, ob nun Linux, MacOS X oder gar Windows das beste Betriebssystem wäre. Jemand hat einen Test gemacht und Windows hat die höchsten Werte oder so. Die Diskussion wäre unvermeidlich: falsche Metrik, unrealistische Fragestellung, unreliable Messung, da gibt es andere wichtige Dinge, die gar nicht erfasst wurden, usw. Wenn alles diskutieren nichts hilft, dann hilft nur die ultimative kognitive Dissonanz: eigentlich sagen diese Zahlen doch eh nichts aus.
Bedenke immer, dass das gesunde, normale Prozesse sind. Menschen, die alles immer realistisch sehen und sich nicht selbst aufwerten, sind tendentiell depressiv.
Mein persönliches Highlight war eine Mail dieser Form:
Zu der Fraktion gehörend, die die Integralrechnung zwar oberstufenkonform durchgepaukt, aber Mathematik jenseits des Dreisatzes eigentlich nie wirklich verstanden hat, hier ein paar Gedanken darüber:Dann gibt es noch die These, dass Matheahnungslosigkeit schon im Kindergarten beginnt:[… eine Seite Reflektion und Selbstanalyse …]
Jetzt, wo ich aufschreibe, komme ich mir unfassbar engstirnig, unwissend und naiv vor!
Als Spieldesigner für Kindergartenspiele habe ich ein mathematisches Lernspiel entwickelt, das von den Kindergärtnerinnen häufig mit der Begründung „Ach, das habe ich früher nie verstanden.“ oder „Nein, das lernen unsere Kinder hier nicht“ abgelehnt wurde. Was man selbst nicht versteht, müssen die Kinder also auch nicht verstehen. Das heißt der niedrige Stellenwert der Mathematik setzt sich von Generation zu Generation fort. Eltern, die Mathematik nicht verstehen, geben diese Ablehnung an ihre Kinder weiter. Genauso machen es auch Kindergärtnerinnen und sogar Lehrer aus mathematikfremden Fächern.Das finde ich eine sehr gruselige Vorstellung.
Ich finde es bedauerlich aber auch menschlich, dass bei solchen Fragestellungen erstmal die Vorurteile bedient werden, daher habe ich das hier auch mitzitiert. Ein weiterer solcher Fall ist, dass Lehramtsstudenten an den Mathefachbereichen fachlich schwächer sind als "echte" Mathestudenten, die auf Diplom oder so hinarbeiten. Es gab auch mehrere Empfehlungen dieses TED-Videos von Conrad Wolfram (der kleine Bruder von dem Mathematica-Entwickler).
Ein weiterer Einsender erzählt:
Bei uns an der Hochschule wird Mathe immer weniger unterrichtet. Auf dem Linux-Event unserer Hochschule im Jahr 2014 haben mich die Ehemaligen mit großen Augen angeguckt als ich erzählt habe dass wir nur noch zwei Semester lang Mathe haben, nicht mehr vier (merke: Das ist eine Hochschule, da gibts also nicht mal wirklich "schlimme" Mathe). Inzwischen ist es sogar so, dass nur noch die "puren" "Informatiker" zwei Semester Mathe haben. Die "Computernetzler" zum Beispiel haben nur noch ein Semester Mathe!Die Frage ist natürlich, was hier woraus folgt. In meiner Informatik-Studienzeit hat sich auch nicht gerade der Eindruck aufgedrängt, dass man Mathe wirklich braucht. Das hat man halt belegt, weil es Pflichtkurse waren.
Ein weiterer Lesetipp ist Lockhart's Lament. Ein fieser Soziologiestudent wies dann noch darauf hin, dass so gut wie niemand dann tatsächlich Cicero liest :-)
Und so kam jemand auf die brilliante Idee, "kooperativ" Arch-Linux in einer VM zu installieren in einem Livestream. Und es geschah, was geschehen musste: ein Botnet hat den Installator übernommen und stattdessen Gentoo installiert :-)
Ist ein bisschen wie Core Wars!
Infrastruktur wird überhaupt nur beurteilt, wenn sie versagt - ansonsten wird sie gar nicht wahrgenommen. Der Linux-Kernel wird an "ReiserFS/btrfs/XFS/ext4 hat meine Daten gefressen" und an "Der Kernel cored, wenn die Kiste aus dem Sleep aufwacht" gemessen und nicht an "Oh, der write(2) System Call hat meine Daten tatsächlich auf die Platte geschrieben.Ich stimme dem im Detail nicht zu (ich bewerte den Kernel auch nach neuen Features und Performancegewinnen bei alten Features), aber das kann man auch durch geschickte Wortauslegung wegdefinieren. Die Ausführungen finde ich trotzdem weiterhelfend und konnte das so auch schon beobachten. Bei so langen Statements erwähne ich häufig den Einsender nicht, aber in diesem Fall linke ich mal auf ein vergleichbares Statement von ihm, denn Kris macht das seit vielen, vielen Jahren und weiß, wovon er spricht. Das Verständnis der verschiedenen Herangehensweisen von Infrastruktur-Kram und Feature-Kram ist wichtig und es kann uns allen nur hilfreich sein, wenn wir es uns immer mal wieder vor Augen führen.Das ist ein großer Unterschied zu Libreoffice, das keine Infrastruktur ist und an neuen Best Cases (= neue Features) statt an seinen Worst Cases gemessen zu werden.
Infrastrukturentwickler verwenden also dieselben Sprachen, Tools, Unit-Tests, VCVSe und dergleichen mehr, arbeiten aber unter einem komplett anderen Wertesystem.
Wenn da einer auf der LKML ankommt und zeigt "Hier, neuer shiny code" (= neuer Best Case), dann wissen die schon, daß der aus einem anderen, falschen Universum ist. Infrastrukturentwickler wissen, daß Code auch immer Bugs/LoC hat, also eine Liability und kein Asset ist. Das kann man natürlich versuchen, solchen Personen immer wieder, und wieder, und wieder zu erklären, aber das kostet mehr Energie als es wert ist.
Man will in einer Infrastruktur auch nicht mehr Leute haben. Wenn wenn man da einmal genug Teilnehmer hat, daß das Projekt läuft, dann sind mehr Leute auch kein Asset, sondern eine Liability - und das gilt nicht nur für die LKML-Regulars oder Kernel-Committer, oder glibc-Developer, sondern auch für Leute, die Deine Gasleitungen oder Stromkabel warten, und sogar für Wikipedia Admins (sic!). Das ist ein ganz besonderer Menschenschlag, mit einer besonderen Arbeitsethik, die vollständig daraus stammt, daß die ihre Arbeit dann gut machen, wenn sie ihnen nicht gedankt wird und sie einfach niemand bemerkt.
Infrastrukturprojekte wollen nicht nur Deinen Code nicht, sondern auch Deine Mitarbeit nicht, weil sie - ausreichend Basis-Masse vorausgesetzt - beides nicht brauchen. Insbesondere können sie Dich nicht brauchen, wenn Du nicht diesen Infrastruktur-Mindset hast, weil Du sonst auch die Kritik und die Arbeitssituation unter einer Fail-Metrik wie sie bei Infrastuktur herrscht nicht aushältst.
Wenn man da als shiny bling bling Feature-Developer hin kommt, oder als eine 'Findet mich und meine Anliegen wichtig'-SJW-Mentalität, dann passiert eine Sarah Sharp.
Und hier hat mal jemand die Postings rausgesucht und verlinkt, um die es eigentlich gegangen ist. Da kann man sich mal selber eine Meinung bilden. (Danke, Daniel)
Conferences include child care, clearly labeled veggie and non-veggie foods, and a clear event policyWait, what?Alcoholic drinks policy encourages participants to have fun, rather than get smashedo_OCode of conduct explicitly protects diverse developers, acknowledging the spectrum of privilegeSorry, aber damit erscheint ihre Kritik an der Linux-Kernel-Mailingliste für mich in ganz neuem Licht. Ich frage mich ja, ob dieses Herangehensweise (Wir behandeln Andere alle als infantil und schaffen eine Gesinnungspolizei) ihre Wurzeln in der Polizei- und Gefängniskultur der USA hat. Und natürlich in so Konzepten wie "manifest destiny" und dem Amerikanischen Exzeptionalismus.Krass. Und das ist bisher niemandem aufgefallen, wie die so tickt?
Update: Wie sich rausstellt, ist das schon Leuten aufgefallen. Schon 2013.
Wenn Linus sich auf Mailinglisten fies und gemein verhält, ist er immer noch sozialer (bzw weniger asozial) als die Twitter/Tumblr-Empörer. Denn Linus toleriert fremde Meinungen und gibt ihnen negatives Feedback, während die Twitter/Tumblr-Empörer fremde Meinungen direkt wegfiltern.Sozial nutze ich hier im Wortsinne, mit anderen Menschen Dinge tun. Linus zu beschimpfen ist von außen immer einfach, aber wer von euch hält es denn tagein tagaus auf einer "feindlichen" Mailingliste der Größe von LKML aus? Mit lauter Leuten, die endlos Dinge von ihm wollen, und seine Ablehnung persönlich nehmen? Egal was er macht, jemand wird es als persönlichen Angriff werten? Er sagt endlos voraus, "wenn ihr $foo macht, wird das Scheiße", dann machen die Leute $foo und es wird Scheiße und er will das Ergebnis nicht aufnehmen und dann ist ER Schuld?!
Also ich als Nerd möchte hier mal ein paar Dinge zu Protokoll geben.
Erstens. Nerds sind im persönlichen Gespräch sozial unterlegen, aber sie haben für Online-Situationen völlig klare Algorithmen entwickelt, die beide Seiten vorher kennen. In Online-Medien gibt es Verwechslungen und Missverständnisse (ich möchte jeden, der Linus als geifernden Proleten sieht, mal einladen, eines seiner Videos zu gucken. Der Mann ist geradezu charmant und ein Sympathieträger im persönlichen Gespräch! Der Kontrast könnte kaum größer sein!). Nerds wissen das und reagieren entsprechend. Wichtigstes Mittel zur Vermeidung von schlechten Situationen ist negatives Feedback. Nerds wissen das und geben frühzeitig negatives Feedback. Nerds wissen auch, dass auf der anderen Seite möglicherweise jemand sitzt, der ihr negatives Feedback für einen persönlichen Angriff hält und daher möglicherweise ignoriert und dann die Zeit aller verplempert und viel Drama und Schaden anrichtet. Daher wird der Nerd, wenn er den Eindruck hat, sein negatives Feedback wurde ignoriert, nochmal nachlegen. Es gibt hier eine relativ klare Eskalationsstruktur. Wie schnell die eskaliert, hängt vom Medium ab. In meiner Inbox zum Beispiel, wenn ich jemandem schreibe, er soll weggehen, und der schreibt mir nochmal, dann frage ich zurück, welchen Teil von "geh weg" er nicht verstanden hat, und dass er weg gehen soll, und wer dann immer noch mal schreibt, der kommt ins ewige Killfile. Das ist meine Eskalationsstrategie. Auf Mailinglisten wird man im Allgemeinen etwas langsamer eskalieren, aber es läuft grob ähnlich ab.
Zweitens. Ich hatte neulich eine Mail, wo jemand folgende Situation schilderte. Mailingliste, einkommende Anfrage, Null Reaktion. Hey, das ist unhöflich, ich antworte mal. Hat geantwortet, die Antwort war nicht 100% korrekt, andere Leute korrigierten dann, und zwar auf der Mailingliste, nicht per privater Mail. Das wertete der Einsender als privaten Angriff auf sich, und was bilden sich diese Leute alle ein, wenn die das besser wissen, hätten sie ja was antworten können! Aber so läuft das nicht unter Nerds. Nerds können sich an der Stelle in den Gegenüber reinversetzen und wissen: Lieber keine Antwort als falsche Antwort. Falsche Antwort verplempert mehr Zeit. Und eine falsche Antwort ist auch für alle anderen auf der Mailingliste ein Affront, denn die müssen die jetzt korrigieren. Das soziale Konstrukt einer Mailingliste ist nämlich, dass es irgendwo ein Archiv gibt, und vor dem Fragen soll man bitte im Archiv gucken, ob die Frage schonmal gestellt und beantwortet wurde. Das ist so, weil überflüssige Mails an die Liste alle Subscriber Zeit kosten, dein Suchen aber nur dich. Nerds sind da Techies und berechnen die verbrauchte Energie. Wenn du im Archiv suchst, wird dir geholfen, und du kostet niemanden sonst Zeit. Wenn du deine Frage, die im Archiv schon beantwortet ist, auf die Mailingliste postest, dann antworten wir nicht, weil es deine Aufgabe gewesen wäre, im Archiv nachzugucken. Die Energiebilanz ist dabei schon negativ, weil alle Subscriber die Zeit verplempern mussten, deine überflüssige Mail zu ignorieren. Wenn du eine Frage auf die Mailingliste schreibst, die schon im Archiv beantwortet wurde, und jemand antwortet jetzt etwas falsches, dann ist das der Worst Case, denn das muss korrigiert werden, sonst findet der nächste Typ, der sich an die Regeln hält und vorher im Archiv guckt, deine falsche Antwort und nicht die richtige und das ganze soziale Konstrukt ist kaputt.
So und jetzt überlegt euch mal, wie viel mehr Aufwand das Schreiben einer Korrekturmail verursacht im Vergleich zum Löschen einer dummen Frage. So viel mehr schlechte Laune erzeugt ihr mit einer falschen Antwort auf eine dumme Frage.
Aber vielleicht war die Frage ja gar nicht dumm und noch nie im Archiv beantwortet? Das kann sein. Denkbar ist es. In meiner langen Karriere in Mailinglisten und im Usenet kann ich mich gerade an keinen einzigen Fall erinnern, wo auf eine tatsächliche neue Frage keine Antworten gekommen sind. Und sei es nur "Das ist ja eine interessante Frage!".
Aber jetzt überlegt euch mal, wie die eben beschriebene Situation auf Außenstehende wirkt. Die Mailingliste ist voller Fragen von Neulingen, und die werden alle ignoriert oder abgekanzelt. Ab und zu antwortet mal jemand auf eine, und der kriegt dann sofort von allen Seiten auf die Fresse. Sieht das wie eine gute Atmosphäre aus? Natürlich nicht! Niemand will das! Aber wer ist Schuld daran?
Aus meiner Sicht: Die Neulinge, die sich nicht an die soziale Konvention gehalten haben. Und das ist einer der fundamentalen Unterschiede zwischen Nerds und anderen Menschen. Andere Menschen haben dann Mitleid mit den Neulingen. Was ist denn das für eine Community, fragen sie, in der man Neulinge so negativ behandelt? Ihr wollt doch wachsen! Seid lieb zu den Newbies!
Und da kann ich nur sagen: Nein, ich will gar nicht wachsen. Die Communities, in denen ich drin bin, sind alle genau richtig groß. Wachstum ist kein Wert an sich, und wenn ich mir Wachstum dadurch erkaufe, dass der Blick in die Mailingliste nur noch aus Schmerz und Trübsal besteht, weil sich keiner an die sozialen Normen hält und sich vorher selber zu helfen versucht, dann sehe ich Wachstum sogar eher negativ als positiv.
Und richtig schlimm wird es, wenn die Neulinge gar nicht kommen, weil sie zu deiner Community wollen, sondern weil sie gehört haben, dass auf deiner Mailingliste die Neulinge so schlecht behandelt werden, und sie was zum Empören gesucht haben.
Wenn man bei einer typischen Mailingliste all die überflüssige Fragen wegnimmt, und all die Antworten auf überflüssige Fragen, dann bleibt im Allgemeinen nicht viel übrig. Das kannst du doch nicht wollen, Fefe? Doch, genau das will ich. Wenn es nichts zu sagen gibt, dann hätte ich gerne Ruhe und würde mich gerne entspannen, anstatt schon wieder 100 sinnlose Mails löschen zu müssen.
Oh und einen noch. Ich beschrieb oben die Eskalationsstrategie von Nerds. Geschichten der Form "dieser höfliche, freundliche Mensch kam auf die Mailingliste und fragte höflich und zurückhaltend diese legitime Frage und wurde zusammengebrüllt und weggemobbt" sind meiner Erfahrung nach alles Lügen. Jede einzelne davon. Ich bin in meinem Leben auf einigen echt haarigen Mailinglisten gewesen, und NOCH NIE habe ich erlebt, dass jemand, der eine legitime Frage gestellt hat, und dabei höflich und zurückhaltend war, angepflaumt wurde. Nicht ein einziges Mal.
Ich habe auch ein paar Mal auf der Linux-Kernel-Mailingliste gepostet über die Jahre. So ein halbes Dutzend bis 10 Mal oder so würde ich schätzen. Wisst ihr, wie häufig ich angepflaumt wurde? ÜBERHAUPT NICHT.
In meinen Augen haben Leute, die auf Twitter Filterblasen betreiben, im Bezug auf das soziale Verhalten anderer mal gepflegt die Fresse zu halten, denn sie haben sich jegliches moralisches Standing verwirkt. Überhaupt finde ich es sehr problematisch, anderen Leuten sagen zu wollen, wie sie ihr Leben zu führen haben. Wenn euch die Linux-Kernel-Mailingliste nicht gefällt, macht halt eine Kernelflausch-Mailingliste auf, wo es gesitteter zugeht. Für über 90% des Inhaltes der echten Kernelmailingliste braucht man Linus' Anwesenheit nicht. Wenn das tatsächlich besser flutscht, dann wird die unsichtbare Hand des Marktes eurer Mailingliste Erfolg bescheren. Wenn nicht, dann werde ich oben auf der Brücke stehen und euch "told you so" zurufen.
Update: Noch was. Nicht auf eine dumme Frage zu antworten ist auch negatives Feedback und am Ende für den Fragesteller gedacht, nicht für die anderen. Der merkt dann hoffentlich, dass er was falsch gemacht hat, und korrigiert sein Verhalten. Newbies, die dumme Fragen stellen, zu helfen, ist nicht nur nicht negatives Feedback, es ist positives Feedback. Damit transportiert man die Nachricht, dass es OK ist, lieber anderer Leute Zeit zu verplempern als selber mal fünf Minuten ins Archiv zu gucken. Damit erzieht man die Leute zum genauen Gegenteil des gewünschen Verhaltens.
Update: Noch einen. Diese Ausführungen basieren auf der Annahme, dass es sich um eine technische, zielgerichtete Mailingliste handelt. Schlaue Projekte haben daher mehrere Mailinglisten. Einmal foo-dev für die Leute, die das Projekt vorantreiben. Einmal foo-announce für die Leute, die nur wissen wollen, wenn eine neue Version rauskam. Und einmal foo-talk als Auffangbecken für die ganzen Schwallbacken, die Mailinglisten als soziales Forum für Smalltalk begreifen.
Update: Auf einen Satz runtergebrochen: Deine Lebenszeit ist nicht wertvoller als meine. Daher mögen die Leute auch keine Werbung, keinen Spam, keine Prediger, keine Cold Calls, keine Vertreter und keine Zeugen Jehovas an der Tür. Wenn du nicht merkst, was für ein Arschloch-Move das ist, meine Zeit mit deinem trivialen Scheiß in Anspruch zu nehmen, dann verschiebst du dich damit direkt drei Punkte auf der Arschloch-Freund-Skala in Richtung Arschloch. Und kommt mir nicht mit freier Meinungsäußerung. Da muss das, was du zu sagen hast, direkt erstmal inhaltlich die drei Minuspunkte wettmachen, damit ich das unter dem Strich positiv bewerten kann. Ich empfinde es übrigens auch als ganz große Frechheit, wenn mich irgendwelche Leute anrufen. Besonders Journalisten halten das für völlig normal, von anderen zu erwarten, dass sie stundenlang mit ihnen telefonieren. Äh, nein. Ich denke gar nicht daran. Mein Telefon ist für Notfälle. Familienmitglied verschollen. Bekannter vermisst. DU bist im Zweifelsfall KEIN Notfall.
Update: Weil sich tatsächlich Einzelne nicht entblöden, das hier als "SO MACHEN NERDS DAS HALT UND DAHER IST DAS SO RICHTIG" zu strohmannisieren: Es ging hier nicht darum, zu sagen, dass das so richtig ist. Ist es vielleicht gar nicht. Es ging darum, zu sagen, dass das nicht böses Fies- und Gemeinsein ist, sondern dass sich da jemand was bei gedacht hat, und dass dein aus deiner Sicht völlig harmloses, gar höfliches Verhalten aus Sicht anderer an asoziales anderer-Leute-schöne-Dinge-kaputtmachen grenzt. Meiner Erfahrung nach ist es viel besser, zu erklären, warum Dinge so sind, als zu erklären, dass sie so sind und passt euch gefälligst an. Die Dinge sind so, weil die Nerds vorher die anderen Optionen durchprobiert haben und die waren alle noch schlechter. Bist du jetzt möglicherweise das Genie, das den Dritten Weg findet, der alles besser macht? Denkbar. Aber sehr, sehr unwahrscheinlich. Viel wahrscheinlicher ist, dass du gerade dabei bist, dich monumental zum Idioten zu machen, indem du die Fehler, die andere Leute schon für dich gemacht haben, nochmal machst. Auf Kosten anderer. :-)
Schuld ist, natürlich, der fiese Kommunikationsstil der Alphamännchen auf der Kernel-Mailingliste.
Ich frage mich ja, mit welchem Recht eigentlich solche Leute einfach annehmen, sie seien im Recht und die anderen müssten sich anpassen. Auf der Kernelmailingliste sind hunderte aktive Poster, wahrscheinlich noch tausende von Lurkern. Und dann kommt diese eine Frau und bringt sowenig Respekt für die etablierten Strukturen mit, dass sie da jahrelang einen Krieg führt, um "Verhaltensregeln" installiert zu kriegen — gegen den Widerstand der ganzen anderen Leute, die auf der Mailingliste was machen. Wie kann man denn bitte von Respekt reden, wenn man selbst den Respekt nicht aufbringen kann, die Leute selber entscheiden zu lassen, in welcher Umgebung sie arbeiten wollen? Dieses Abschiedsstatement lässt auch mal wieder tief blicken. Sie habe keine Kraft mehr (Opferrolle), sie könne den Ton nicht mehr ertragen (Opferrolle), sie melde schon gar keine Bugs mehr, weil sie Kommunikation mit diesen Leuten nicht aushält (Opferrolle). Sie war übrigens auch Kernel-Koordinator für das "FOSS Outreach Program for Women". Das hat auch nicht geklappt. Und Schuld sind natürlich die ganzen fiesen Maskus auf der Mailingliste.
Aber auf die Idee, dass das Ziel der Kernelmailingliste nicht der Outreach an Frauen sondern die Arbeit am Kernel ist, und dass sie möglicherweise schon viel mehr Toleranz erfährt als sie mit ihrem Anliegen oder Verhalten verdient hätte, weil die Leute sie eben doch respektiert haben, auf die Idee kommt niemand.
Ich stelle mir mal vor, wie das abliefe, wenn ein einzelner Mann zu, sagen wir mal, einem Bridgeclub käme, und den Damen dort erklärt, sie sollten gefälligst mal Outreach für Männer betreiben und ihn Bier saufen, die Füße auf den Tisch legen und Rülpsen lassen, und in der Ecke will er einen Fernseher mit Fußballübertragungen haben. Da wären sich sofort alle einig, dass das ein Arsch ist, der da mal bitte von ein paar Pflegern rausbegleitet gehört.
Ja aber aber aber du sprichst dich doch nicht ernsthaft gegen einen zivilen Ton aus, Fefe? Doch, tue ich. Eine technische Mailingliste, in der man beschissenen Code nicht brandmarken darf, weil es die Gefühle des Autoren verletzen könnte, in der man einen Bug nicht Bug nennen darf, weil das nicht flauschig genug ist, in der man einen Patch zur Einführung des Binnen-I in der Dokumentation nicht rausschmeißen kann, weil das nicht politisch korrekt wäre, wenn man Idioten rausschmeißt, so eine Mailingliste verfehlt ihren Zweck. Das wäre wie wenn man ein Auto baut, das keine Vollbremsungen zulässt. Manchmal braucht man das, und ja, da können Leben von abhängen. Es gibt für technische Projekte genau gar keinen Grund, sich von irgendwelchen Leuten vorschreiben zu lassen, wie sie ihr Projekt zu machen haben. Wenn es euch nicht gefällt, forkt halt. Oh, das geht nicht? Da müsste man ja Arbeit in was anderes als empört sein investieren? Tsja.
Der Vollständigkeit halber: Ich kenne Sarah Sharp nicht, habe sie nie getroffen oder mit ihr gemailt. Ich nehme sie hier nur als Aufhänger. Sie kann wahrscheinlich am wenigstens für das, was ich hier beschreibe, denn sie hat ja tatsächlich auch technisch mitgearbeitet. Aber sie ist halt die Repräsentantin dieses Trends und sie hat jetzt News gemacht, daher jetzt diese Kommentar.
Leute, wenn ihr euch über das Binnen-I empören wollt, dann macht halt ein belangloses Sprachenblog auf und rantet da vor euch hin. Wenn sich niemand interessiert, dann ist das kein Zeichen, dass der liebe Gott hinter euch steht und ihr die ganze Zeit im Recht wart und ihr jetzt einen Kreuzzug lostreten sollt, sondern dann ist das ein Zeichen, dass euer Anliegen nicht mehrheitsfähig ist. Deal with it.
PS: Habe heute Schnupfen und Halsweh (Opferrolle) und kein Kraft mehr (Opferrolle) für Toleranz gegenüber Intoleranten übrig, die mir ihr Lebensmodell aufzwängen wollen. Toleranz geht in beide Richtungen. Du kannst nicht von mir Toleranz für deine Ideen und Gedanken fordern, und dann keine für meine Ideen und Gedanken haben. Und nein, du bist nicht automatisch im Recht, nur weil du das glaubst. Die Merkel hält sich auch für im Recht. Wenn es für deine Positionen keinen Weg gibt, dich von ihrer Falschheit zu überzeugen, dann ist das keine Position sondern eine Religion und du solltest dich was schämen.
Update: Ich will das noch ein bisschen konkretisieren, was ich meine. Die Voraussagen sind immer die selben: Linux laufen die Leute weg, das Potenzial der Frauen als Mithelfer geht flöten, am Ende stehen Ruin und Untergang. Das sind Voraussagen, die auf Basis einer Theorie gemacht werden. Der Grund, wieso man solche Aussagen macht, ist weil man dann eine Messung durchführen kann, und sehen kann, ob die Messung mit der Voraussage übereinstimmt (das würde die Theorie bestätigen) oder nicht (dann war die Theorie falsch). So und jetzt gucken wir uns mal die Messung an: Linux ist und bleibt eines der erfolgreichsten, wenn nicht das erfolgreichste Open Source Projekt aller Zeiten. Von Developer-Exodus keine Spur. Anders gesagt: Die Messung hat die Voraussagen und damit die Theorie falsifiziert. Deal with it.
Update: Bei Slashdot hat mal jemand in den Archiven gewühlt und die ursprünglichen Beschwerden von Sarah gefunden. Lest selbst.
Update: Jetzt schlagen hier Klugscheißer auf, die meckern, dass ich Theorie schrieb, als ich Hypothese hätte schreiben sollen. Die Klugscheißer haben völlig Recht.
Heute so: Microsoft kauft Havok. Havok baut eine in sehr vielen Spielen verwendete Physik-Engine, und gehörte seit 2007 Intel. Der Hauptkonkurrent ist PhysX und gehört Nvidia.
Ich deute das mal so, dass sie sich unter Druck sehen.
$ echo "int main() { return 0; }" > t.c
$ time gcc -o t t.c
gcc -o t t.c 0.03s user 0.01s system 31% cpu 0.122 total
$ time gcc -o t t.c
gcc -o t t.c 0.02s user 0.01s system 92% cpu 0.036 total
$ time clang -o t t.c
clang -o t t.c 0.19s user 0.02s system 56% cpu 0.372 total
$ time clang -o t t.c
clang -o t t.c 0.23s user 0.01s system 99% cpu 0.243 totalDas ist besonders auffällig, wenn ich meine Libraries kompiliere, die immer aus vielen kleinen Fitzeldateien bestehen. Einmal libowfat mit gcc bauen dauert 10 Sekunden, mit clang dauert es 1 Minute 25 Sekunden. WTF? Auf der selben Hardware, versteht sicht, mit allen Dateien im Cache. Und gcc ist noch "ineffizient". Bei gcc gibt es gcc, das Frontend, dann cc1, das Backend, dann as, den Assembler, dann collect2, den Wrapper um den Linker, dann ld, den Linker. Bei clang gibt es clang und ld. Wie kann denn das bitte so viel langsamer sein?!
Gut, das ist mit -O2. Vielleicht ist der Optimizer so lahm bei clang? Probieren wir mal mit -O0. gcc: 7 Sekunden. clang: *waaaaart* *kaffeehol* 1 Minute 22. Was zur Hölle?!?
clang ist von LLVM 3.7, gcc ist 5.2.0. Plattform ist Linux/AMD64.
Da tun mir ja fast ein bisschen die BSDler leid, die aus fundamentalistisch-politischen Gründen von ihrer Distro zu so einem Lahmarsch-Compiler migriert wurden.
Bei C++ ist das übrigens anders herum, da ist clang dann schneller. Aber soll ich was sagen? Es gibt da draußen viel mehr kleine C-Fitzeldateien als große C++-Monster.
Spannenderweise ist der bleeding-edge-clang++ aus dem SVN plötzlich Faktor 10 langsamer als g++. Da muss wohl irgendwas schiefgelaufen sein.
Update: Ich habe eine Theorie, wieso clang so hohe Startup-Kosten hat. Ich habe beim Bauen Shared Libraries aktiviert. Daher lädt clang bei mir beim Start gefühlte 100 Libraries rein. Das kostet halt.
Update: Und die SVN-Version hab ich versehentlich nicht auf Release-Mode gesetzt beim Bauen, deshalb ist die so lahm.
Update: Wenn ich die SVN-Version im Release-Modus und statisch gelinkt baue, dann ist der tatsächlich geringfügig schneller als gcc. Ich ziehe also alles zurück und behaupte das Gegenteil.
Das Problem war, dass dietlibc einige OpenBSD-APIs implementiert, konkret arc4random und getentropy, genau damit OpenSSH das verwenden kann und in den Genuss des neuen getrandom-Syscalls unter Linux kommt. Das configure-Skript erkennt das auch und benutzt dann meine dietlibc-Implementationen. Die glibc hat diese APIs nicht. Der OpenSSH-Server hat einen "sandbox"-Modus für Privilege Separation, in dem er SECCOMP-Filter benutzt, um die erlaubten Syscalls zu filtern. Und dort war nun ausgerechnet der getrandom-Syscall noch nicht freigegeben, weil der Code für den glibc-Port das nicht benutzte.
Manchmal kann es eben auch Nachteile haben, wenn man Leuten zu sehr entgegen kommt :-)
Als Kontext: grsecurity macht seit echt vielen Jahren exzeptionell gute Arbeit. Deren Eigenlob da oben ist nicht übertrieben. Die haben u.a. ASLR erfunden. OpenBSD (und natürlich auch alle anderen) hat dieses zentrale Security-Feature von denen kopiert. Und das ist nur deren bekannteste Erfindung, die machen da wirklich hervorragende Arbeit.
Die fiese Firma, die sie da nicht explizit nennen wollen, ist vermutlich Wind River / Intel.
So sehr ich ihre Erwartungshaltung verstehen kann — wer möchte nicht für seine Arbeit bezahlt werden? —, so wenig zielführend ist diese Aktion meiner Meinung nach. Erstens hatten die ja, wie grsecurity hier länglich ausführt, eh nicht den aktuellen Stable-Patch genommen, sondern irgendeinen alten, gammeligen Stinkepatch beim Portieren noch kaputtgemacht. Das Ziel treffen sie damit also gar nicht, nur die ganzen anderen User.
Zweitens finde ich es bescheuert, von Sponsoren zu reden, und dann nur denen den Content zu geben. Wenn ich Geld gebe und dafür was kriege, dann ist das kein Sponsoren-Verhältnis sondern da wird etwas bezahlt. Sponsoren zahlen dafür, dass ihr Logo irgendwo steht. Und wenn sie ihre Patches nicht öffnen, dann sollten sie vielleicht auch ihren Laden von "Open Source Security" umbenennen. Denn das ist dann nicht mehr, was sie tun.
Ich glaube, dass die bessere Lösung gewesen wäre, irgendwo eine Pranger-Webseite zu pflegen. Oder einfach "not for resale" in die Lizenz zu schreiben, wenn sie das nicht möchten.
Wobei das natürlich schon echt unverständlich ist, wieso ein Milliardenkonzern wie Intel nicht ein paar Almosen aus der Portokasse in Richtung grsecurity krümeln kann. Das merken die doch gar nicht in ihrem Quartalsbericht! Das fällt unter die Rundungsgrenze! Und damit meine ich übrigens: Intel sollte die fördern, egal ob Wind River jetzt die implizierte Firma ist oder nicht. Oder halt über die Linux Foundation fördern. Meine Güte, irgendein Modell wird sich da doch finden lassen!
Update: Zwei Hinweise von einem Einsender: Bei den Pwnie-Awards 2011 gab es einen Lifetime Achievement Award für einen von PaX/grsecurity. Und Nicht nur Wind River, auch Verifone kommt in Frage.
Jemand schrieb mir, das könnte bedeuten, dass das Netzteil demnächst aufgibt.
Der Linux-Treiber macht übrigens noch ganz andere Zickereien, da gibt es Bildstörungen, die ausssehen, als würde das Bild Interlaced übertragen und die Zeilen werden in der falschen Reihenfolge wieder zusammengefügt. Das scheint ein bekanntes Problem zu sein.
An der Stelle fragt sich vielleicht der eine oder andere, wieso ich überhaupt eine AMD-Grafikkarte gekauft habe. Dafür gibt es mehrere Gründe:
Aber so wie sich das jetzt gerade darstellt alles, ist AMD wohl eher nicht die richtige Entscheidung. Wisst ihr, was unter Linux noch am stressärmsten funktioniert und ordentliche Open Source-Treiber hat? Intel-Grafik. Ich brauche unter Linux keine fette 3d-Grafik und habe daher dort den Nvidia-Chip komplett deaktiviert, und kriege unter Windows mit zugeschalteter Nvidia-GPU ordentlich 3d-Wumms. Wieso gibt es Hybridgrafik eigentlich nicht für Desktops? Oder gibt es das und ich habe es bisher übersehen?
Mal unter uns: Wenn Intel endlich mal konkurrenzfähige Grafikleistung produzieren würde, und sie scheinen das ja in letzter Zeit vermehrt ernst zu meinen, dann wäre ich der erste, der AMD und Nvidia komplett rauskantet. Intel hat in der Vergangenheit immer viel Ärger für ihre Grafiktreiber gekriegt, aber ich kann das nicht nachvollziehen. Ich hatte nie Ärger mit deren Grafiktreibern, auf keiner Plattform. Das Ultrabook, das meinen 4k-Monitor ordentlich angesteuert kriegt, hat auch Intel-Grafik an Bord.
Update: Vielleicht fragt sich jemand, wieso ich überhaupt noch einen Desktop habe. Wegen der Geräuschentwicklung. Wenn ich was kompiliere oder zocke, dann will ich keinen pfeifenden Laptop vor mir haben. Der Desktop hat ein großes Gehäuse und bleibt leise.
Update: Mhh, mein Desktop-Bios ist von 2011, der Rechner selbst von 2010. Vielleicht sollte ich den einfach mal komplett austauschen. Inzwischen kriege ich auch mit dem Laptop mit Intel-Nvidia-Hybridgrafik einen stabilen, flickerfreien 60Hz-Link hin.
Aus Sicht von Microsoft, Google und Apple sind die Zeiten vorbei, in denen man ein Gerät einfach nur so am Internet betreiben kann, ohne dass es ständig nach Hause telefoniert. Und selbst Linux-Distributionen telefonieren ja heutzutage nach Hause, und sei es nur zum Nachgucken, ob es Updates gibt.
O tempora, o mores!
Ich für meinen Teil glaube nicht, dass Windows 10 so viel schlimmer ist als vorherige Windows-Versionen, mal abgesehen von Cortana natürlich, und dafür kann man Microsoft nur partiell die Schuld geben. Da sahe sie sich halt durch Siri und Google Now unter Zugzwang gesetzt. Wenn man Cortana und Wifi Sense ausmacht, dann bleiben hauptsächlich Dinge übrig, die schon bei Windows 8 und früher ein Problem waren, wie der ganze Browser-Kram, der während der URL-Eingabe de facto ein Keylogger ist. Aber das macht Chroma ja auch und warnt da weniger klar vor.
Ich finde diese Grafik vor allem deshalb wichtig, weil die meisten Dinge davon Apple-User z.B. schon die ganze Zeit betreffen, nur regt sich von denen keiner drüber auf, weil die alle nicht die mentale Kapazität haben, um das Problem zu erkennen, bzw. um das als Problem zu erkennen. Und Android natürlich genau so. Was war bei Chrome neulich die Hölle los, als die Leute merkten, dass Google da unter Linux Google Now implementiert hat. Und die Aufregung kam auch dort initial nicht von Privatsphäre-Seite sondern von religiösem Fundamentalismus, weil Debilianisten fanden, das sei ein binärer Blob und gehöre nicht in ihre Distribution. Als ob so eine Funktion irgendwie vertretbarer wäre, wenn der Quellcode für die Clientseite offen liegt!
Wir können hier gerade live und in Farbe beobachten, wie die Welt den Bach runter geht. Das ist wie mit der Umweltverschmutzung, Klimawandel und Massentierhaltung. Alle sehen es, alle wissen, dass es uns alle umbringen wird, aber keiner hält es auf.
Nun, wenn ich euch jetzt sage, dass das Gewehr eine WLAN-Schnittstelle hat, was ist dann eure erste Reaktion?
Wenn sie "Das kann man doch bestimmt hacken" ist, dann habt ihr völlig Recht. (Danke, Pascal)
Das ist dann wohl eine Copyright-Verletzung.
Nein, wirklich! Die Linux Distros könnten da rumzicken. Hat wohl bisher noch keine gemacht, aber nunja. Wer dachte, hey, freie Software ist freie Software, und gerade die GPL sollte doch dafür sorgen, dass von der Front kein Stress kommt, … Die Free Software Foundation hat da zwei Jahre rumverhandelt. Unglaublich.
Hier ist ein Ubuntu-Bug dazu, und der ist ganz instruktiv.
Wenn man den Darstellungen dort glauben darf, dann hat Samsung in ihrer Firmware angekündigt TRIM mit NCQ zu können, kann es aber nur ohne NCQ. Linux guckt sich an, was die Firmware ansagt, und macht das dann halt, und dann failed die SSD. Der Fix ist jetzt, die Samsung-Geräte in die schwarze Liste der Geräte aufzunehmen, bei denen der Hersteller zu blöde ist, die tatsächlichen Capabilities zu announcen.
Glücklicherweise kann man immer noch sowohl TRIM als auch NCQ machen, nur halt nicht in Kombination. (Danke, Thomas)
Bürgerbüros #Kreisverwaltungsreferat: Aufgrund eines technischen Totalausfalls ist heute kein Parteiverkehr mehr in den Bürgerbüros möglich!Technischer Totalausfall? Hier schreiben sie "Totalausfall unserer IT-Systeme". Was da wohl passiert ist?
Update: Ein Einsender weist darauf hin, dass sonst immer angeblich Linux Schuld war, wenn irgendwo was klemmte. Und jetzt wo es unter Windows klemmt, gibt es nur nebulöses "da ist was kaputtgeagngen"-Geblubber. (Danke, Michael)
Ich hatte vor einer Weile geschrieben, dass mein neues Notebook ein Schenker XMG P505 geworden ist. Das habe ich jetzt eine Weile im Einsatz und bin nach wie vor hochzufrieden. Die Verarbeitung überzeugt auf ganzer Linie, die verbaute Hardware war Top of the Line beim Einkauf und ist es immer noch weitgehend. Da war keine Bloatware drauf, alles ordentlich installiert, keine unerkannten Geräte im Dateimanager, ich konnte sagen, dass ich lieber ein englisches Windows zu meiner deutschen Tastatur haben will, da lagen auch keine Antivirus-Trial-Bullshit-Vorinstallieren bei, und für Gaming ist der echt prima.
Meine größte Sorge war, dass der dann fürs normale Arbeiten nicht gut sein würde, weil die Batterie nicht lange hält oder der Lüfter immer läuft. Kurz gesagt: Ist kein Ultrabook, der Akku hält gut drei Stunden beim Tippen in der Bahn. Filmgucken kann ich auf Fullscreen im Akkubetrieb für die Lände normaler Hollywoodfilme, und habe dann so 30-40% Akku übrig. Bei einem besonders langen Film (2h20) kam ich bis kurz vor den Abspann. Der Lüfter läuft normalerweise nicht. Man hört nur die Festplatte leise zuckeln, wenn man die nicht runterfährt oder gleich ganz auf SSD setzt. Ich kann gerade echt nichts sagen, was bei mir Unzufriedenheit auslöst bei dem Gerät. Ich benutze den inzwischen auch Zuhause und fahre den Desktop gar nicht mehr hoch. Der 4k-Monitor funktioniert am Mini-DP-Ausgang in 4k mit 60 Hz. Alles super.
So und jetzt der 4k-Monitor. Den habe ich jetzt ein paar Tage im Einsatz und bin auch hochzufrieden. Ich habe bisher keine Schlieren oder Latenzprobleme beobachten können, und fahre den im Moment im Eco-Modus (dunkler). Gimmicks wie Bild-in-Bild oder den Bildbearbeitungsmodus benutze ich nicht, die scheinen aber zu funktionieren. Das Hauptproblem auf einem 4k-Monitor ist, dass man da bei Software nachjustieren muss, um den HiDPI-Modus zu aktivieren. Das kann ein bisschen fummelig werden, aber ich benutze im Wesentlichen unter Linux außer urxvt und Webbrowser keine weiteren Anwendungen, gelegentlich mal einen Image Viewer vielleicht, oder einen gvim. Da setzt man halt die Font hoch, Firefox richtet sich nach der DPI-Zahl, die X leider nicht automatisch aus dem EDID holen kann, die konfiguriert man dann halt manuell mit xrandr. Fertig. Der Monitorsound funktioniert über miniDP vom Laptop aus unter Linux mit mplayer aus dem Stand und ich höre damit gerade den Mass Effect 2 Score seit ner Stunde. Klingt nicht wie so gut wie die Stereoanlage, aber gut genug, dass ich mir damit seit ner Stunde Musik anhöre. Anyway. Schenker-Gaming-Laptops würde ich sofort wieder kaufen, den Monitor nach bisherigem Stand auch. Wenn mir da nicht noch irgendwas ganz doll dreckiges auffällt.
Was mir gerade unerwartet Stress macht ist meine Logitech-G100-Maus, wo die linke Maustaste Aussetzer hat. Da kommen gelegentlich Mausklicks nicht an. Man hört den Klick, aber nichts kommt an. Sehr befremdlich, mit Logitech hatte ich eigentlich bisher nie Ärger. Vorher hatte ich zwei Mäuse von Roccat, das würde ich nicht nochmal kaufen. Die hatten beide das selbe Problem (waren verschiedene Modelle), nämlich dass die Gummischeiben links und rechts mit irgendeinem Billigkleber festgeklebt waren, der dann bei Benutzung warm und flüssig wurde und da an den Seiten rausquoll. Dann hatte ich bei der Mausbenutzung plötzlich klebrigen Schleim an den Fingern. Irgendwann habe ich dann mal genug gehabt und die Gummiplatten abgemacht, den Klebstoff entfernt, und die Platten wieder mit Bastelkleber festgemacht. Aber, sorry, bei Mäusen dieser Preisklasse ist das mal völlig inakzeptabel. Roccat kommt mir nicht wieder ins Haus. Und wenn Logitech jetzt auch nachlässt, gehen mir langsam die Optionen aus. Ich bestehe aus Privatsphäregründen auf kabelgebundenen Mäusen, hätte aber gerne eine optische Maus, die auch auf Glas funktioniert. Das konnten die Roccat-Mäuse auch nicht. Da holt man dann im Hotel auf Reisen die Maus raus und ärgert sich, dass man auch ein Mauspad hätte mitbringen müssen.
Oh, der Monitor tat bei mir in Tests sowohl an einer alten AMD-Grafikkarte im Desktop und am Laptop unter Linux. Da hatte ich mir auch ein bisschen Sorgen gemacht. War aber anstecken-tut. Musste da nichts konfigurieren. Gerade bezüglich MST und so hatte ich mir da Sorgen gemacht. War unbegründet.
Update: Ich probiere gerade Firefox mit GTK3. Damit funktioniert der automatische HiDPI-Modus von Firefox/GTK2 nicht mehr.
XKEYSCORE is a piece of Linux software that is typically deployed on Red Hat servers. It uses the Apache web server and stores collected data in MySQL databases. File systems in a cluster are handled by the NFS distributed file system and the autofs service, and scheduled tasks are handled by the cron scheduling service. Systems administrators who maintain XKEYSCORE servers use SSH to connect to them, and they use tools such as rsync and vim, as well as a comprehensive command-line tool, to manage the software.Vielleicht hört mir jetzt endlich jemand zu, wenn ich sage, dass wir bei Lizenzen für freie Software eine Klausel gegen Militär und Geheimdienste brauchen?Aber wartet, einen Lacher habe ich noch:
John Adams, former security lead and senior operations engineer for Twitter, says that one of the most interesting things about XKEYSCORE’s architecture is “that they were able to achieve so much success with such a poorly designed system. Data ingest, day-to-day operations, and searching is all poorly designed. There are many open source offerings that would function far better than this design with very little work. Their operations team must be extremely unhappy.”Der Mann hat jahrelang einen Cluster aus Ruby-Schnarchware verwaltet, seine Firma ist vor allem bekannt für den Failwhale, und DER will jetzt anderen Leuten sagen, wie man sowas macht! Dass ich nicht lache!Aber bei aller Schelte für die NSA. Eine Sache haben sie doch richtig gemacht:
Analysts connect to XKEYSCORE over HTTPS using standard web browsers such as Firefox. Internet Explorer is not supported.MWAHAHAHA
The __driver_rfc4106_decrypt function in arch/x86/crypto/aesni-intel_glue.c in the Linux kernel before 3.19.3 does not properly determine the memory locations used for encrypted data, which allows context-dependent attackers to cause a denial of service (buffer overflow and system crash) or possibly execute arbitrary code by triggering a crypto API call, as demonstrated by use of a libkcapi test program with an AF_ALG(aead) socket.Der kaputte Code ist seit Linux 2.6.38 dabei. Mir ist gerade nicht auf Anhieb klar, wieso die das als remote getagged haben. Sieht für mich erstmal wie ein Local Privilege Escalation aus. Vielleicht wenn man sein IPsec progressiv konfiguriert hat?
Das hätte natürlich so nie durch den Primzahlgenerator kommen dürfen. Und in der Tat, wenn man das mal in GMP durch den Miller-Rabin-Test jagt, ist das Ergebnis "keine Primzahl".
#include <gmp.h>Gibt es diesen Key wirklich? Ja, man findet ihn auf den Keyservern. Was zur Hölle ist hier passiert?! Hat der den Key mit einem Hexeditor generiert statt mit gnupg?!
#include <stdio.h>int main() {
mpz_t a;
mpz_init(a);
mpz_set_str(a,"817023023960376946633975507110154649249407598806798730414849884461776172171921668594148071323527016137506405823108520062504849249423700259406905313281403901410082762097159560221463048924336192384026777502177262731045200322200149773127502888545234973139480887644585192600631058962876114156934248895171959246969597637127280010272143593885240940877456234662196130491400738438731832514335353824697930453078426722191105157568392826870043655708008545411143367763836566011740499383456592129662585004880376777597714978023542434421914201119537685489173509942329090631662014650033142642110914360849421856179611226450806562235534802516081595259914768497444702718749402330070488028751073730349460752771915484847399385631524708487646079936572410398967582895983187640798072309362094727654167628620105981459021548290415800096769214437425690934372015628796027498219902441288189398386359846661623243493534897411417685435424010451956954083531228374002591372549525280610594684910812811287436481207089763125424247793044043309737269468709710679872269272855389945385386467765509880648929743498214329578288874987193768439353382305260108425688024147656806932474058888992099083804597481699305852902662863062054067183925164590726103552998367994727700722491707",10);
printf("%d\n",mpz_probab_prime_p(a,10));
}
Update: Bei Hacker News gibt es ein paar Kommentare, die Licht ins Dunkel scheinen.
The factored keypair in question is actually a subkey on HPA's public key. However, it appears that the self signature (which is a signature on the hash of the main public key and the subkey) does not match the hash_check. The issuer of this self signature has the same key_id as HPA's main key, which is why this subkey is listed under HPA's public key.
[…]
EDIT: It's the EXACT SAME subkey self-signature packet as HPA's real subkey self-signature packet! Someone (by malice or mistake) manually added a subkey to HPA's public key and copied the signature from the other subkey directly onto the new subkey.
Und weiter unten jemand anderes:
When I try to import HPA's key from the public key servers, I get an "invalid subkey binding" error and the weak sub key isn't imported. That error means that the sub key isn't properly signed by HPA's master key, so there is no cryptographic proof that this weak sub key actually belongs to HPA. This looks more like a fake sub key that someone tried to pollute the public key servers with, which isn't really an issue because PGP implementations will just ignore it.
Update: Jetzt ist mir in der Aufregung die Formulierung entglitten. Der Modulus ist bei RSA keine Primzahl, sondern das Produkt zweier Primzahlen. Allerdings zweier großer Primzahlen. Herauszufinden, welche zwei Primzahlen das im konkreten Einzelfall sind, ist so schwer, dass das die Sicherheit von RSA darauf beruht.
Wenn man einen Schlüssel generiert, generiert man u.a. diese zwei Primzahlen. Primzahlen generiert man, indem man Zufallszahlen nimmt, und die mit einem probabilistischen Primzahltest prüft, wie z.B. dem Miller-Rabin-Test. Der soll mit an Sicherheit grenzender Wahrscheinlichkeit ausschließen, dass es sich bei den beiden großen Faktoren nicht um eine Primzahl handelt, und der sollte daher fehlschlagen, wenn er einen so kleinen Faktor findet.
Um nicht die Smart Meter Gateways mit Displays und Bedienfeld bestücken zu müssen, hat die PTB die Möglichkeit geschaffen, eine zertifizierte Software-Applikation zur Anzeige einzusetzen. Die erfolgt über das Internet in einem Webbrowser.Wait, what?!
Und dafür haben sie jetzt eine Linux-Distro gebaut, die man als Live-CD bootet, und damit kann man dann … was zur Hölle?! Wem hilft ein altes Live-Linux mit einem Firefox, der schon zwei Wochen nach Release der CD veraltet ist? Das ist dann sicher wegen … oh, was sagen Sie? Ist gar nicht sicher? Na sowas.
Update: Die Linux-Version segfaultet bei mir aus dem Stand. Vielleicht haben wir doch noch Zeit.
Update: Unten auf der Seite steht:
When this tool crashes, we automatically collect crash dumps so we can figure out what went wrong. If you don't want to send your crash dumps to Microsoft, don't install this tool.
Vielleicht habe ich die Funktion des Tools bloß falsch gedeutet. Auf der anderen Seite ist das bei mir gecrasht, bevor es einen Dump machen konnte. Ich vermute gar, es ist beim Dumpen gecrasht. :-)
Nanu? Was ist denn da passiert? Hier kriegt man einen kleinen Einblick. Dieser Teilthread handelt davon, dass die Hauptbegründung (bei weitem nicht die einzige!) für kdbus ist, dass das alte dbus so ineffizient ist, und man da mal was tun muss, weil das so nicht weitergeht. Also hat Linus mal sehen wollen, und nachdem das nicht sofort klappte (Linus tappt da ganz wunderbar in die üblichen boah-ist-diese-ganze-gnome-kacke-furchtbar Buildprobleme, die sie immer versuchen, hinter configure und pkg-config zu verstecken, aber manchmal suppt es eben stinkend aus irgendeiner Ritze raus), lässt er mal einen Profiler laufen, um zu sehen, was da eigentlich so langsam ist. Und — es ist nicht der Kernelteil. Damit ist das "aber aber aber Performance"-Argument natürlich erstmal vom Tisch.
My guess is that pretty much the entirely of the quoted kdbus "speedup" isn't because it speeds up any kernel side thing, it's because it avoids the user-space crap in the dbus server.IOW, all the people who say that it's about avoiding context switches are probably just full of shit. It's not about context switches, it's about bad user-level code.
Da dreht sich das DRM-Karussel munter weiter und man wird wieder unter Linux gearscht sein. Ja super!
IIS hat eine Kernelkomponente, weil Microsoft ohne so zu Bescheißen nicht in der Lage war, in Benchmarks mit Linux zu konkurrieren. Es war so schlimm, dass Samba unter Linux schon rein im Userspace schneller war als ein Windows, das SMB komplett im Kernel macht. Vor diesem Hintergrund muss man das als Verzweiflungstat sehen.
Übrigens gab es auch unter Linux mal Versuche, einen Webserver direkt im Kernel zu implementieren, das war aber nie mehr als ein Experiment.
Microsoft hat damals die IIS-Benchmarks offensiv als Argument gegen Linux und Apache verwendet. Wir reden hier von Ende der 90er, da war der Kampf gegen Linux noch voll im Gange. Heute stellt Microsoft selber Software unter MIT-Lizenz für Linux her. Das war damals völlig undenkbar.
Das spannende an diesem Bug ist, dass http.sys immer einen relativ guten Ruf hatte, geradezu als sicher galt, weil es da so selten irgendwelche Probleme gab. Aber so ist das halt manchmal im Leben. Es dauert ein bisschen, bis man die Rechnung für Jugendsünden kriegt.
Update: Falls sich jetzt der Eindruck einstellt, dass nur IIS http.sys einsetzt, dann stimmt das nicht. Es gibt auch andere Software, die das tut, etwa von Citrix. Die haben den Bug auch gemeldet.
Oh, wobei: sie haben einen Fork von LLVM gemacht.
An dieser Stelle möchte ich mich bei allen befragten Experten herzlich bedanken, dass sie bei der Aktion mitgemacht haben!
Mit IT ist er super, Sicherheitspolitik ist auf solidem Stammtischniveau. Der soll mal bei Computern bleiben— Dr. Sandro Gaycken, u.a. NATO-Berater in Sicherheits- und Cyber-Fragen
Also von Kernenergie hat er ja keine Ahnung, der sollte mal bei Computern bleiben.— Rainer Klute, Vorsitzender, Nuklearia e.V.
Also von Journalismus hat er ja keine Ahnung, der soll mal bei Computern bleiben— ihr werdet nicht glauben, was ich alles versucht habe, um jemanden zu finden, der sich dieses Zitat in den Mund legen lassen würde. Ich habe die "Bild" angeschrieben, die "Welt", den "Stern", den "Cicero", die "taz", ich habe bei der "Zeit" und dem ehemaligen Nachrichtenmagazin angefragt … erfolglos. Niemand wollte mir bestätigen, dass ich von Journalismus keine Ahnung habe. Vielleicht hätte ich die Henri-Nannen-Schule versuchen sollen.
Heißt das jetzt, dass ich doch von Journalismus Ahnung habe? Wer weiß. Diese Aktion hier hat es mir jedenfalls versaut.
Also von Satire hat er ja keine Ahnung, der soll mal bei Computern bleiben.— Martin Sonneborn, MEP und Parteivorsitzender der PARTEI.
Also von Krypto hat er ja keine Ahnung, der soll mal bei Exploits bleiben.Das lege ich so mal ganz frech meinem alten Mitstreiter Prof. Dr. Rüdiger Weis in den Mund. Der schrieb mir inhaltlich im Wesentlichen das, er formuliert es nur etwas weitschweifender. Ich tue das gleich noch mal in einen separaten Blogeintrag. :-)
Also von Exploits und deren ethischer Dimension hat er ja keine Ahnung, der soll mal bei Verschwörungstheorien bleiben.— Felix "FX" Lindner, mit dem ich gelegentlich verwechselt werde, und das erst nach dem 2. Bier merke. Dabei ist das ganz einfach. Er ist der, der von Exploits und ihrer ethischen Dimension Ahnung hat. Ich bin der andere.
Zusammenfassend können wir also ganz klar sehen, was eh schon immer alle wussten: Ich sollte mal bei den Verschwörungstheorien bleiben.
Ich hatte übrigens auch die Junge Freiheit gebeten, mir zu bestätigen, dass ich eine linke Zecke bin, und die Junge Welt, dass ich ein konservativer Reaktionär bin. Ist leider auch nichts geworden. Naja, die Kernbotschaft habe ich glaube ich weitgehend zusammen gekriegt.
Update: Falls ihr kurzfristig noch Zitate beisteuern wollt: immer her damit. Das muss dann aber schon mindestens das toppen, was ich schon habe.
Update: Wartet, einen hab ich noch!
Seit wir uns verweigert haben, Werbung auf seinem Blog zu schalten, werden wir von ihm gebashed
— Thorsten Sick, Avira.
(Anm.d.Red.: Da hing noch so eine Werbe-Signatur dran, die hab ich weggemacht. Das verstößt gegen die Blog-Statute)
Update:
Also von Journalismus hat er ja keine Ahnung, der soll mal bei Computern bleiben
— Andreas Bohle, stellv. Chefredakteur, LinuxUser
Oh, übrigens: Told you so!
So. Yes, thats correct: The SELinux system that is only there to protect you, passes attacker controlled data to sh -c (https://docs.python.org/2/library/commands.html) ainside a daemon running as root. Sacken lassen…
GET / HTTP/1.1Das ist ein HTTP-Request. Die Antwort sieht dann so aus:
Host: www.server.com:80
HTTP/1.1 OKDas Problem ist jetzt, dass das idealisierte Beispiele waren. Tatsächlich sehen Requests nämlich so aus:huhu
GET / HTTP/1.1Und Antworten sehen so aus:
Host: www.cnn.com:80
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate DNT: 1 Cookie: token=kiMLX8/1ni34+wrDrAfx7XDDNjSLJhzIXFL27VY2SwM= Connection: keep-alive
HTTP/1.1 200 OK x-servedByHost: prd-10-60-165-21.nodes.56m.dmtio.net Cache-Control: max-age=2592000 Content-Type: text/html Via: 1.1 varnish Content-Length: 11502 Accept-Ranges: bytes Date: Mon, 09 Mar 2015 16:37:46 GMT Via: 1.1 varnish Age: 702161 Connection: keep-alive X-Served-By: cache-iad2130-IAD, cache-lax1421-LAX X-Cache: HIT, HIT X-Cache-Hits: 1414, 5 X-Timer: S1425919066.634699,VS0,VE0 Vary: Accept-Encoding [… der HTML-Inhalt …]Praktisch alles davon ist überflüssig. Sowohl auf Client-, als auch auf Serverseite. Ein Teil davon ist dem Standard geschuldet (wieso muss der Server bitte das Datum mitschicken?!), aber der Großteil ist einfach Bloat von Clients und Servern. Alleine schon der User-Agent ist eine Größenordnung zu groß. Der Accept-Header ist ein typischer Fall von Feature Creep, war mal gut gemeint, hat aber so dermaßen auf ganzer Linie verkackt, dass da jetzt "*/*" als "akzeptierter MIME-Type" drin steht. Damit wird natürlich die Intention des Headers völlig unterwandert und man könnte ihn auch eigentlich komplett weglassen. Ähnlich sieht es mit Accept-Languages aus. Das war mal dafür gedacht, dass der Browser sagt "mein Benutzer spricht Deutsch, kann aber auch Englisch", und die Webseite gibt dann ihre deutschsprachige Version heraus. Das benutzen tatsächlich einige Webseiten. So gefühlt 3 oder 4. Hätte man sich also auch sparen können. Accept-Encoding sagt, dass der Browser auch gzip und deflate kann. Das hätte man schlicht als Default in den Standard schreiben können, dann würde man sich das sparen, dass alle Browser das mitschicken. DNT ist der Do-Not-Track-Header. "Liebe Werbetreibenden, bitte missbraucht meine Daten nicht!1!!" Ja nee, klar. Die Cookies sind im Verantwortungsbereich des Webseitenbetreibers, da kann der Browser nichts für. Der Connection-Header hier ist auch für den Fuß, weil keep-alive bei HTTP/1.1 Standard ist. Aber sicherheitshalber, falls der Server nur 1.0 kann, schicken wir es nochmal mit. Ihr seht schon, das ist ein verkrusteter Haufen fossiler Brennelemente.
Schlimmer noch sieht es auf der Serverseite aus. Da sind die Hälfte der Header direkt für die Tonne und kommen auch offenbar gar nicht vom Webserver sondern von dem Varnish-Cache davor. So nützlich wie ein Hirntumor!
So und jetzt schauen wur uns das mal zusammen an und überlegen uns eine Strategie. KLAR! Die Cookies sind das Problem!1!! Also war die Lösung der Webseiten-Optimierer-Spezialexperten, dass sie die 100 Milliarden Inline-Bilder auf eine separate Domain ausgliedern. Dann werden bei den Requests an die keine Cookies der Hauptdomain übertragen. WAS MAN DA FÜR EINEN TRAFFIC SPART!!1! Leider handelt man sich auch einen zusätzlichen DNS Round Trip ein. Aber hey, das sieht man in Benchmarks nicht so, weil das eh schon im Cache ist!1!!
Kurzum: HTTP/1.0 hat Probleme in der Praxis. Beachtet aber das "Connection: keep-alive". Das heißt, dass der Server die Verbindung nach diesem Request offen hält. Der Client kann dann den nächsten Request absetzen. Das entsorgt direkt das wichtigste Argument für HTTP/2, das mit dem "wir wollen aber nur ein Handshake am Anfang der Verbindung haben, weil das so teuer ist".
Also haben die HTTP/2-Apologeten argumentiert, naja gut, das Handshake ist nicht das Problem, sondern die Latenz pro Antwort ist das Problem. Um das zu illustrieren, muss man ein bisschen malen. Ich mache das mal in ASCII Art, mit ??? für den Request und === für die Antwort.
??? ???So stellt man sich eine typische HTTP-Verbindung vor. So ist das auch — im LAN. Über das Internet gibt es Latenzen zwischen ??? und ===. Die male ich jetzt mal als |||.
=== ===
??? ???Ihr seht, diese Latenzen dominieren schnell. Daher gibt es in HTTP/1.1 ein Verfahren namens Pipelining. Das sieht dann so aus:
||| ||| ||| |||
=== ===
?????????Die Latenz ist nicht weg, aber sie ist viel weniger schlimm. Leider implementieren das einige wenige Webserver nicht. Und um diese Webserver im Geschäft zu halten, schalten die Browser Pipelining aus. Nein, wirklich! Geht mal in Firefox auf about:config und sucht nach network.http.pipelining.
|||||||||||||||
=========
Weil das der zentrale argumentative Dreh- und Angelpunkt der HTTP/2-Apologeten ist, will ich jetzt mal einen Trick mit euch teilen.
Der Grund, wieso einige Webserver Pipelining nicht können, ist, dass deren Haupt-Schleife so aussieht:
Solange TCP-Verbindung besteht:Bei Pipelinig kommen jetzt mehrere Requests in einem Stück Daten rein. Der Server hat die Logik nicht, um hinter dem 1. Request nach weiteren zu gucken. Aber man kann auch mit so einem Server Pipelining machen. Ich habe das vor vielen Jahren mal für einen Usenet-Downloader implementiert, und später für SMB, bei HTTP geht das genau so. Man schickt den nächsten HTTP-Requests nicht, nachdem das letzte Byte der Antwort des vorigen angekommen ist, sondern nachdem das erste Byte der Antwort des vorigen angekommen ist.
Lese Daten
Wenn die Daten ein HTTP-Request sind, beantworte ihn
Das lohnt sich leider erst, wenn die Downloadgrößen deutlich größer als die Request-Größen sind. Daher ändere ich mal die Symbolik ein bisschen in der ASCII-Art. Vorher:
??? ???Was die Grafik euch sagen will: Der zweite Request kommt beim Server an, während der noch den ersten beantwortet. So kann man das machen. Warum das bei HTTP keine Option war? Weil inzwischen bei einigen Sites für einige Requests die Header größer als die Inhalte sind.
vvv ^^^ vvv
===============
Meine Einstellung dazu ist: Einfach immer Pipelining vorschreiben und anschalten, und wer das nicht implementiert, der kann halt nicht mitspielen. Ich hab das am Anfang in gatling auch nicht implementiert gehabt, weil es eh keiner benutzt hat. Diese Art von Verhalten geht überhaupt nur, weil die Browser einen damit durchkommen lassen. Das sollten sie nicht.
Hat HTTP/2 denn jetzt überhaupt keine Vorteile? Doch. Zwei. Erstens haben sie sich ein Verfahren überlegt, um Header zu komprimieren. Ich habe mir davon die Details noch nicht angeguckt. Ich sah bisher nur Negatives darüber, aber das will ja nichts heißen. Zweitens schreiben sie für den TLS-Teil TLS 1.2 vor.
Merkt ihr was?
Wir könnten auch einfach HTTP/1.1 nehmen, Pipelining und TLS 1.2 vorschreiben, und wir hätten so gut wie alle Vorteile von HTTP/2 ohne die Nachteile.
Welche Nachteile? Nun, HTTP/2 macht Multiplexing. Multiplexing heißt, dass sie mehr als eine virtuelle Verbindung über eine TCP-Verbindung fahren. Das ist eine ganz beschissene Idee.
Stellt euch mal Youtube vor. Sobald er das Video überträgt, ist die Multiplex-Verbindung ausgelastet und die Kommentare kommen nie. Außer der Server hat Logik, um faires Scheduling zu implementieren. Ja ganz groß!
Geht noch weiter. Stellt euch mal vor, der Server hat fair scheduling implementiert. Ist immer noch Scheiße. Denn einige Elemente einer Webseite können andere Elemente referenzieren, Inline-Bilder, Skripte, was auch immer. HTML und CSS sollten daher zuerst übertragen werden, auch damit der Browser schonmal das Layout machen kann, und dann später die Bilder reinlädt. Jetzt muss der Server also schon intelligentes Scheduling implementieren. Am besten mit Content Sniffing. Denn das wird die nächste Anforderung sein, dass der Server das HTML/CSS parsed und die Dateien schonmal öffnet und reinlädt, die der Browser gleich haben wollen wird.
Aber nein, da haben die HTTP/2-Leute eine noch bessere Idee gehabt. Sie sehen vor, dass der Browser dem Server sagt, was mit welcher Priorität kommen soll.
Ihr sehr schon: Alleine um Probleme zu lösen, die wir vorher nicht hatten, treiben wir hier ungefähr so viel Aufwand, wie wir vorher für den ganzen Webserver getrieben haben.
Daher glaube ich, dass HTTP/2 ein Schuss in den Ofen ist.
Aber wartet. Einen habe ich noch. Nehmen wir mal an, wir haben Paketverlust auf der Leitung. Bei HTTP/1 bleibt dann eine Verbindung stehen. Eine von sechs oder wieviel auch immer der Browser aufgemacht hat. Bei HTTP/2 bleibt dann alles stehen, weil alles über die eine Verbindung ging. JA SUPER!
Erwähnte ich, dass HTTP/2 mit dem Header-Wildwuchs nicht aufgeräumt hat? Dafür gibt es ja jetzt Kompression. Hier ist die Spec dazu.
Leider haben die auch ansonsten im Protokolldesign und der Spec einmal großflächig alles verkackt, was man so verkacken kann. Klickt euch mal in diesem Mailinglistenarchiv nur durch die Postings von Bob Briscoe der letzten Tage. Übrigens ist auch der Autor von varnish nicht begeistert von HTTP/2.
Ich frage mich, ob Debian das mitkriegt, wenn ihnen die Nutzerzahlen wegbrechen.
Ich habe neulich ja aus Testgründen mal Arch Linux installiert und der hat mir auch erstmal ungebeten systemd installiert. Ich glaube, das wird bei Linux jetzt was die ganze Ad- und Bloatware bei Windows ist. Nach der Installation muss man erstmal den ganzen ungewollten Scheiß wegoperieren, den einem die Distro so auf die Platte spült. Sehr schade, dass wir die negativen Aspekte von Windows kopieren, bevor wir die positiven nachgemacht haben.
Ich erwähne das, weil sich der eine oder andere (hoffentlich!) gefragt haben wird, wieso wir von dem halbwegs wohlverstandenen Antik-BIOS zu dem klaffenden Sicherheitsloch UEFI wechseln, und wieso Lenovo uns Krypto-Technologien aufdrängen will, die uns daran hindern, etwaige NSA-Hintertüren im BIOS (wir erinnern uns bei der Gelegenheit an die "Bad-BIOS"-Geschichten) durch Flashen eines eigenen BIOS zu ersetzen.
Ja, das liegt an der NSA. Vollumfänglich liegt das an der NSA.
Was mir besonders auf den Sack geht, sind die Leute, die jetzt so tun, als ginge es bei TPM ja nur um Measured Boot, und dieser Bootguard-Scheiß sei bloß eine Aberration. Nein, ist es nicht. Das war der ursprüngliche Plan. Als die Geschichte noch Palladium hieß und ein Microsoft-Projekt war, um den NSA-Anforderungen zu genügen. Damals hieß es: Im Moment können wir TPM nur als passive Komponente neben die CPU löten, aber in der nächsten Generation (wir reden hier von Pentium 4-Zeiten!) ist das dann in der CPU und dann kann man das auch nicht mehr abschalten. Damals haben wir massive Proteste losgetreten, woraufhin das TPM eine (optionale!) passive Komponente neben der CPU blieb. Das Narrativ der NSA-Schergen änderte sich daraufhin zu "aber guckt mal, ihr könnt doch selber Schlüssel hochladen, und dann könnt ihr damit euer Linux absichern!1!!" Und einige Elemente unserer Community haben diesen Bullshit auch noch geglaubt!
Liebe Leute, wir befinden uns hier gerade in einem Krieg um unsere informationstechnischen Plattformen. Wer die Plattform besitzt, kontrolliert auch die auf ihr stattfindenden Dinge. Das sollte spätestens seit Facebook auch dem letzten Idioten klar sein, ist es aber offensichtlich nicht.
Intel glaubt jetzt offenbar, hey, die Leute da draußen sind alle dümmer als ein Stück Brot. Wir probieren das einfach nochmal und tun das TPM in die CPU. Damit es keiner merkt, nennen wir es "Boot Guard" und lassen das TPM daneben bestehen. Für die Plausible Deniability machen wir das "optional", und dann kriegt Lenovo den Gegenwind ab und nicht wir. Und wenn wir Glück haben, dann kommen so Spezialexperten wie Patrick Georgi und erkennen nicht nur nicht, dass Boot Guard ein TPM wie ursprünglich geplant ist, sondern bringen auch noch das Argument, dass das ja was anderes als "das TPM" sei, und versteigen sich dann auch noch zu der Ansage, dass TPM uns retten wird vor Boot Guard. Ach ja, ist das so? OK, zeig mal. Ich hab hier ein System, auf das habe ich coreboot geflasht, und es bootet nicht mehr. Zeig mir doch mal, wie TPM mich jetzt rettet, Patrick!
Warum reibe ich mich so an diesem einzelnen Verirrten? Weil der eigentlich auf unserer Seite kämpft! Das ist ein Coreboot-Entwickler! Ich will dem jetzt nicht unterstellen, ein NSA-Uboot zu sein. Aber vom Effekt seiner Aussagen her könnte er kaum mehr auf Seite der NSA kämpfen.
Liebe Nerds, so geht das nicht weiter. Schlimm genug, wenn die Politik keine Folgenabschätzung macht. Schlimm genug, wenn die Physiker Atombomben bauen, ohne zu wissen, ob deren Detonation am Ende unsere Atmosphäre verbrennen wird. Wenigstens wir müssen uns bei solchen Sachen langfristige Gedanken machen! Und nicht auf Geheimdienste und ihre Talking Points reinfallen!
Es reicht nicht, über die Politik zu meckern, wenn die unsere Freiheit auf dem Altar der Sicherheit opfern. Secure Boot ist genau das selbe in grün.
Und so kommt zusammen, was Rüdi uns seit Jahren als Horrorszenario auf den CCC-Kongressen und anderswo erzählt bezüglich TPM. TPM verhindert, dass wir unsere Hardware mit der Software unseres Vertrauens betreiben können.
Das ist die Apple-isierung unserer Computing-Infrastruktur. Erinnert ihr euch noch an früher? Da kaufte man einen Fernseher, und die Baupläne lagen bei. Der PC konnte seinen Siegeszug überhaupt nur antreten, weil er eine offene Plattform war. Das ist jetzt offensichtlich so tot wie das FAZ-Feuilleton. Zuckt noch ein bisschen. Und dann wundern sich alle, dass die Leute lieber Tablets kaufen. Tja, wenn ihr mir den Vorteil der PC-Plattform wegnehmt, geb ich euch auch nicht mehr den Aufpreis für einen PC.
Einmal mit Profis arbeiten!
Auf einer gewissen Ebene hat er natürlich Recht. Auf der anderen Seite hat Snowden seinen Scheiß halt nicht mit Moxies Scheiß vor der NSA gerettet sondern mit GPG. Und am Ende kommt er dann mit:
GPG isn’t the thing that’s going to take us to ubiquitous end to end encryption, and if it were, it’d be kind of a shame to finally get there with 1990’s cryptography.Damit wären wir wieder bei den Ansprüchen. GPG hat nicht den Anspruch, universelle Ende-zu-Ende-Verschlüsselung zu machen. GPG ist für Email. Nicht für Webseiten, nicht für Chat (obwohl man es in XMPP verwenden kann), nicht für Telefonieverschlüsselung. Die Kritik ist unwürdig.Ich will da jetzt nicht groß ins Detail gehen, aber so richtig vollständig überzeugend ist auch Moxies Software bisher nicht. Die andere Sache, die sich durchgesetzt hat, ist OTR. Auch das ist nicht von Moxie. Ich finde das nicht angemessen, wenn er sich da so aus dem Fenster lehnt. GPG ist nicht schlecht, weil es alt ist. OTR nicht gut, weil es neue Krypto benutzt. Moxie macht sich das hier viel zu einfach.
Ich will dem mal entgegen halten, dass praktisch alle Linux-Distributionen, die überhaupt Krypto zum Validieren der Paketintegrität einsetzen, dafür GPG benutzen. Das muss man erst mal schaffen, so eine Marktdurchdringung.
Update: Statement der Schuldigen (Achtung: Link geht zu Facebook)
Um mal das konkrete Problem zu beziffern, das ich gerade zu lösen versuche: Ich suche in meinem Index über ca 23 GB Quellcode, ca 550k Dateien. Mein Index grenzt die Suche nach memcpy auf ungefähr 23000 Dateien ein. Diese Dateien muss ich dann alle einmal öffnen und die Treffer mit Zeilennummer ausgeben. Das ist die Aufgabe dieser Suchmaschine.
Der alte Code braucht dafür ca 2 Sekunden (wenn alle Dateien im Cache sind, sonst natürlich deutlich länger). Der neue Code braucht hier gerade nur 1,17 Sekunden.
Eine spannende Lektion habe ich aber noch. Ich habe den Code einmal auf Futures umgestellt, das ist ein Feature von C++11. So sieht der Ausgabe-Code ohne Futures aus:
for (auto& x : hits)Und so sieht er mit Futures aus:
cout << grep(words,x.first);
vector<future<string>> v(hits.size());Die Idee ist, dass zwischen dem async und dem x.get() die Arbeit aus den Futures auf einen Threadpool verteilt wird, und wenn ich unten x.get auf ein Element in dem Vector aufrufe, dann macht der Code einen Thread-Join, falls der Thread nicht eh schon von sich aus fertig war. Die ganze Synchronisation findet also implizit statt.
size_t i=0;
for (auto& x : hits)
v[i++]=async(grep,words,x.first);
for (auto& x : v)
cout << x.get();
Die erste Ernüchterung: Nix Threadpool. Die Standardpolicy von g++ 4.9.2 unter Linux ist, das dann statt async als deferred auszuführen, d.h. da werden keine Threads gestartet sondern bei x.get() wird das halt schnell synchron ausgeführt. Das ist dann natürlich nicht schneller als es direkt synchron auszuführen. m(
Aber man kann auch g++ 4.9.2 unter Linux sagen, dass man gerne Threads haben will:
for (auto& x : hits)Damit hab ich dann statt 100% CPU immerhin ~300% CPU (also drei Cores werden ausgelastet), aaaaaaber: es ist nicht schneller als es synchron zu machen. Im Gegenteil. Das kostet plötzlich rund 1,6 Sekunden. Das Konzept mit den Futures heißt in anderen Sprachen auch Promise. Es gibt auch in C++ Promise als Konzept. Ich habe den Unterschied zwischen Future und Promise noch nicht verstanden, und es gibt auch noch ein drittes Ding, Packages, das auch sowas ist. (Ihr müsst mir das jetzt nicht erklären, ich kann das Manual schon auch lesen, habe es lediglich noch nicht getan an der Stelle)
v[i++]=async(std::launch::async,grep,words,x.first);
Was ich jedenfalls sagen will: Abstraktionen sind ja schön und gut, aber wenn ich dann am Ende Hand anlegen muss, damit das einen Speedup ergibt, dann ist das für den Fuß. Vielleicht übersehe ich irgendwas gerade, aber aus meiner Sicht ist das hier gerade die perfekt parallelisierbare Sache, eine Datei öffnen, darin Matches suchen, und die Ergebnisse dann seriell ausgeben. Vielleicht bringt das ja nur was, wenn er dafür tatsächlich zum Massenspeicher gehen muss, und wenn das eh aus dem Buffer Cache des Systems kommt, dann hat man keinen Vorteil aber trägt die Kosten für die implizite Synchronisierung. Oder so. Ich weiß es nicht. Ich untersuche das jetzt auch nicht mehr :-)
(Es geht hier übrigens gerade nicht darum, wie man schönen C++-Code schreibt, sondern wie Futures aussehen)
Update: Äh, gcc 4.9.2 nicht 2.9.2 :)
Update: Einige Leute schlagen jetzt OpenMP vor. Ja, mit OpenMP geht das, sogar richtig gut. Damit komme ich dann auf 0,58 Sekunden. Mein Punkt mit diesem Blogeintrag war, dass dieser Standard so nicht hätte ausgerollt werden dürfen. Jetzt wird eine Generation C++-Programmierer lernen, dass man sein Threadpooling doch von Hand oder mit 3rd-Party-Kram wie OpenMP macht, und das erschafft einen Haufen an Legacy-Code, den wir in Zukunft werden warten müssen.
Sorry, aber so läuft das nicht. Richard Stallman hat auch sein Leben der guten Sache gewidmet. Linus Torvalds auch. Was ist mit den OpenBSD-Leuten? Den OpenSSL-Leuten?
Wer sein Produkt kostenlos verteilt, der kann nicht nachher herumheulen, dass sich nicht aus magischen Quellen Geld auf seinem Tisch manifestiert hat. Das muss man vorher durchfinanziert haben, dass man die Entwicklung durchführen kann. Sonst sucht man sich einen Mäzen oder einen Sponsor oder macht Crowdfunding, vielleicht ein Regierungsprojekt. Man kann gucken, ob man eine Gemeinnützigkeit anerkannt kriegt. Ist das mit Aufwand verbunden? Klar! Wer das nicht macht, hat mein Mitleid nicht verdient, sorry.
Ich schreibe auch seit 20 Jahren freie Software. Sieht mich jemand herumheulen, dass ich mir kein Abendbrot leisten kann? Nein. So läuft das nicht.
Werner Koch ist im Übrigen in der ausgesprochen privilegierten Position, dass er sogar mehrfach von der Bundesregierung Förderkohle eingesackt hat. Und dann hat er auch noch ein erfolgreiches Crowdfunding durchgezogen. Was sollen denn bitte die ganzen anderen Leute sagen?! Die, denen die Regierung keine Kohle nachwirft? Die, deren Crowdfunding in der Obskurität verlischt?
Sorry, Werner. Du schläfst in dem Bett, das du dir gebettet hast. Wenn du da jahrzehntelang dein Lebens-Management verkackst, dann stelle dich bitte nicht am Ende hin und winsel herum, dass dir die Welt ein bedingungsloses Grundeinkommen schuldet. Sowas kriegt man nicht durch geduldig Warten.
Ich persönlich bin ein Freund des bedingungslosen Grundeinkommens, unter anderem gerade damit auch Leute wie Werner Koch Software wie gnupg schreiben können, ohne sich Sorgen um ihre Abendbrot machen zu müssen. Aber soweit sind wir noch nicht. Die Realität geht nicht weg, wenn wir sie lange genug leugnen.
Im Übrigen, aber das ist nicht mein Hauptpunkt hier, finde ich die Wartung von gnupg auch keinen Vollzeitjob. Sorry, nein, ist es nicht. Seit wann macht er das jetzt? 20 Jahre? Gelegentlich kommt mal ein Feature dazu, das will ich nicht leugnen. Features, die 90% der gnupg-Benutzer nicht betrifft, sowas wie Smartcards. Aktuell wohl auch elliptische Kurven, das betrifft schon eher jemanden. Aber elliptische Kurven haben die finanziell noch schlechter aufgestellten OpenSSL-Leute ganz ohne murren mal eben nachgerüstet.
Liebe Geeks. Wir haben hier ein strukturelles Problem. Freie Software finanziert sich nicht von selbst. Auf göttliche Intervention warten ist keine Lösung. Sucht euch einen Job, der euch Spaß macht. Am besten nichts, was mit Softwareentwicklung zu tun hat. Sonst habt ihr nämlich abends nach der Arbeit auch keinen Bock mehr auf Softwareentwicklung.
Und dann entwickelt ihr in eurer Freizeit freie Software. Und dann geht ihr in eurem Bett schlafen, unter dem Dach, das ihr euch mit dem anderen Job finanziert habt. So wird ein Schuh draus.
Noch was: Geschenken wirft man keinen Guilt Trip hinterher. Entweder es ist ein Geschenk, dann erwartet man nichts dafür, oder es ist kein Geschenk. Freie Software ist ein Geschenk. Klar darf man sich über Spenden freuen. Aber meckern, wenn sie ausbleiben, darf man nicht.
Update: Oh und einen Punkt möchte ich noch machen. Es wird häufig geheult, dass so viel Open Source Software angeblich in so einem schlechten Zustand ist, angeblich weil die Leute das nicht als Vollzeitjob machen. Das stimmt so nicht. Ich zum Beispiel schreibe Software nicht als Selbstzweck, sondern weil ich was lernen will. Aspekte, bei denen ich nichts lerne, oder die mich nicht interessieren, mache ich dann auch nicht. Die Ausgabe von Fließkommazahlen im printf der dietlibc ist seit Tag 1 kaputt. Dass das nicht gefixt wird, liegt nicht daran, dass ich nen Job habe, der mich ablenkt. Sondern das liegt daran, dass mir andere Sachen wichtiger sind. Das ist eine Frage der Prioritäten, nicht der Ressourcen. Jeder von uns hat genug Freizeit um alles zu schaffen, was er wirklich schaffen will.
Update: Oder aber natürlich man macht das zum Beruf. Gründet eine Firma, die Open Source macht. In einigen Fällen hat das sogar funktioniert. Wenn das gelingt, ist es natürlich der heilige Gral. Aber ich habe zwei Befürchtungen. Erstens ist es nicht mehr das Gleiche, wenn man dafür bezahlt wird. Es macht irgendwann weniger Spaß, wenn es ein Beruf ist und nicht etwas, das man aus freien Stücken tut. Zweitens muss man ja trotzdem irgendwoher Einnahmen generieren. Support für das Produkt ist hier eine populäre Option, aber das kann man nur bringen, wenn das Open-Source-Produkt soweit fertig und stabil ist und eine wichtige Sache löst und breit eingesetzt wird. Das ist eine verschwindende Minderheit der Projekte. Und dann ist die Arbeit, die man tut, auch eher Wartung als Entwicklung. Die Frage also, wie man die Entwicklung von freier Software finanziert kriegt, ist damit weiterhin nicht geklärt.
Als letzte Option bezahlen auch manche große Firmen wie IBM oder Oracle oder Linux-Distributoren ein paar Leute für ihre Arbeit an Open Source-Projekten. Das halte ich für nicht realistisch genug, um das generell als Lebensmodell zu empfehlen. Ein paar Leute können sich das so drehen. Der Rest — fast alle! — nicht.
Update: Es haben sich $50k/Jahr-Sponsoren gefunden. Und genau die Art von Leuten, von denen man Geld annehmen möchte!1!! Na seht ihr, ist doch noch alles gut ausgegangen. Wenn ihr Werner Koch wäret, wäret ihr jetzt zufrieden?
Update: Oh und die Linux Foundation wirft auch nochmal $60k hinterher.
Update: Ich mache mir Sorgen, dass jetzt lauter Kids glauben, das könnte für sie auch funktionieren. Leute, niemand von euch hat den Hauch einer Chance, das als Finanzierungsmodell für das Leben zu replizieren. Das ist wie auf einen Lottogewinn zu hoffen. Holt euch lieber einen richtigen Job und entwickelt nebenher freie Software. Das ist das realistische Modell. Ich finde nach wie vor, dass man Leute, die sich wie Werner ohne Fallschirm aus dem Flugzeug stürzen, nicht auffangen sollte. Sonst validiert man damit das Modell, dass man so seinen Lebensunterhalt verdienen kann. Und dann machen lauter Andere das nach.
Update: Auf dem zweiten Platz: Javascript, ISO-8601 und Time Zones.
Da bin ich ja mal gespannt, wie das wird, wenn Microsoft .NET nach Linux portiert. Wenn ich das richtig verstehe, soll das dann auch eine Zielplattform 1. Klasse innerhalb von Visual Studio werden. Das hätte das Potential, den ganzen herumgammelnden Open Source Initiativen mächtig Feuer unterm Hintern zu machen. Spannend!
Update: Ah, anscheinend will Microsoft ihr .NET mit Mono mergen.
Update: Ich sollte vielleicht dazu sagen, dass ich mir wegen systemd nicht viel Sorgen mache. Demnächst ersetzen sie dann den Linux-Kernel und dann haben wir endlich wieder Ruhe. Kann sich nur noch um ein paar Wochen handeln. Und nächstes Jahr entwickelt systemd dann zu Bewusstsein und beantragt einen permanenten Sitz im Sicherheitsrat. DANN können wir uns wieder Sorgen machen.
drwx------ root/root 0 2014-10-02 02:53:49 ./ drwxr-xr-x root/root 0 2014-10-02 02:53:49 ./usr/ drwxr-xr-x root/root 0 2014-10-02 02:53:49 ./usr/share/ drwxr-xr-x root/root 0 2014-10-02 02:53:49 ./usr/share/man/ drwxr-xr-x root/root 0 2014-10-02 02:54:04 ./usr/share/man/man1/ -rwxr-xr-x root/root 4840 2014-10-02 02:54:04 ./usr/share/man/man1/google-chrome-unstable.1u.s.w.
Fälle jemandem was auf? Wenn man das in / auspackt, dann ist danach / nur noch für root les- und ausführbar.
Einmal mit Profis arbeiten!
Das ist das hier:
-rw-r--r-- 1 leitner users 47942700 Oct 3 03:24 google-chrome-unstable_current_amd64.deb
Bevor ihr jetzt stöhnt, lest euch erst mal das Money Quote durch:
However, we have identified a problem with Linux kernel, the result of which was that secret random seed values (e.g., net_secret, syncookie_secret, inet_ehash_secret, etc.) were never initialized on some systems.So, JETZT dürft ihr stöhnen. *Stöhn*Update: Link geändert, weil der Ursprungslink jetzt eine Werbe-Redirect ist.
Geschichten aus dem Linux-Schützengraben.
Die Idee ist, dass ein Prozess Seccomp anschalten kann, das ist dann auch nicht revidierbar, und ab dann kann er nur noch read, write, exit und sigreturn machen, und read und write geht auch nur auf vorher schon geöffnete Deskriptoren. An sich keine doofe Idee, mal abgesehen von dem Verkaufen-Aspekt, aber hat sich m.W. nie in der Realität für irgendwas durchsetzen können. Es war doch ein bisschen zu restriktiv. Das Original-Seccomp war von 2005.
Und wo wir gerade bei Geschichtsstündchen sind, erzähle ich euch auch mal was von BPF, dem Berkeley Packet Filter. Wenn man unter Unix Netzwerktraffic sniffen will, nimmt man im Allgemeinen libpcap, die das schön abstrahiert. Die kann auch filtern. Man kennt die Syntax von tcpdump:
# tcpdump -s0 host 10.0.0.1 and tcp and not port 22Wenn man so einen Filter hat, dann will man ja nicht, dass der Kernel einem alle Pakete gibt und man selber filtert, sondern man will dem Kernel das mitteilen und der gibt einem dann nur die passenden Pakete raus. Der Mechanismus dafür heißt BPF und ist aus Programmsicht ein Array mit Bytecode-Instruktionen drin. Die haben alle eine fixe Länge, insofern eher RISC als Bytecode, aber der "Instruktionssatz" ist wunderschön archaisch. Da gibt es zwei Register, den Akkumulator und das Index-Register. Es gibt Load und Store, ALU-Operationen und Vergleiche mit Sprüngen. Ganz krude Geschichte. Hier ist mal ein Stück Beispielcode:
struct bpf_insn BPFAcceptIPSource[] = {
// Check Ethernet Protocol Word At Offset 12
BPF_STMT(BPF_LD+BPF_H+BPF_ABS, 12),
BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, ETHERTYPE_IP, 0, 3), // Check Source IP address At Offset 26
BPF_STMT(BPF_LD+BPF_W+BPF_ABS, 26),
BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, 0x01020304, 0, 1),//Source == 1.2.3.4
BPF_STMT(BPF_RET+BPF_K, (UINT)-1), // Accept.
BPF_STMT(BPF_RET+BPF_K, 0 )
};
Wer da keine feuchten Finger kriegt, ist kein echter Hacker! Und ich meine jetzt nicht nur wegen des Endianness-Problems. :-)Jedenfalls, wieso ich das erwähne: Eines Tages hat sich ein Schlaufuchs überlegt, hey, wir haben seccomp im Kernel, und wir haben BPF im Kernel, wir könnten doch einfach BPF statt auf ein Netzwerkpaket auf eine wohldefinierte Struct loslassen, wo die Syscall-Daten drinstehen, und dann kann sich der Userspace seine Regeln selbst definieren, welche Syscalls erlaubt sein sollen und welche nicht. Und genau das gibt es jetzt seit ein paar Jahren (?), und es heißt "Seccomp Filter" oder "Seccomp Mode 2".
Ich blogge das hier, weil ich sowas seit vielen Jahren haben will. Die Leute dahinter sind von Google und arbeiten an Chrome OS. Mir ist das überhaupt nur aufgefallen, dass es das jetzt gibt, weil aktuelle Versionen von Portable OpenSSH das als Sandboxing-Mechanismus benutzen — sehr cool!
Heute ergab sich erstmals für mich eine schöne Gelegenheit, das selber mal einzusetzen. Ich arbeite gerade in einem Kundenprojekt an Monitoring. Eines der in dem Projekt entstandenen Tools macht grob das selbe wie "vmstat 1", aber gibt das Ergebnis als CGI als text/event-stream aus, und auf der anderen Seite sitzt dann eine Webseite mit ein bisschen Javascript, das aus den Events SVG-Visualisierungen erzeugt. Dieses vmstat-CGI-Tool ist ein perfekter Kandidat für Seccomp-Filter, fand ich. Es öffnet turnusmäßig ein paar Dateien unter /proc und /sys, macht ein bisschen malloc, ein bisschen gettimeofday, und ruft dann write auf, um die Daten rauszuschreiben. Syscalls wie fork, execve, socket, kill oder connect muss der nie aufrufen. Also sage ich dem Kernel: Wenn dieser Prozess das doch tut, dann kille ihn sofort.
Als ich darauf per Seccomp-Filter eine Selbstbeschränkung programmiert habe, fiel mir auf, dass die bisherigen Codestücke nur auf die Syscallnummer gucken, weil das alles war, was die Chrome-OS-Leute in die Dokumentation getan haben. Aber die Struct beinhaltet auch die Syscall-Argumente. Das ist nur für den Fall nützlich, wo das keine Pointer auf Strings sind, denn denen kann man nicht hinterherlaufen aus dem BPF-Code heraus, aber man kann z.B. sowas machen wie: open() geht nur mit O_RDONLY. Dafür habe ich keinen Code gefunden, daher habe ich ihn selber geschrieben, und dachte mir, das tu ich mal in mein Blog, damit es andere Leute finden können, die möglicherweise auch mal in dieses Problem laufen. Die grobe Codestruktur von so einem Seccomp-Filter-Programm ist:
Hier ist mein Code für open():
/* we need a special case for open.
* we want open to succeed, but only if it's O_RDONLY */
BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_open, 0, 4),
/* it's open(2). Load second argument into accumulator (first
* argument is filename, second is mode). We want to check if mode
* is O_RDONLY and only allow the syscall through if it is. */
BPF_STMT(BPF_LD+BPF_W+BPF_ABS, offsetof(struct seccomp_data, args[1])),
/* if it's O_RDONLY, skip 1 instruction */
/* slight complication: on 32-bit platforms we also pass O_LARGEFILE */
#if __WORDSIZE == 64
BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, O_RDONLY, 1, 0),
#else
BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, O_RDONLY|O_LARGEFILE, 1, 0),
#endif
/* "return SECCOMP_RET_KILL", tell seccomp to kill the process */
BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_KILL),
/* "return SECCOMP_RET_ALLOW", tell seccomp to allow the syscall */
BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW),
Möge er von Hackern gefunden werden, die dieses Problem lösen möchten :-)
I do not have enough energy in my life to clean up two poorly written crypto code bases.Immerhin signieren sie jetzt überhaupt, und zwar mit … signify. Nie gehört? Ich auch nicht. Das scheint was ad-hoc schnell selbst gehacktes zu sein. Hier ist das Argument dafür:$ wc -l *.cNun werdet ihr vielleicht sagen: hey, klingt gut, will ich haben. Wo ist der tarball?
29 crypto_api.c
143 mod_ed25519.c
327 mod_ge25519.c
806 signify.c
1305 totalSignify is 1305 *lines* of C code. and it's included in our development
platform. It is not that difficult to install, and
if you can't install it, you could always run OpenBSD in a vm to verify a
signature, it comes with openbsd.
Die Antwort: Es gibt keinen. Ich habe mir mal im Schweiße meines Angesichts die nötigen Teile aus dem OpenBSD-CVS herausgepopelt und in einen unter Linux bauenden Tarball getan. Mit dem ganzen Glue-Code sieht die Statistik schon mal gleich ganz anders aus, da sind wir dann plötzlich bei knapp 8000 Codezeilen (plus libc, natürlich).
Das baut bei mir, und ich kann damit die LibreSSL-Distribution verifizieren. Immerhin. Das ist aber natürlich immer noch voll für den Fuß, weil der public key von deren Signatur auf dem selben FTP-Server liegt wie die Daten. Wenn jemand den Tarball manipulieren kann, kann er also auch einen anderen pubkey daneben legen und keiner merkt was. Bei GnuPG gibt es ja wenigstens das Web of Trust.
Diesmal im Futex-Syscall. Das sind die Art Bugs, mit denen man aus einer Sandbox ausbricht. Z.B. der von Chrome.
Der größte Erkenntnisgewinn ist für mich dieser Kommentar.
Guys, just ignore this. These are bots who do this automatically for projects, which have been circling around on Github lately. There are also ones about feminism etc. The Linux kernel also had a PR like this a few months ago with a massive amount of responses on it.
Founding backers of the Initiative include Amazon Web Services, Cisco, Dell, Facebook, Fujitsu, Google, IBM, Intel, Microsoft, NetApp, Rackspace, VMware and The Linux Foundation.Yeah!Update: Ich höre gerade aus gewöhnlich gut informierten Quellen, dass sich OpenBSD bei der Linux Foundation um diese Kohle bewirbt :-)
Nun habe ich mir für meine SSL-Library gedacht, dass ich nur auf Systemen laufen werde, bei denen es /dev/urandom oder Äquivalent gibt, und nicht versuchen werde, da selber irgendwelche Entropie-Fummeleien zu machen. Das kann eigentlich nur nach hinten losgehen.
Aaaaaaber. Ein Kumpel von mir macht SSL auf einem Rechner, der nicht am Netz hängt, und eine Smartcard mit Hardware-RNG hat. Es gibt Smartcards mit Hardware-Zufall und einem kleinen ARM drauf. Habt ihr mal darüber nachgedacht, woher der Kernel den Zufall in /dev/urandom nimmt? Dafür nimmt man so Dinge wie das Timing zwischen Netzwerkpaketen und die Rotationslatenz von Festplatten. Timing von Tastatur- und Mauseingaben. Gibt es bei Smartcards alles nicht. Auf Smartphones gibt es Eingabegeräte aber keine Festplatten und bei den Netzwerkpaketen musst du davon ausgehen, dass sie ein Angreifer schickt, um deinen Zufall vorhersagen zu können.
Das ist ein echtes Problem in der Praxis. Gerade wenn ein Gerät frisch gebootet wurde, und die ganzen Krypto-Dienste hochfahren und Zufall für temporäre Schlüssel haben wollen. In solchen Fällen ist es wichtig, dass man den Zufallszahlengenerator irgendwie mit echtem Zufall seeden kann. Auch auf Servern mit SSD ist das ein Problem, wenn da keine Eingaben per Maus und Tastatur kommen.
Unter Linux kann man dafür einfach Daten nach /dev/random schreiben. Unter Windows gibt es zwar auch einen RNG in CryptoAPI, aber es gibt keinen Weg, da Zufall reinzuseeden. Die Sache mit dem Bildschirm-Auslesen ist natürlich echt ein Kracher. Aber da einfach die Möglichkeit wegzunehmen, externen Zufall reinzupipen, das macht LibreSSL für viele Anwendungen kaputt.
Übrigens, sowas wie ~/.rng kommt als Idee daher, dass man beim Runterfahren Entropie aus dem Pool ins Filesystem schreibt, damit man nach dem nächsten Hochfahren gute Entropie hat, wenn man ihn braucht. Das ist nicht per se eine doofe Idee.
Was ich sagen will: LibreSSL schießt sich hier gerade ziemlich massiv in den Fuß. Das sollte man dann auch erst mal ein paar Jahre aufhängen und reifen lassen, bevor man das einsetzen kann. Schade eigentlich.
Update: Mich weist gerade jemand darauf hin, dass das unter Windows doch auch geht.
Nein, muss es nicht. Im Gegenteil. Das wäre das Ende von Open Source.
Außerdem lässt es der Artikel so klingen, als habe sich jetzt herausgestellt, dass Open Source Software weniger gut als kommerzielle sei. Das ist ganz großer Unsinn (auch wenn es natürlich auf beiden Seiten Ausreißer gibt, die deutlich besser als der Durchschnitt der anderen Seite sind).
Open Source als Bewegung ist das Konzept, dass man Leute Code schreiben lässt, deren Herzensblut dranhängt. Die es eben nicht kurz herunterpfuschen, weil sie dafür bezahlt werden. Open Source ist die Beobachtung, dass manche Menschen es lieben, Code zu schreiben. Und wenn man sie nicht mit Deadlines und Deliverables und dem monatlichen Paycheck unter Druck setzt, dann nehmen sie sich die Zeit und machen ihr Projekt ordentlich. Viel ordentlicher jedenfalls als die durchschnittliche kommerzielle Software.
Inzwischen wird kommerzielle Software wie Open Source entwickelt. Weil das Modell funktioniert. Kaum eine Firma entwickelt heute noch Software ohne Unit Tests, ohne Source Code-Versionskontrolle, überall gibt es ein Wiki für die Dokumentation und alle wollen gerne agil sein.
Der Erfolg von Open Source war so durchschlagend, dass es das Gegenmodell gar nicht mehr in freier Wildbahn gibt!
Wenn es etwas gibt, das sich bei Open Source zu ändern lohnt, dann ist es der mangelnde Respekt. Nur weil du gerne Programmieren lernen willst, heißt das nicht, dass du am Linux-Kernel herumfummeln solltest. Deine eigene SSL-Library schreiben? Kein Ding. Tu es! Da kann es nur Gewinner geben, selbst wenn es niemals fertig wird und niemand deinen Code benutzt. Du hast dabei was gelernt und als Programmierer an Größe gewonnen. Ein wenig bekanntes Detail aus der OpenSSL-Genesis ist, dass das mal SSLeay hieß — eay sind die Initialen des initialen Autoren, Eric Young —, und der hat das Projekt gestartet, weil er lernen wollte, wie die Division von 1024-Bit-Zahlen funktioniert.
Der Kern des Problems ist aus meiner Sicht, dass wir als Gesellschaft uns darauf geeinigt haben, dass Software halt ein schwieriges Problem ist, und daher Fehler halt passieren und niemand für seine Fehler geradestehen muss. Man kann sich heute bei so gut wie allen Problemen mit "das war ein Softwarefehler" herausreden. Für mich als Programmierer ist das natürlich auf der einen Seite toll, weil ich mich so Dinge trauen kann, die ich sonst nicht in Angriff nehmen würde. Aber es hat in der Szene so ein wirklich widerliches Gefühl erzeugt, als hätten wir Programmierer es verdient, als sei das unser Recht, niemals für unseren Scheiß den Kopf hinhalten zu müssen. Ich will das mal anhand dieser Tweets veranschaulich. So tief sitzt da die Panik! So ein Affront für das Weltbild ist es, dass möglicherweise jemand kommen könnte, und der sieht, dass ich gepfuscht habe! Sowas finde ich zutiefst unwürdig. Als ob der Auditor Schuld hat, wenn dein Code Scheiße ist! Wenn bei einer Frittenbude Küchenschaben gefunden werden, ist dann das Gesundheitsamt der Bösewicht? Wenn GM kaputte Autos baut, und da sterben Leute, glaubt ihr auch, die Zuständigen machen sich in erster Linie Sorgen wegen der Hater aus dem Internet? Anders gefragt: Würde irgendjemand von euch von einer Firma kaufen, die nur Qualitätskontrolle macht, weil sie Angst vor Internet-Hatern hat, wenn herauskommt, wir ranzig ihr Produkt ist?!
Dass überhaupt das Wort "Hater" gefallen ist, sagt aus meiner Sicht schon alles. Wenn du etwas baust, dann sollte das der güldene Sonnenschein sein, nach frisch gebackenem Brot durften und die filigrane Eleganz eines mathematischen Beweises haben. Und zwar nicht weil es da draußen "Hater" gibt, sondern weil das dein verdammer Anspruch an dich selbst ist! Wenn jemand kommt und dich auf Fehler in deinem Code hinweist, dann solltest du auf die Knie fallen und dem Fremden überschwänglich danken, denn er hilft dir, deinen Code näher an die Zielvorstellung der Perfektion zu bringen!
Ich glaube nicht, dass bei Software so viel mehr gepfuscht wird als anderswo. Aber physische Dinge sind vergänglich. Fehler bei physischen Dingen gehen von alleine weg, mit den Dingen selbst. Software lebt theoretisch für immer. Softwarefehler akkumulieren immer nur. Aus meiner Sicht müssen wir Software wie radioaktiven Müll behandeln — vorsichtig und mit Bedacht.
Nachdem ich all das gesagt habe, möchte ich noch sagen: Schreibt mehr Software! Aber macht es ordentlich!
Update: Jetzt bin ich ganz von meinem eigentlichen Gedankengang abgekommen. Open Source funktioniert, weil es eben nicht geldgetrieben ist. Der Programmierer zieht seinen Anreiz, die Software zu schaffen, aus der kreativen Freude des Programmierens, und aus dem Zen-ähnlichen Zustand, wenn ein komplexer Algorithmus, den man hingeschrieben hat, dann tatsächlich funktioniert. Guter Code ist seiner selbst Belohnung. Wenn man dort Geld als Anreiz einbringt, dann wird das dieses Modell kaputtmachen. Programmierer werden dann anfangen, die Arbeit pro eingenommenem Euro zu minimieren. Genau wie das überall eintritt, wo man Geld für Arbeit zahlt. Am Ende wird man feststellen, dass die Stundenlöhne anderswo niedriger sind als bei uns, und dann wird niemand mehr in Deutschland Open Source programmieren wollen. Nur weil man das mentale Modell so umgebaut hat, dass wir das "für Geld" tun, nicht um etwas zu lernen, oder den anderen Gründen. Macht das bloß nicht!
Geld für Dinge ausgeben, bei denen niemand kreative Genugtuung erfährt, das kann man diskutieren. Ich glaube, das wird man auch machen müssen, damit auch bei den SSL-Libraries wieder Open Source qualitativ führend ist. Aber fangt nicht an, das Belohnungsmodell von Open Source Programmieren auf "da gibt es Geld für" umzustellen. Das wäre der Untergang.
Update: Ich will mal eine Kommentarmail hier zitieren:
In der Psychologie unterscheidet man zwischen extrinsischer und intrinsischer Motivation. Intrinsische Motivation bedeutet, dass man etwas tut, weil es einem Spass macht, weil man es für richtig hält etc. Extrinsische Motivation bedeutet, dass man etwas tut, weil man eine Belohnung dafür erhält. Sozialpsychologische Experimente haben gezeigt, dass man intrinsische Motivation unwiederbringlich zerstören kann, indem man einen extrinsischen Anreiz schafft, etwas zu tun.
Update: Noch eine Einsendung:
Die moderne Motivationsforschung sagt an dieser Stelle „Nein“, weil die Programmierer bereits in dem Moment wo sie Geld bekommen den Spaß verlieren würden, aus Spiel wird dann Arbeit. Das Ganze geht auf die Selbstbestimmungstheorie der Motivation von Deci & Ryan, 1985a zurück (s. Wikipedia). Lese grade Drive von Daniel Pink (ISBN 978-1847677686), was die gedankliche Grundlage für die agile Softwareentwicklung z.B. Scrum beschreibt. Bei modernen Softwareschmieden gehört diese Kenntnis mittlerweile auch zum Einstellungskriterium.
Nun benutzt Apple aber nicht gcc sondern clang. Und da gibt es die Warnung zwar, aber sie muss manuell angeschaltet werden und ist nicht Teil von -W -Wall -Wextra. Das ist meiner Ansicht nach ein grober Fehler, den clang korrigieren sollte.
Aber wie ist denn das bei gcc? Wäre Apple sicher gewesen, wenn sie gcc eingesetzt hätten?
Wie sich rausstellt: Nein. gcc hat die Option vor ein paar Jahren deaktiviert. Ja, ganz weg. Die Kommandozeilen-Option gibt es noch, aber sie tut nichts mehr. Was für ein epischer Knieschuss, liebe gcc-Maintainer! Da habt ihr ja mal wieder mit Anlauf einen Kopfsprung ins Klo gemacht!
Man kann also im Moment Softwareentwicklern unter Linux nur empfehlen, clang mindestens als Zweitcompiler zu verwenden, um diese Warnung überhaupt kriegen zu können. Oder man steigt gleich ganz auf clang um, weil man keinen Bock mehr auf die Andrew Pinskis bei gcc hat.
Ich bleibe erstmal noch bei gcc, weil da immer noch geringfügig besserer Code rausfällt in meinen Tests.
Und PrivateCore macht … RAM-Verschlüsselung. Nein, wirklich!
vCage validates the integrity of the hardware environmentGemeint ist hier Trusted Computing, TPM-Measuring.provides a hardened hypervisor based on KVMHardened und "based on KVM" in einem Satz? Oioioio!and secures server random access memory (RAM) with AES encryption.Wie soll das funktionieren? Na ganz einfach!This is done by loading a secure hypervisor into CPU cache and acting as a gateway to encrypt memory paging in and out between the CPU cache and RAM.Soso, paging! Zwischen CPU-Cache und RAM, ja? Paging?Ob deren Produktbeschreibung aus irgendeinem Nonsens-Paper-Generator rausgefallen ist?
Das wäre ja alles höchst unterhaltsam, wenn nicht die Marketing-Ansage wäre: Wenn ihr das macht, müsst ihr dem Cloud-Provider nicht mehr vertrauen! Eure Anwendung kann dann vertrauenswürdig laufen, auch wenn die Hardware, auf der sie läuft, nicht vertrauenswürdig ist! Überhaupt hat Intel eine Technologie namens TXT im Angebot, von der sie versprechen, dass man damit TPM-Attestation bis hinein in die Anwendung haben kann, die in der VM läuft.
Wenn ihr übrigens mal Rüdiger Weis beim Meckern über TPM zugehört habt, werdet ihr die Einsicht mitgenommen haben, dass TPM nicht dazu da ist, den Anwender zu schützen, sondern die Software von Microsoft vor dem Anwender. Rüdi malt dann immer das Bild an die Wand, dass das Booten von Linux verhindert werden soll. TPM selbst kann das nicht, der führt immer auch unvalidierten Code aus. Aber wenn der Code fragt, ob er validiert wurde, dann kann ihm TPM sagen, ob das Windows in einer vertrauenswürdigen Umgebung hochgekommen ist oder nicht. Und da kommt dann halt bei manipulierten System (z.B. zum Linux-Booten, wenn man keinen TPM-fähigen Bootloader nimmt) "falsch" zurück als Antwort. Dieses Detail war das Feigenblatt, hinter dem sich die Trusted-Computing-Leute vor Rüdi versteckt haben. Intel hat allerdings noch mehr in ihren Prozessoren drin, das über das TPM-Zeugs hinausgeht. Da kann im Prozessor auch hinterlegt werden, dass nur als vertrauenswürdig signierter Code zur Ausführung kommen soll. Das nennt sich dann Launch Control Policy. Wenn Rüdi das hört, kriegt er einen Schlaganfall.
Update: Krass, Privatecore macht sogar explizit Werbung, dass ihr Produkt Cloudserver vor der NSA schützt. Was für eine Frechheit!
Ich prüfe da nicht viel, im Wesentlichen will ich, dass das Opcode-Byte sagt, dass es ein Handshake ist, und dass die TLS-Version gültig aussieht, und dass die Länge des Handshake-Paketes nicht größer als 256 ist. Warum 256? Weil das nach damaligen Verhältnissen exorbitant viel war und weil 256 in Binärdarstellung ein 1-Byte in der höherrangigen Hälfte des Längenfeldes war, was sich dann leicht testen ließ.
Was jetzt passiert ist, ist dass Chrome so viel Bloat mitschickt, dass bei denen 0x200 als Länge im Header steht, also 512. Wir erinnern uns: Chrome, das waren die Leute, die wegen des angeblichen HTTP-Header-Bloats ein eigenes Konkurrenzprotokoll namens SPDY erfunden haben, das so super toll optimiert ist, dass für die zwei e kein Platz mehr im Namen war. DIE Leute haben jetzt ihr SSL-Handshake soweit aufgebläht, dass es in meinen Sanity-Check rannte.
SPDY basiert übrigens auch auf SSL.
Einmal mit Profis arbeiten!
Update: Vier der Extensions sind so neu (oder Google-proprietär?), dass Wireshark sie noch nicht kennt.
Update: Es gibt eine Erklärung, wieso der SSL-Header so groß ist. Das ist kein Bloat, sondern die machen das absichtlich, um um eine ranzige F5-Firmware herumzuarbeiten. m(
The /etc/cleanup script runs weekly to remove temporary files that are no longer needed by CMS. The syntax of certain Linux commands differs from Solaris and a path argument is not always required. Therefore, if there are no files under /tmp at the exact moment when the /etc cleanup script is run on Linux the script may start to delete all files under /.Einmal mit Profis arbeiten!Erinnert ein bisschen an diesen legendären Bug :-)
Die schlechte: RSA BSAFE benutzt das als Default-RNG. Und nicht nur die, NIST hat eine Liste. Cisco, Apple, Juniper, McAfee, Blackberry, … bei den meisten wird das allerdings nicht Default sein.
Die gute Nachricht: BSAFE wird von keiner freien Software eingesetzt. Wenn ihr also Firefox unter Linux einsetzt, seid ihr sicher.
Ich bin mir gerade nicht sicher, wie das unter Windows ist. Da gibt es ein TLS vom System namens "SChannel". Das wird meines Wissens u.a. von IE und Chrome verwendet. Benutzt der BSAFE? Vermutlich. Es gab mal eine Zeit, da konnte man RSA und co gar nicht ohne BSAFE legal einsetzen in den USA, aus Patentgründen. Das müsste mal jemand herausfinden, wie das ist, und ob Windows den NSA-RNG einsetzt.
OpenSSL ist auch auf der Liste, aber die haben schon angesagt, dass sie das nur implementiert haben, weil ihnen jemand dafür Geld gegeben hat, und das ist nur an, wenn man den FIPS-Modus aktiviert, von dem sie im Übrigen dringend abraten und was nicht der Default ist.
Dieses Problem betrifft die ganzen MIPS-Linux-basierten Plastikrouter da draußen. SSL oder VPN oder so besser lieber nicht damit machen.
Update: Und die WLAN-APs natürlich, das fasste ich mal unter Plastikrouter zusammen.
Money Quote:
P.S. If you don't know what uucp is, you can read more about it on fidonet or at my gopher site.Muhahahahaha
Bei so viel Nostalgie lässt sich auch Microsoft nicht lange lumpen und erinnert mit einer IPv6-Version des Ping of Death an diese Zeit. Wem wird da nicht ganz warm ums Herz!
Hier gehen gerade verzweifelte Mails ein, ob sich der Einsatz von PGP denn überhaupt lohne, wenn man davon ausgehen müsse, dass das Windows darunter Hintertüren hat. DAS IST GENAU DER PUNKT. Es gibt Alternativen. Das hat viel Schweiß und Mühe gekostet, die soweit zu bringen, dass man mit ihnen arbeiten kann. Muss man sich dabei etwas zurücknehmen gegenüber polierten kommerziellen Systemen? Kommt drauf an. Ich als Softwareentwickler empfinde eher Arbeiten unter Windows als zurücknehmen. Grafikdesigner werden das möglicherweise anders erleben.
Aber dass wir überhaupt eine Infrastruktur haben, in der die Dienste sich gezwungen sehen, bei Google und Microsoft die entschlüsselten Daten abzugreifen, weil wir internetweit Verschlüsselung ausgerollt haben, das ist ein großer Sieg. Klar ist das alles immer noch nicht befriedigend. Schöner wäre es, wenn das Internet eine Blümchenwiese wäre. Aber wir haben es geschafft, dass man, wenn man will, gänzlich ohne Software-Hintertüren arbeiten kann. Wie weit man dabei gehen will, hängt natürlich von jedem einzelnen ab. Aber zur Not kann man heutzutage auch sein BIOS als Open Source haben.
Natürlich können auch in Linux und OpenBIOS theoretisch Hintertüren sein. Das liegt an jedem von euch, sich da genug einzulesen, um seinen Teil mitzuhelfen, die Wahrscheinlichkeit dafür zu senken. Muss man dann natürlich auch tun. Die Software kann man zwar kostenlos runterladen, aber man zahlt dann eben auf andere Art. Indem man sich einbringt.
Kurz gesagt: Dass wir überhaupt ein Gegenmodell zu "alle setzen walled garden backdoored NSA-technologie ein" haben, das ist ein immenser Sieg, der in den 80er Jahren, als diese ganzen Geschichten hochblubberten, wie ein feuchter Fiebertraum wirkte. Wir haben immens viel geschafft. Es liegt an uns, das konsequent einzusetzen und konsequent weiterzuentwickeln. Und es ist eure verdammte Pflicht, nachfolgenden Generationen dieses Stückchen Hoffnung zu erhalten. Helft mit!
Update: Um das mal ganz klar zu sagen: Linux einsetzen und Verschlüsseln ist keine Lösung für alles. Per Trafficanalyse wissen die immer noch, wer wann mit wem geredet hat. Nur nicht mehr notwendigerweise worüber. Das sehen die nur, wenn einer der Gesprächsteilnehmer Hintertüren im System hatte oder das dann auch auf Facebook oder Twitter rausposaunt oder bloggt. Open Source ist ein Werkzeug, nicht die Lösung. Ihr müsst auch euer Verhalten entsprechend ändern.
Java hat uns den RAM billig gemacht. Computerspiele haben uns Grafikkarten schnell und billig gemacht. Pornographie hat uns Internet schnell und billig gemacht. Und Antiviren machen uns die Rechner schnell und billig. Ich saß da an einem Arbeitsplatzrechner, der vom Kunden zur Verfügung gestellt wurde. Da lief natürlich auch ein Antivirus drauf. Und ich habe da, weil ich ja nichts neues starte oder runterlade, die ganzen Komponenten deaktiviert, die normalerweise so nebenbei mitlaufen, und alle Dateien scannen, die von irgendeinem Prozess geöffnet werden. Stellt sich raus: DAS war es, wieso Office bei mir so flutschte. Bei meinem Nachbarn schnarchte das wie gewohnt vor sich hin. Der hatte das nicht ausgeschaltet.
In diesem Sinne: Antiviren sind natürlich immer noch Schlangenöl und machen die Menschen unsicherer statt sicherer, aber wir sollten ihnen trotzdem dankbar sein, weil sie dafür gesorgt haben, dass andere Software schneller wird, weil es sonst überhaupt nicht ertragbar wäre.
Ich würde sogar so weit gehen, für Linux Antiviren zu fordern. Das ist ein echter Wettbewerbsnachteil, den Linux-Softwareentwicklung da hat. Die Entwickler sehen keinen Optimierungsbedarf, weil das bei ihnen flutscht. Wenn man nicht gerade Old School seine Dokumente mit TeX oder troff schreibt, ist der Performance-Zustand der Office-Suiten unter Unix geradezu beschämend. Und die ganzen Sprallos von Freedesktop und co kommen ja auch jedes Jahr mit weiteren Indirektionsschichten mit XML und endloser Redundanz, weil sie es können! Wenn da noch ein paar Antiviren das System auf C64-Niveau verlangsamen würden, dann würden diese Leute effizienteren Code schreiben.
Update: Das rechts unten sieht wie ein mIRC aus, oder?
They work primarily with the Ft. Meade customer … combination of offensive and defensive Cyber software engineering … Reverse Engineering, Penetration Testing, Malware Analysis, and the application of Big Data / Cloud technologies to Cyber problems … seeking Kernel and Device Driver Developers (Windows or Linux/Unix)Falls jemand nicht weiß, wer der Ft. Meade customer sein könnte: Wikipedia hilft. Da sitzen das United States Cyber Command und die NSA.
Ich auditiere ja nun Code als Lebensunterhalt. Ihr könnt mir glauben: in so gut wie jedem Projekt findet man geklauten BSD-Code. Und ich bin mir so gut wie sicher, dass die den jeweiligen Autoren vorher nicht mal Bescheid gesagt haben. So ala "hey, der Code sah nützlich aus, den verwenden wir mal". Man kriegt also nicht mal kostenloses Feedback, dass jemand den Scheiß benutzt, als Autor. Und dann sieht man Projekte wie die FreeBSD-Foundation öffentlich um Geld betteln, weil Firmen ihren Kram einfach abgreifen. Es ist echt ein Trauerspiel.
Ich werde ja mit zunehmendem Alter eher noch radikalisiert in der Beziehung. Ich erwärme mich gerade für die AGPL. Die schließt nicht nur Weitergebe des Codes in den viralen Trigger ein, sondern auch wenn jemand z.B. einen Webservice betreibt. Und auch die Opposition gegen die GPLv3 entbehrt meiner Ansicht nach jeder Grundlage. Wir müssen endlich was wirksames gegen diese Softwarepatente tun. Wenn wir denen alle verbieten würden, dass sie Samba und Linux einsetzen, dann wäre das aus meiner Sicht ein guter Schritt. Stellt euch mal vor, Linux wäre GPLv3, dann müssten in den ganzen Patenttrollfirmen Android-Telefone verboten werden.
Und es gibt noch einen Bug des Tages. Vergeben wir halt heute mal zwei. 23 Millionen IP-Adressen im Internet fahren UPNP-Software, die mit einem UDP-Paket übernommen werden kann. Diese ranzigen Plaste-Router immer.
Update: Stimmt wohl nicht, nicht die JVM benutzt /dev/random sondern wenn dann irgendwelche Apps.
Um zu vermeiden, dass jeder Anwender einen Film kopieren kann, ist dafür der Linux-Standard gewählt worden.m( (Danke, Dennis)Wird die Festplatte an einen PC oder MAC angeschlossen, erscheint sie gar nicht erst, weil dafür Linux-Spezialtreiber erforderlich wären.
Früher gab es noch Filmrollen, aber heute ist das alles digital. Und offenbar ist hier die Festplatte mit dem Film drauf kaputtgegangen. Also musste das Kino alle Vorstellungen absagen. Festplatten können halt auch mal kaputtgehen. Und dank dem ganzen DRM-Scheiß kann das Kino keinen Backup haben und somit dann auch keinen Film zeigen.
Update: Die hätten doch ein Backup machen können. Das kommt als verschlüsselte Dateien auf einem ext3-Linux-Filesystem rein, JPEG2000 fürs Bild und PCM für den Ton, alles per AES-CBC verschlüsselt.
Das ist schon deshalb sportlich, weil DNSSEC bei den Kryptoprimitiven immer etwas hinterherhinkt. Die haben 2048 Bit RSA-Schlüssel erst Jahre später spezifiziert, nachdem die paranoideren Leute das schon für ihr SSH und PGP und SSL ausgerollt hatten.
Bei DNSSEC war daher Designentscheidung, dass die privaten Schlüssel gar nicht erst im Server stecken sollen. Man signiert seine Zonen off-line und lädt dann die signierten Zonen zum Server hoch. Selbst wenn jemand den Server hackt, kann er den Schlüssel nicht klauen, weil der nicht auf dem Server ist.
Die Idee ist natürlich, dass der Schlüssel gar nicht am Internet hängt. Jetzt stellt sich aber raus: das mit dem off-line, das ist so unhandlich, wir machen das lieber online!1!! Damit das automatisierbar ist. Bei einer TLD wie .de oder .ch kommen ja auch im Sekundentakt Änderungen rein. Da muss dann jeweils neu signiert werden. Da erhöhen sich dann natürlich die Anforderungen an das Hosting entsprechend. Immerhin könnte die Sicherheit der ganzen Welt auf diesem DNSSEC ankern.
Wie wird das denn dann am Ende gehostet? Hier gibt es Webcams. Das ist ein kleiner Server in einem Safe, in einem Safe. Mit klein meine ich den Stromverbrauch, denn Abwärmeabtransport ist ein bisschen schwierig, könnt ihr euch ja vorstellen. Alleine von der "Alien Power Source"-Optik her ein echter Sieger, dieses Hosting. Oh und der Schlüssel ist nicht auf dem PC sondern auf einem separaten sicheren Hardwaremodul. Wenn jemand die Kiste hackt, kann er zwar Änderungen signieren, aber er kann nicht den Schlüssel extrahieren. Nachdem der Hacker gefunden und rausgeschmissen wurde, kann er nichts mehr signieren. Er kann natürlich immer noch anderen Leuten seine vorher signierten Falschdaten unterschieben. Dazu sagt die DNSSEC-Spec: Aber, äh, *räusper* *aufdieuhrguck* oh schaut mal, schon sooo spät *wegrenn*
Oh, übrigens. Wie bindet man so ein Hardwaremodul an? Per IP über Ethernet! Genau wie den Rechner selbst. Auf dem läuft übrigens Linux, der ist also unhackbar!1!!
Noch ein paar Zahlen: der Rechner verbraucht so 30W, und die LEDs draußen auch noch mal so viel :-)
Update: Solange die Site down ist, könnt ihr euch ja die Folien hier angucken, die haben noch ein paar Details zu dem Setup.
Naja, gibt ja noch AMD, deren Atom-Konkurrenz ist eh besser. Und was tut AMD? AMDs nächste Atom-Killer-Generation wird auch nur Windows 8 unterstützen. Was zur Hölle?!? Immerhin klingt es bei AMD nicht so, als wollten sie absichtlich Hürden gegen Linux aufbauen. Aber trotzdem.
Lasst EFI in Frieden. PCs sind keine Geldautomaten, die sollen nicht sicher sein. Sicher heißt Zwangsjacke für den Anwender und gerade in diesem Fall reden wir ja von Apple, die zwar in Sachen Sicherheit Jahre hinterherhinken, aber dann Handschellen für den Anwender als Sicherheitsmaßnahme verkaufen und man sein Telefon nur in Betrieb nehmen kann, wenn man Itunes installiert. Apps? Nur aus dem Apple Store. Wegen der Sicherheit!1!!
NICHTS von dieser ganzen Scheiße kommt dem Benutzer zu Gute. Das ist alles nur Gängelei von dem nur einer profitiert: Apple.
Es ist schlimm genug, dass wir seit Jahren nicht in der Lage sind, sichere oder vertrauenswürdige Software zu produzieren. Aber damit jetzt Guantanamo-Technologien auf allen Endgeräten zu etablieren, dass wir DAS zulassen, das ist eine Schande sondergleichen. Und am Ende wird es wieder keiner gemerkt haben. Ach was hätten wir den tun sollen, keine Apple-Geräte kaufen? Das wäre in der Tat mal ein Anfang! Solange Hersteller wie Apple für sowas noch mit Rekordprofiten belohnt werden, wird das nie aufhören.
Dieser UEFI-Codesigning-Bullshit ist übrigens genau die Technologie, mit der auch Microsoft Windows 8 zunageln will. Aus Sicherheitsgründen, wissenschon. Microsoft kriegt dafür zu Recht auf die Fresse. Apple wird für den gleichen Mist noch gefeiert.
Oh und dass der Typ in dieser Meldung ausgerechnet Thunderbolt nimmt ist nochmal ein zusätzlicher Gähner, weil Thunderbolt auch ganz ohne Backdoor den DMA-Zugriff von außen auf dem Hauptspeicher erlaubt. Den Teil benutzt er aber gar nicht. Weil, äh, … keine Ahnung warum nicht, denn das ist inhaltlich genau so "überraschend" wie dass man EFI-Backdoors machen kann. Wie wäre es als nächstes mit der krassen Einsicht, dass wenn jemand deinen Laptop klaut, er deine Festplatte auslesen kann!1!! Oder dass man per Internet Daten übertragen kann!
Ich halte das für eine der zentralen Fragen unserer Zeit. Wenn ich ein Gerät kaufe, dann muss ich das Recht haben, damit zu tun was ich will, inklusive Reverse Engineering der Software darauf, inklusive "Schutzmaßnahmen" umgehen, inklusive weiterverkaufen, inklusive eigene Software drauf installieren. Das muss m.E. die zentrale Forderung jeder zukunftsorientierten Partei sein, dass es bei Politik um Menschen und nicht um Firmen geht, und die Rechte der Menschen immer schwerer wiegen als die Wünsche von Firmen. Keine Firma darf ihren Kunden vorschreiben, dass ihr Telefon nur in Mobilnetz A geht, dass auf ihrer Spielekonsole nur Spiele und kein Linux laufen darf, dass in ihren Drucker nur Patronen der eigenen Abzockmarke funktionieren. Allgemein: dass Geräte nur für den vom Hersteller/Verkäufer vorgesehenen Zweck verwendet werden dürfen.
Diese ganze Gängelscheiße gehört illegal gemacht. Ja, da werden Geschäftsmodelle implodieren, aber die gehören auch entsorgt, diese Geschäftsmodelle. Firmen müssen sich wieder darauf konzentrieren, Produkte zu bauen, die ihre Kunden haben wollen. Nicht ihre Kunden mit Tricks zum Kauf ihrer Produkte zu gängeln. Die Legacyparteien sind ja offensichtlich alle nicht in der Lage zu dieser trivialen Einsicht. Wie sieht es mit den Piraten aus? Die scheinen mir in der Sicht auch unter Legacy-Partei zu laufen, oder habe ich da was übersehen?
A Remote Direct Memory Access Protocol SpecificationDas Ende ist nahe, liebe Freunde. Da muss man nicht religiös sein, um da apokalyptische Visionen zu kriegen!
Money Quote:
The Remote Direct Memory Access Protocol (RDMAP) enables removal ofWir sind alle so gut wie tot. Ich bin ja immer froh, wenn die Leute sich neue Dinge ausdenken, die mir meinen Job in der IT-Security auf Jahrzehnte hinaus sichern, aber … remote direct memory access?! HALLO?!?
data copy operations and enables reduction in latencies by allowing a
local application to read or write data on a remote computer's memory
with minimal demands on memory bus bandwidth and CPU processing
overhead, while preserving memory protection semantics.
Wer sich jetzt denkt, ach naja, who cares, das wird schon niemand implementieren… das RFC kommt von IBM und HP. Und Microsoft ist bei sowas natürlich auch nicht weiter: SMBDirect - SMB2 über RDMA.
Gut, das ist jetzt nicht völlig offensichtlich für die Tonne designed, so schlimm wie Apple mit Firewire hat vorher niemand verkackt und wird auch nachher nie wieder jemand verkacken. Aber die bloße Idee, dass man ein Remote Direct Memory Access entwickelt, das ist ja schonmal ein Horrorfilm vom Feinsten. What Could Possibly Go Wrong?
Haha, ein Kumpel meint gerade, sie hätten das Microsoft Direct Memory Access nennen sollen, dann wäre wenigstens kein Zweifel übrig, wie sie darauf gekommen sind, wenn man sich die Abkürzung anguckt.
Update: Stellt sich raus: Linux supported auch RDMA, sogar NFS über RDMA. Das ist für Hochparallelrechner gedacht, erklärt mir gerade ein Physiker, der Plasmasimulationen der Sonnenatmosphäre macht, nicht für "über das Internet". Das habe ich mir auch gedacht, als ich das sah. Ein besseres Gefühl gibt mir das trotzdem nicht.
Daher sage ich mal voraus: ein paar Geeks werden daran arbeiten, das so zu machen. Im Großen und Ganzen ist das bloß ein weiteres Argument für HTML5 und gegen Flash. Flash ist ja eh am Sterben. Good Riddance.
Schritt 2: Apple stellt den CUPS-Entwickler ein.
Schritt 3: CUPS schmeißt Komponenten raus, die man unter Linux aber nicht unter OS X braucht.
Ich bin mir sicher, es gibt dafür eine völlig harmlose technische Erklärung. Sie fällt mir nur gerade nicht ein.
Die einzige gute Nachricht an der Stelle ist, dass das anscheinend nur den IA64-Branch betrifft, und IA64 ist ja eh tot.
Seit dem gibt es in Linux einige mehr oder weniger geniale Änderungen, die wir nie unterstützt haben, weil Multithreading nie so richtig wichtig war für die dietlibc. Mir schonmal eh nicht so, aber auch die Zielplattformen haben normalerweise nie mehr als einen Core gehabt. Das hat sich inzwischen geändert.
Die erste wichtige Neuerung ist Thread Local Storage. Das funktioniert so, dass man in den Threads auf x86 ein Segment-Register so belegt, dass man über das Segment ab Offset 0 auf den Thread-Parameter-Block zugreifen kann. Es ist auch vorgesehen, dass man selbst in seinem Code Variablen thread local deklarieren kann, aber den Sinn davon habe ich nie gesehen, die kann man ja auch gleich auf den Stack tun oder vom Heap allozieren, wenn sie größer sind. Der Punkt ist jedenfalls, dass alle möglichen Thread-Funktionen wissen müssen, welcher Thread sie gerade aufruft, z.B. können Mutexe rekursives Locking erlauben und müssen daher wissen, ob dieser Lockversuch vom selben Thread kam wie der ursprüngliche. Kurz gesagt: bei Threading-Code war es immer ein Flaschenhals, wenn der Code gucken musste, welcher Thread das eigentlich gerade ist. Die Alternativen sind alle doof; man könnte einen Syscall aufrufen, um die PID oder TID zu kriegen, oder man könnte den Stack Pointer nehmen und in einer globalen Datenstruktur nachgucken (allerdings muss die dafür gelockt werden und wie gesagt müssen Mutexe auch die Thread-ID wissen). Mit Thread Local Storage ist das nur noch ein einziger Speicherzugriff über das Spezial-Segment. Das war also schonmal gut, aber ich hab immer das Gefühl gehabt, ich müsste jetzt auch Futex-Support implementieren, um überhaupt in einer Liga wie NPTL spielen zu können. Das habe ich heute mal gemacht, und die Ergebnisse sind ernüchternd.
Der alte Code in dietlibc benutzt im Wesentlichen Spinlocks, d.h. eine Schleife, die immer wieder versucht, den Lock zu kriegen, bis es halt klappt. Damit dabei nicht die CPU so doll belastet wird, sagt er zwischen den Iterationen dem OS, dass mal ein anderer Thread laufen soll jetzt. Sieht sehr krude und amateurhaft aus, fand ich immer.
Futex, zum Vergleich, ist ein geradezu geniales Verfahren. Man nimmt sich dafür den Lock, also eine Speicherstelle, und zählt den mit einer atomaren Operation von 0 auf 1 hoch. Wenn nach dem Hochzählen 1 drin steht, dann weiß man, dass man den Lock hat und sonst niemand. Wenn dann da 2 oder so drinsteht, dann hat man den Lock nicht, und benutzt den futex-Syscall, um dem Kernel zu sagen, dass man auf diesen Lock hier warten will. Der Kernel suspendiert dann den Thread.
Beim Unlock geht man analog vor; man zieht atomar einen ab, und wenn man bei 0 rauskommt, ist alles gut und man ist fertig, ansonsten ruft man den Futex-Syscall auf und sagt an, dass man mal einen der wartenden Threads aufgeweckt haben will. Es gibt da noch zwei-drei Komplikationen aber im Wesentlichen ist es das. Den Syscall benutzt man nur, wenn man nicht im Userspace über die atomaren Operationen schon alles geklärt hat.
glibc hat über NPTL seit vielen Jahren Futex-Support.
Mein Test-Programm ist untypisch, denn es macht vier Threads auf, die alle dauernd um den selben Lock konkurrieren. An sich sind Locks ja genau auf den anderen Fall optimiert, nämlich dass es keinen Wettbewerb gibt im Normalfall, insofern ist das kein sonderlich guter Test, aber es ging ja ursprünglich auch gar nicht um den Durchsatz, sondern die Threads prüfen auch, ob sie tatsächlich als einzige Zugriff hatten.
Hier ist der Durchsatz (am Anfang insgesamt und die vier Zahlen am Ende sind für die einzelnen Threads):
glibc:Die Ergebnisse haben mich ja nun doch massiv überrascht. Falls sich jemand den Code mal angucken will: hier ist er. Ich habe den neuen Futex-basierten Locking-Code dann lieber doch nicht eingecheckt angesichts dieser Zahlen :-)
5840543 iterations: 1450529 1436218 1478655 1475141.dietlibc alt:
80426491 iterations: 18957811 16267831 19589958 25610891.dietlibc neu mit futex:
11477382 iterations: 2868532 2830930 2876189 2901731.
Oh, einen noch. Es gibt da noch eine Optimierung, die man gerne macht beim Locking. Man ruft nicht sofort den Kernel an, sondern probiert es erst ein paar Mal. Der Gedanke dahinter ist, dass normalerweise so ein Lock ja nur sehr kurz gehalten wird, und man sich den Syscall-Overhead auch sparen kann, wenn der, der den Lock gerade hält, nur mal kurz ein-zwei Variablen schreibt und ihn dann wieder freigibt. Das hat mein Futex-Code natürlich auch getan. Und zwar erst 100 Mal, dann nur noch 10 Mal. Hat den Durchsatz signifikant erhöht, das auf 10 zu senken. Das hat mich auch überrascht.
Update: Falls ihr mal eure libc testen wollt: das lief auf einem 64-bit Linux auf einem Phenom 1090T (3.2 GHz, 6 cores).
Ich für meinen Teil suche ja seit längerem nach einer schönen ARM-Bastelplattform. Auf USB-powered würde ich nicht bestehen, aber ich hätte gerne ein Mini-ITX-Board o.ä., damit es da auch ordentlich Steckplätze gibt, um daraus einen Router und ein NAS und was man sonst so braucht zu bauen. Und ich hätte gerne einen dieser kräftigeren ARMs, wie sie in Smartphones verbaut werden, und dass ich einen HDMI-Ausgang habe und damit mit mplayer H.264 1080p abspielen kann. Aber so diese Bastel-Ecke scheint keiner der Anbieter zu wollen. Android geht mir mal voll am Arsch vorbei, ich will da selber ein Linux drauftun.
Update: Weil jetzt hier Dutzende Hinweise auf Raspberry Pi und Pandaboard reinkommen: ich brauche mindestens zwei Ethernet-Ports, und mindestens einer davon muss Gigabit sein, und ich muss Sata-Platten anschließen können. Und das Teil soll dann auch bitte in der Lage sein, den Gigabit-Port zu saturieren beim File-Serven von der Platte.
Update: Jetzt kommen hier gehäuft Plug-Computer-Vorschläge rein. Man liest im Internet, dass die alle ein Hitzeproblem haben.
Theorien und Vorschläge nehme ich gerne per Email entgegen. Im Moment tendiere ich zu "die haben ihre LI-Software von Digitask gekauft und die spackt jetzt halt herum" :-)
Update: Bei diversen Leuten geht es offenbar problemlos.
Update: Es gibt einen Schuldigen. CACert hat offensichtlich gerade einen OCSP-Fuckup. Wenn Firefox bei denen eine OCSP-Anfrage für mein Cert stellt, kriegt er ein "403 Access Forbidden" zurück. Mit anderen Worten: Chrome macht kein OCSP. m( Man kann OCSP auch in Firefox ausschalten (security.OCSP.enabled = 0), aber an sich will man ja OCSP haben. Dieses SSL ist echt ein Haufen Sondermüll. Macht Firefox bei jedem Zugriff einen OCSP-Request oder nur einmal pro Tag? Man fragt ja ein spezifisches Zertifikat an, das hieße ja, dass CAcert ein Bewegungsprofil erstellen kann. Mann ist das alles für den Fuß.
Update: Mir mailt gerade jemand: Firefox prüft einmal pro Session, und Chrome macht doch OCSP aber macht daraus keinen Timeout sondern zeigt dann ein kleines gelbes Dreieck als Warnung an.
Das sieht alles aus wie ein Standard-Rootkit, und das kam rein über einen legitimen Account eines Benutzers auf der Maschine, dem sein Rack-Server aufgehackt wurde. Offenbar wussten die Angreifer nicht, was sie da wertvolles aufgemacht hatten, jedenfalls haben sie nichts groß verändert außer halt sich da ins System einzunisten und das ssh zu ersetzen und so.
Die Linux-Kernel selbst sind nicht betroffen, und können auch gar nicht groß betroffen sein, weil die aus Linus' Privatsystem kommen, nicht von dort. git ist ein verteiles Versionierungssystem und da liegt nicht auf dieser Kiste auch "der git-Server", über den man die Kernelsourcen kompromittieren könnte. Und selbst wenn, dann benutzt git kryptographische Prüfsummen, das würde sofort auffallen, wenn da jemand was in der Versionsvergangenheit manipulieren will. Es gibt natürlich trotzdem noch ein paar offene Fragen, und sicherheitshalber haben sie doch alle in letzter Zeit veränderten oder hochgeladenen Tarballs nochmal überprüft. Aber akute Angst muss wohl keiner haben.
Es zeigt aber natürlich trotzdem, dass nicht mal die Linux-Kernel-Leute vor sowas gefeit sind. So schlimm ist der Stand der Computer-Security. Seufz.
Oh, eines noch: der Useraccount hatte keinen Superuser-Zugriff. Das Rootkit schon. Es gibt also noch mindestens einen Exploit für local privilege escalation unter Linux unter x86-64. Gut, das wird jetzt niemanden überraschen, der sich mit der Materie auskennt, aber es ist natürlich schon beunruhigend. Auf der anderen Seite wird das jetzt vielleicht eine Audit-Hetzjagd lostreten, bei der dann der und einige andere Fehler gefunden werden.
Zu "der WebGL-Lücke" habe ich nichts gesagt, weil das keine Lücke ist, sondern eine Idee der Größenordnung "lasst uns im Winter Russland angreifen". Ich versuche das mal kurz zu erklären. Prozessoren haben heutzutage eine MMU drin. Die MMU erlaubt es, Speicherschutz zu implementieren. Das Betriebssystem kann damit z.B. verhindern, dass irgendwelche Prozesse Speicherbereiche anderer Prozesse oder des Betriebssystems selber kaputtmachen.
Hardware hat sowas nicht. Insbesondere haben Grafikkarten sowas nicht. Früher war das nicht so schlimm, weil auf der Grafikkarte kein Code lief, also jedenfalls kein hochgeladener Code, sondern man konnte halt aus ein paar Operationen auswählen, die dann auf der Grafikkarte ausgeführt werden. Heute haben Grafikkarten eigene Programme, die Shader. Die können u.a. auf den Hauptspeicher des PCs zugreifen. Lesend und schreibend.
Mit anderen Worten: wer Shader auf die Grafikkarte hochladen kann, hat Schreibzugriff auf das Betriebssystem.
Das hat sich noch nicht weit genug herumgesprochen, dass die Malware-Toolkits das regulär benutzen. Aber alle, die sich mit der Technologie mal beschäftigt haben, wissen das. Grafikkarten sind da nicht alleine. Jede Hardware am PCI-Bus kann das. Und PC-Card und ExpressCard sind im Wesentlichen auch nur herausgeführte PCI-Busse. Wer also ein Notebook mit solchen Slots hat, der gibt jedem mit physischem Zugriff auf das Gerät auch softwaretechnisch Vollzugriff auf das Gerät, und zwar ohne dass derjenige rumschrauben müsste.
Und dann gibt es natürlich noch schlechte Ideen wie Firewire, was kein PCI-Bus ist, aber wo man über den Stecker trotzdem Schreibzugriff auf den Hauptspeicher im Rechner hat. Das selbe in Grün. Es sah ja eine Weile so aus, als hätte man aus dem Firewire-Debakel gelernt, aber nein, Intels neueste Technologie, Thunderbolt, führt gleich einen ganzen PCI-Express-Bus per Stecker raus aus dem Gehäuse. SUPER!
Aber zurück zu den Grafikkarten. Wenn man das einmal verstanden hat, dass Shader-Zugriff auf Grafikkarten sicherheitstechnisch Game Over ist, verstehen man auch plötzlich diverse andere Dinge als die schlechte Idee, die sie sind. Z.B. … in "virtuellen Maschinen" 3d-Grafik zu machen. Oder … 3d-Grafik über Netz forwarden! Game Over.
Es gibt eine Hoffnung im dem ganzen Jammertal. IOMMU. IOMMU ist eine MMU für I/O-Zugriffe. Damit könnte man also z.B. einschränken, welche Speicherbereiche die Grafikkarte überhaupt sehen kann. AMD hat sowas schon länger, Intel hat kürzlich nachgelegt. Leider … gibt es da auch schon Angriffe drauf.
Solange es hier keine funktionierende und erprobte Schutz-Technologie gibt, muss man alle 3d-Software (und natürlich erst Recht OpenCL/Cuda/Stream-Kram) so betrachten, als habe man ihr gerade Vollzugriff auf das System erteilt. Denn im Wesentlichen hat man das.
Vielleicht versteht jetzt der eine oder andere, wieso man keinesfalls irgendwelchen Webseiten Shader-Zugriff auf seine Grafikhardware geben will.
Update: Hier kommen gerade ein paar Mails von Leuten rein, die es besser/genauer wissen als ich. Die beiden Haupteinwände sind: a) man kann per WebGL nur GLSL hochladen, nicht binäre Shader, und b) die Grafikkarte kann nicht auf den kompletten Speicher im PC zugreifen, sondern nur auf die Bereiche, die der Treiber eingestellt hat. Soweit ich weiß ist das generell beides richtig.
Allerdings sind ja die Treiber nicht Open Source (Ausnahmen bestätigen die Regel; Benutzer der Open Source GL-Treiber unter Linux können hier möglicherweise ruhiger schlafen). Und Kontextwechsel kosten. Und Grafikkartentreibern geht es um Performance, sogar mehr noch als um Korrektheit. Ich bleibe daher bei meiner Einschätzung. Zumindest bis jemand kommt und es mir noch anders erklärt :-)
Sein neuester Streich: Ein x86-Emulator in Javascript. Im Emulator läuft ein Linux-Kernel, und das ganze emuliert einen Ranz-x86 mit Ramdisk und Serialport für die Ausgaben. Spannenderweise performt das in Firefox doppelt so gut wie in Chrome schreibt er. Auf jedenfall mal wieder ein echter Fabrice Bellard-Kracher.
So, lasst mal eure Hand gleich an der Stirn, geht noch weiter.
Daraufhin haben die Polizisten zwei Polizeitechniker dazugerufen, um digital an das Dokument zu kommen. Das Dokument, das SEIT NOVEMBER frei auf der Homepage von Attac zum Download steht. Das scheiterte dann an den mangelnden Linux-Kenntnissen der Ermittler.
Halt, noch nicht aufhören mit dem fazialpalmieren, geht noch weiter!
Am Ende haben sie es sich dann vor Ort von der Attac-Homepage runtergeladen. Was sie auch ohne Durchsuchung von zuhause aus hätten machen können. Und dann gingen sie.
Und DIE sollen uns vor den Kriminellen und Terroristen schützen!
Update: Die glibc-Patches, die das memcpy rückwärts kopieren lassen, kommen übrigens von Intel, weil sie auf dem Atom die Prefetch-Logik verkackt haben.
Aber natürlich ist es auch Ziel, mal die Klagewelle der Verwertungsindustrie abzuwenden, indem man mal einem Richter sachverständig erklärt, wie eigentlich so ein Tracker funktioniert. (NB: als Sachverständige, nicht als Beklagte) Ich will das hier mal stellvertretend versuchen, für das Verständnis unlauter abkürzend, aber nicht sinnentstellend.
Ein Tracker verteilt keine Dateien. Nehmen wir mal an, ihr wollt euch den Fnord-Jahresrückblick 2010 per Bittorrent runterladen. Das Torrent-File beinhaltet folgendes:
Ihr habt euch also die Torrent-Datei gezogen, und mit der geht euer Torrent-Client jetzt der Reihe nach zu den Trackern, die in der Datei drinstehen, und sagt denen: hallo, ich bin ein Torrent-Client, ich habe Interesse an dem Torrent mit diesem Hashwert hier (der, der in der Torrent-Datei drinsteht), und ich habe von den Nutzdaten schon folgende Blöcke hier.
Der Tracker hat jetzt eine Liste oder auch Datenbank von allen Hashes, nach denen er schon gefragt wurde, und trägt als erstes bei dem angefragten Hash die IP-Adresse des Anfragenden ein. Dann gibt er dem Client eine Teil-Liste von IPs zu dem Hash. Nicht alle IPS, sondern nur ein paar. Und man kann auch nicht einfach mehrfach fragen und kriegt dann alle oder auch nur andere IPs. Da muss man warten, bis der Tracker andere IPs rausrückt.
Mit diesen IPs geht der Client jetzt herum und fragt jeden davon, welche Blöcke er hat. Dann fängt er an, von den Clients hinter den IPs die Blöcke zu downloaden, die noch am wenigsten verbreitet sind.
Die beachtenswerten Punkte hierbei sind: der Tracker weiß gar nicht, was er da trackt. Alles, was er hat, ist ein Hashwert. Der sieht, wenn man ihn in Form einer Magnet-URL schreibt, so aus:
magnet:?xt=urn:btih:3CJATDQBXFUEQCXVXZHUUNALQK5GXCTQNehmen wir jetzt mal an, du bist ein Tracker. Und jemand kommt zu dir und fragt nach den IPs zu obigem Hash. Nicht nur bist du kein Raubkopierer, du kannst nicht mal wissen, ob es sich bei den Nutzdaten, die diesen Hash ergeben haben, um eine Raubkopie handelt oder nicht. Du kannst nicht mal wissen, ob es überhaupt Nutzdaten gibt, die diesen Hash ergeben, denn ein Troll kann natürlich einfach nach einer beliebigen Zahlenkombination fragen, zu der es am Ende gar keinen Torrent gibt.
Wenn die Content-Industrie sich also hinstellt, und dem Trackerbetreiber Beihilfe unterstellt, dann hat das von den Fakten her keinerlei Basis in der Realität. Es gibt nichts, was ein Trackerbetreiber tun könnte, um zu einem gegebenen Torrent herauszufinden, um was für Inhalte es sich handelt. Er könnte natürlich loslaufen und Suchmaschinen nach dem Hash befragen. Aber selbst dann hat er ja nur den Dateinamen und Hashes, d.h. er muss die Nutzdaten erst einmal selber runterladen, um prüfen zu können, ob es sich um eine Raubkopie handelt. Es ist also überhaupt nicht möglich für einen Trackerbetreiber, das Tracken von Raubkopien zu verhindern. Selbst wenn der Trackerbetreiber nur Hashes seiner eigenen Dateien zulässt, dann kann es theoretisch immer noch Raubkopien geben, die denselben Hashwert ergeben. Die Wahrscheinlichkeit ist zwar sehr gering, aber ausgeschlossen ist das nicht.
Nun könnte man sich vorstellen, dass die Verwertungsgesellschaften eine Liste von "verbotenen" Hashes publiziert. Und die geben sie dem Trackerbetreiber, und der blockiert die dann. Was passiert, wenn man sowas zulässt, sieht man gerade schön auf Youtube, wo regelmäßig Creative Commons-Musik runterfliegt, weil irgendeine Verwertungsgesellschaft einen "bedauerlichen Fehler" begangen hat.
Aus Sicht des CCC ist ein Tracker eine Art schwarzes Brett im Internet, auf dem IP-Nummern und Zahlenreihen draufstehen. Wir haben den Content gar nicht, um den es da geht, und daher kann man von uns nicht verlangen, dass wir da groß prüfen.
Der CCC findet, dass der Betrieb eines offenen Trackers legal ist, auch wenn Gerichte in der Vergangenheit gerne mal (in vermuteter Unkenntnis der Technik) anders entschieden haben.
Nun ist das natürlich nicht schön gelaufen, dass die Leute vom Piratebay den Tracker so schnell gefunden haben und auch noch in ihre Torrents eintragen. Dieser Tracker ist nämlich gerade nicht, wie vom ehemaligen Nachrichtenmagazin schlampig recherchiert, der "Nachfolgetracker von denis.stalker", der im Übrigen nicht mal ein Angebot des CCC war. Wenn das eine Kampagne sein soll, um unsere Argumentation in Ermangelung von Gegenargumenten per Assoziation mit der Piratenbucht zu schädigen, dann wird das scheitern.
Übrigens braucht man Tracker gar nicht mehr notwendigerweise. Es gibt inzwischen auch Verfahren, wie sich Clients ganz ohne Tracker gegenseitig finden können. Diese ganze sinnlose Fixierung auf die Tracker kommt daher, dass die Contentindustrie keinen besseren Ansatzpunkt gefunden hat, um ihr veraltetes Denkmodell von "es gibt da einen gewerbsmäßigen Hehler und lauter Konsumenten, die wir aber nicht abmahnen wollen, weil das ja unsere Kunden sind" auf Bittorrent anzuwenden, und wenn man keine Ahnung von der Materie hat, sieht so ein Tracker wie das am ehesten passende Ziel aus.
Update: Es gibt auch ein neues Blogposting dazu im Opentracker-Blog. Oh und ja, der Tracker ist absichtlich offen, da dürft ihr gerne eure Linux-ISO-Images drauf tracken, und eure Creative Commons-Musik.
Update: Wer sich für weitere Details zu Trackern interessiert, dem sei auch noch mal der 24c3-Vortrag dazu ans Herz gelegt. Den gibt es auch bei Piratebay :-)
Hier ist jetzt, wo eure Hilfe gebraucht wird. Es gibt ein Wiki zu der Sache. Es werden Leute gebraucht, die sich durch die einschlägigen Webforen wühlen, und in dem Wiki mal die Postings von dem graf_chokolo verlinken und analysieren, damit sich ein schlüssiges Bild ergibt, aus dem man dann vor Gericht zeigen kann, ob es dem ums Raubkopieren oder ums Linux-Booten ging.
Wenn ihr das gewissenhaft macht, tut ihr Sony damit mehr weh als mit Produktboykotten. Dieses Gerichtsverfahren muss denen vor laufenden Kameras der Weltpresse ins Gesicht aufplatzen wie eine eiternde Pestbeule. Ansonsten wird sich da nie was ändern.
Das ist kein Aufruf zur Aktenfälschung hier. Es geht nicht darum, etwaige Beweise zu unterdrücken, dass er Raubkopieren wollte, wenn sich das denn als die Wahrheit herausstellt. Aber so sieht es im Moment jedenfalls nicht aus.
In diesem Sinne: tut mal was Positives mit eurer Zeit! :-)
Sehr beeindruckend!
Ich finde es immer schade, dass da die geifernden Linux-Horden die Kommentare mit ihrer schlechten Laune vergiften, anstatt da mal konstruktiv tätig zu werden. Es ist übrigens bei weitem nicht so, dass Linux weniger Sicherheitslücken hat, wie der eine oder andere vielleicht in seiner naiven Unwissenheit annimmt. Es gibt nur noch keinen Trojaner-Markt, weil der Marktanteil zu gering ist. Genau das gleiche Phänomen, das auch Apple im Moment noch schützt.
Keylogger, die laut ARD-Magazin „Plusminus“ geheime Daten abfangen konnten, sind wirkungslos.AU AU AU DAS TUT SO WEH!!
Die Zahlen werden auf der Bildschirmtastatur zufällig angeordnet, die Übertragung erfolgt verschlüsselt, sodass die PIN deutlich besser gegen „Abhören“ geschützt ist.Die Übertragung zwischen Maus und PC erfolgt selbstverständlich nicht verschlüsselt. Wer das nicht glaubt, kann sich das ja mal im Linux-Kernel angucken, da gibt es einen Maustreiber für jeden zum angucken.
Wer nicht sofort versteht, was für eine hanebüchene Irreführung diese Aussage ist, der kann sich ja mal Back Orifice (aus dem letzten Jahrtausend!!) angucken, oder VNC (es gibt in Metasploit eine VNC-Payload). Mann müssen die verzweifelt sein, so eine plumpe Masche überhaupt in Erwägung zu ziehen.
Update: Falls jemand zu faul ist, auf die Links zu klicken: das sind Methoden, um den Bildschirm in einem Trojaner abzufilmen. Da sieht man dann, worauf jemand klickt. Zufällige Anordnung der Knöpfe und verschiebbares Fenster hilft da gar nichts.
Update: das ist noch subtil anders: das Passwort ist nicht hardgecoded, aber es wird im Client geprüft. Kommt also aufs Gleiche raus. Ein Detail, was in dem Advisory nicht erwähnt wurde: das SuperUser-Passwort ist identisch mit dem root-Passwort von dem Linux auf der darunterliegenden Telefonanlage.
Dass die Fonts in jedem Browser eine subtil andere Größe haben, das ist glaube ich mein Fehler. Falls jemand weiß, wie man das ohne Browserweiche besser macht, nehme ich Hinweise gerne entgegen.
Update: Ach wie schön, der Vollkorn-Autor hat vor ein paar Tage eine neue Version mit besserem Hinting veröffentlicht. Gleich mal updaten :-)
Erster Eindruck: das von HP installierte Windows 7 ist arschlahm, gefühlte 300 Crapplications sind vorinstalliert, inklusive einem Adobe Reader 9.1.0. Da kann man entweder einen Tag mit Updaten und Aufräumen verbringen oder neuinstallieren. Leider kommt das Teil nicht mit einem Installationsmedium. Frisch installieren mit Bordmitteln geht nicht, man kann nur den Auslieferungszustand wiederherstellen; da kopiert er dann ein Image über die Partition. Na super.
Eine Linux-Installation scheitert erstmal daran, dass HP mit vier Partitionen ausliefert, da ist dann kein Slot frei. Eine Boot-Partition, eine Windows-Partition, eine Recovery-Partition (und da es keine externen Recovery-Medien gibt, will ich die auch nicht einfach wegschmeißen), und eine vierte obskure FAT-Partition mit Dateinamen, die nach BIOS-Update aussehen. Unklar. Ich fürchte fast, da bleibt mir am Ende nur einmal alles wegschmeißen und neumachen. Seufz.
Da muss man erstmal ein paar Dinge umstellen, wie z.B. dass ein Druck auf F1 nicht F1 erzeugt, sondern was man sonst unter Fn+F1 erwarten würde. Den F1-Keycode kriegt man nur mit Fn+F1. Lässt sich aber im BIOS umschalten.
Das Gehäuse wirkt ganz OK aber das Gerät wirkt recht schwer, wie ich finde. Die "coole" perforierte Oberfläche und das beleuchtete HP-Logo hätten sie sich sparen können, das nervt mehr als es gut aussieht. Aber immerhin kein Thinkpad.
Das Trackpad nervt, weil es keine Mausknöpfe hat. Da sind einfach Teile des Pads als Maustaste reserviert worden. Da hab ich normalerweise meinen Daumen liegen. Das deutet das Pad jetzt immer als Multitouch-Geste und bringt mich damit um den Verstand. Kann man hoffentlich umkonfigurieren.
In den HP-Foren meckern die User rum, dass HP den ATI-Grafikchip 100 MHz weniger taktet als die Konkurrenz. Wird sich zeigen, ob ich damit leben kann.
Anscheinend muss man großflächig rumschrauben an dem Gerät, um den RAM zu wechseln. Oder das ist unter der Platte versteckt. Keine Ahnung, das Gerät kommt mit 4 GB, da hab ich keinen akuten Bedarf gerade. VGA gibt es nicht, nur HDMI und etwas, das ich für DisplayPort halte (hatte ich noch nie, ist also nur geraten), und Umwandler zu VGA oder DVI sind nur optional erhältlich und liegen nicht bei. Das werte ich mal als Zeichen, dass ich das lieber woanders kaufen sollte.
Ich habe ja nun noch keine echte Last auf dem Gerät erzeugt, aber bisher ist es angenehm leise und kühl.
Außerdem publiziert niemand das mir persönlich wichtigste Detail: wie laut das Gerät ist, unter wenig Last (webklicken), unter mittlerer Last (webklicken mit Flash, Film abspielen), unter hoher Last (3d-Spiel zocken). Ich möchte gerne wissen, ob die einen Staubfilter vor ihrem Lufteinzug haben, oder ob ich den Laptop alle halbe Jahr aufmachen und entstauben muss.
Ansonsten geht der Trend zur kleinen Display-Auflösung. Die Branche scheint sich geeinigt zu haben, dass 1366x768 eine akzeptable Auflösung ist. Ist es nicht. Und was für eine Frechheit, an so eine Knauser-Auflösung auch noch "HD" dranzuschreiben!
Meine Anforderungen sind eigentlich eher klein, wie ich finde. Ich möchte gerne ein leises Gerät, das bei niedriger Last gar kein Geräusch macht, bei dem der Akku lange hält (5h Minimum ohne Last), das in bei einem Display von 15,6" oder weniger in beiden Dimensionen nicht deutlich unter meiner alten Auflösung von 1680x1050 liegt, das mit eSATA kommt und wo die Tastatur brauchbar ist (d.h. nicht wie beim HP Envy 15 links neben der Ctrl-Taste noch eine Tastenreihe mit wertlosen "value-add" Knöpfen wie der "Taschenrechner"-Taste; auch komplett verboten ist die Thinkpad-Unsitte, links unten die Fn-Taste zu haben, da gehört Ctrl hin).
Für ernsthaftes Arbeiten im Büro muss man extern digital einen hochauflösenden Monitor anschließen können. Beim Display will ich matt und dunkel schaltbar, dieser Sonnenbrandtrend ist mir zuwider.
Oh und wenn mir jemand im Jahr 2010 noch ein Notebook ohne Gigabit Ethernet anbieten will, dann werte ich das als Verarschung und kaufe dort nicht.
Das ist alles.
Ihr werdet lachen, ich finde keine Notebooks, die dem genügen.
Ich bin bisher Acer-Kunde. Aber deren Webseite wird immer schlechter, eine simple Produktliste mit Gegenüberstellung ist schon zuviel verlangt. Außerdem sind deren Displays heutzutage alle glossy 1366x768. Scheidet also aus.
Thinkpad geht wegen der Tastatur nicht, außerdem komme ich mir verarscht vor, wenn ich sehe, dass das Baseline-T-Serie-Modell in den USA mit Optionen Klicken bei 1000 Dollar anfängt, aber in Deutschland bei 2300 Euro. Im Übrigen finde ich Thinkpads äußerlich abstoßend. So abstoßend, dass ich damit nicht in der Öffentlichkeit gesehen werden will.
Macbook geht aus fundamentalreligiösen Gründen nicht (und wegen deren Tastatur, die geht ja mal GAR nicht).
Dell Studio 15 habe ich kurz erwogen, aber deren Displays sind nur glossy. Und bei der Kundenbewertungs-Webseite dazu steht, dass deren Belüftung (festhalten) zugedeckt wird, wenn man das Display aufklappt. m( Daraus folgt: Lüfter laut. Ansonsten hätte ich das gekauft.
Das HP Envy 14 scheint bisher am nächsten an dem dran zu sein, was ich haben will. Allerdings ist das Display spiegelnd. MOAN EY. Sind Notebooks nur noch Lifestyle-Krams, den sich Leute kaufen, die das dann nicht benutzen? Auf einem Spiegeldisplay kann man sich doch nicht mal in Ruhe in der Bahn ein Filmchen angucken, ohne vor allem reflektierte Bäume zu sehen, an denen der Zug gerade vorbeifährt.
Tja, was bleibt denn da überhaupt noch? Toshiba-Notebooks habe ich bisher nur als mechanisch schrottig verarbeitet erlebt, die ziehe ich nicht in Erwägung im Moment. Im Übrigen ist bei denen auch bei 1366x768 Schluß.
Und Sony ist prominenter Vertreter der Contentmafia, die boykottiere ich nicht erst seit sie ihren Kunden Rootkits installieren wollen.
Von Asus habe ich nur schlechtes gehört, insbesondere hat mich deren Support immer im Stich gelassen bisher, und das waren nur PC-Komponenten, kein ganzes Notebook. Solches Verhalten belohne ich nicht noch mit Notebookkauf.
Samsung scheidet aus, weil sie kein Gigabit Ethernet verbauen.
Wo holt ihr euch eure Notebook-Kaufberatung her? Ich bin entsetzt, dass ich im Moment noch die beste "ich klicke mir die Features, die ich haben will" Auswahl bei Geizhals finde.
Eine positive Sache möchte ich aber doch erwähnen: beim Klicken durch die Review-Webseiten hat mich notebookcheck.net mit Reviews wie diesem hier überzeugt. So muss ein Review sein. Vor allem die Vergleichshistogramme unter den Balkengraphen gefallen mir dort. Wieso macht das sonst keiner?
Tja, da mich die großen Hersteller im Stich lassen, werde ich mich jetzt mal durch die kleinen Anbieter klicken, und wenn das auch nicht hilft, dann werde ich wohl meine Ansprüche runterschrauben müssen. Seufz.
Update: Mir wird empfohlen, bei Dell mal durch die Geschäftskundenseiten zu klicken, da gäbe es die Displays mit matter Oberfläche. Werde ich mal tun. Außerdem empfehlen mir einige Leute HP Notebooks wie das 8530p. Da ist halt ein nach heutigen Maßstäben antiker Grafikchip drin. Gut, würde ich wahrscheinlich mit überleben können, aber fiel bei mir durchs Raster, weil es heute eben Hybridgrafik gibt. Da fährt man unter Linux oder auf Akku die gammelige Intel-Chipsatzgrafik und schaltet nur fürs 3d-Zocken ordentliche Grafik dazu, aber die soll dann bitte auch anständig schnell laufen und da kann es dann ruhig auch laut werden beim Kühlen. Da hab ich eh Ohrstöpsel drin und höre das nicht. Ich bin gerade am Erwägen, ob ich nicht ein N220+ o.ä. fürs mobile Arbeiten kaufe und ein Gamer-Notebook mit Spiegeldisplay zum Zocken. Seufz.
Update: Zum Thinkpad erzählen mir gerade Leute, dass es da inoffizielle BIOS-Hacks gibt, um Fn und Ctrl zu tauschen. m(
Update: Bei den ganz neuen Thinkpads kann man das wohl ohne Hack im BIOS einstellen. Und bei Samsung gibt es auch eine Geschäftskundensparte mit Gigabit Ethernet und matten Displays, aber irgendwas ist immer. Mal Auflösung zu klein, mal nur Chipsatzgrafik, … Das hier sieht gut aus, aber das verkaufen sie noch mit Vista. Hoffentlich gibt es da auch eine aktuellere Version von.
Update: Noch ein erwägenswerter Tipp, der hier gerade reinkommt: Notebook mit Spiegeldisplay kaufen und hier mattieren lassen.
<img src="logo.svg">und alles wird gut, aber weit gefehlt! Stellt sich raus, dass Chrome das kann, Firefox aber nicht. Firefox erwartet ein object-Tag. Was für ein Hirnriss!
Aber das ist noch nicht alles. Stellt sich raus, dass Safari SVG kann (ist ja auch Webkit wie Chrome, damit war zu rechnen), aber NICHT auf dem Iphone oder Ipad. WTF?! Gerade das Ipad haben sie doch als Browser-Device verkauft!
An der Safari-Version kann man es nicht festmachen. Die Plattformstrings werden schnell unübersichtlich, es gibt da auch noch irgendein webtv-Zeugs, kenn ich alles nicht. Also ist da jetzt eine Javascript-Browsererkennung drin. Wie furchtbar ist DAS denn alles?! Ich dachte, die Zeiten seien vorbei im Web?
Also aus meiner Sicht: Schande über Apple und Firefox.
Und zur Krönung des Tages kommt hier auch noch einer an, der benutzt Epiphany mit Webkit, und das gibt sich als Safari unter Linux aus. Das bau ich da jetzt nicht ein. Was für ein Müll dieses Web doch ist.
Oh und bei Firefox ist offenbar das UI für das audio-Tag kaputt und man kann da nicht die Lautstärke regeln. Na suuuuuper. Bin ich wirklich der erste, der das Audio-Tag benutzt?! Ist das echt noch keinem aufgefallen?!?
Ich frage mich ja, wenn sie schon ein PDF-Plugin machen, wieso sich PDF-Seiten dann nicht genau so anfühlen wie HTML-Seiten. Das fühlt sich alles noch … anders an. Rechtsklick gibt es gar nicht, Mittelklick auf einen Link im PDF tut auch nicht das selbe wie bei HTML… da geht noch was.
Die "Missionierung" ist ausdrücklich KEIN Ziel des Vertrages.Na dann haben wir ja nochmal Glück gehabt!
Und die RWTH ist da nur eine von vielen Unis, die das so macht. Seit ich an der Uni war, scheint sich MS da mehr als breit gemacht zu haben. Active Directory, Exchange, Sharepoint *grusel* (Danke, Matthias)
Und da wundern die sich, dass die Leute alle weg wollen von dieser Krätze und zu HTML5 wechseln.
Allerdings, ein Aspekt daran verdient lautes Gelächter:
Google will das Windows-Betriebssystem aus Sicherheitsgründen aus seinem Unternehmen verbannen.OK, was ist hier bitte die Botschaft? Google hält OS X für sicherer als Windows? HAHAHAHAHAHA[…]
Bereits seit Anfang dieses Jahres gelte eine Anweisung, wonach neu eingestellte Mitarbeiter nur noch zwischen Mac OS X und Linux wählen dürften.
Und der Aspekt, dass das nur für die neuen Mitarbeiter gilt … das ist ja wohl hoffentlich ein Übersetzungsfehler?! Die können doch nicht ernsthaft eine Steigerung des Sicherheitsniveaus erwarten, wenn das nur für die neuen Mitarbeiter gilt?!
Kurz gesagt: lange nicht mehr hat eine Firma durch nur eine Pressemitteilung soviel Kompetenz-Image eingebüßt.
open("/lib/fimware/updates/radeon/R520_cp.bin", O_RDONLY) = -1 ENOENT (No such file or directory)"fimware". Ja, fimware! udev versucht, die Firmware aus dem falschen Verzeichnis zu laden! Hab ich was kaputtkonfiguriert, würde man denken. Schaunmermal:$ cd /tmp/udev-152Wenn Inkompetenz weh tun würde, wären diese Knalltüten schon längst im künstlichen Koma. Versager, wo man hinguckt.
$ grep -r fimware .
./configure: with_firmware_path="/lib/fimware/updates:/lib/fimware"
./configure.ac: [with_firmware_path="/lib/fimware/updates:/lib/fimware"]
Dann brauchten wir ein devfs. Da hießen dann plötzlich alle Devices anders. Klar, liegt ja auch nahe. Also haben wir alle Software anfassen müssen, die mit Devices operiert.
Dann reichte das plötzlich nicht mehr, und wir brauchten udev. Da hießen dann plötzlich wieder alle Devices anders. Klar, liegt ja auch nahe. Also haben wir wieder alle Software anfassen müssen, die mit Devices operiert.
Das reichte dann plötzlich auch nicht mehr. Wir brauchten ein Layer darüber, "hald", von den Freedesktop-Spacken. Das habe ich noch nie irgendwo funktionieren sehen, es ist die Krätze auf Erden, ein unfassbarer Haufen Scheiße, das geht gar nicht. Der Antichrist persönlich würde sich in Grausen abwenden, wenn es ihn gäbe. Es ist so furchtbar, dass selbst seine Erfinder sich jetzt davon abwenden. Das neue X 1.8 zieht jetzt seine Device-Informationen nicht mehr aus hald, sondern aus udev. Das führt bei mir dazu, dass er weder Maus noch Keyboard findet. Warum auch. Braucht man ja auch nicht. Natürlich beendet sich X nicht, wenn er keine Devices findet, sondern er bleibt hängen, so dass man die Kiste resetten muss, um es wieder zu beenden. TOLLES ENGINEERING, ihr Spacken!
Nach nur wenigen Stunden meiner Lebenszeit, die ich in diesen undebugbaren Haufen Mist stecken mußte, habe ich folgende Lösung gefunden:
Section "ServerFlags"Ich neige ja an sich nicht zu Gewaltphantasien, aber diese Leute haben Ferien in Abu Ghraib verdient.
Option "AutoAddDevice" "false"
Option "AllowEmptyInput" "false"
EndSection
Oh und von dbus fange ich gar nicht an, das setzt dem nochmal eine Krone auf. Wieso erfinden die Leute alle Automatismen, die dann nicht automatisch funktionieren, sondern umfängliche Konfigurationsarbeiten benötigen?! Ich erinnere mich mit Grausen daran, diese furchtbare Bluetooth-Grütze debuggen zu müssen, die plötzlich dbus wollte. KOTZ!
Ich will an der Stelle mal einen Freund zitieren:
die freedesktop-leute spenden ja sonst ihre gesamte zeit damit, linux und x11 zu einem single-user-system zu machen. jetzt sind sie wohl noch einen schritt weiter beim zero-user-system
Das hat mich über die Jahre so viel Zeit gekostet und soviel Ärger gemacht, dass es auf dem besten Weg ist, den Ärger aufzuwiegen, den ich in der Zeit mit bei Windows bleiben gehabt hätte. Es ist eine Schande, dass wir es so weit kommen lassen. Ich bin ja fast gewillt, das langsam als Zersetzungsstrategie aufzufassen, zumal da ja auch die ganzen Distro-Versager mitpfuschen, die offensichtlich alle das Geheimwissen als Firmengeheimnis behalten wollen, das man braucht, um ihren Automatismus-Müll zum Funktionieren zu bewegen.
Der Stream sieht für mich nicht so aus, als könne das funktionieren. Erstens mal besteht ungefähr die Hälfte der übertragenen Daten nur aus leeren Frames voller 0xff, das irritiert ja schonmal. mplayer sagt bei mir folgendes (arte HD):
TS file format detected.Hat jemand Vorschläge?
VIDEO MPEG2(pid=6210) AUDIO MPA(pid=6221) NO SUBS (yet)! PROGRAM N. 0
MPEG: FATAL: EOF while searching for sequence header.
Video: Cannot read properties.
Update: ffplay kann das spielen, aber mit falscher fps-Rate und damit auch unbrauchbar. Aber immerhin weiß ich jetzt, dass da tatsächlich Bild und Ton kommt.
Update: So kann man die Aufnahmen abspielen:
mplayer -demuxer lavf dvb-dump.tsMeine Fresse sieht das gut aus. Auf arte läuft gerade eine Sendung über Kanada, wo sie mit einem Flugzeug über einen Wald fliegen. Da sind bei den schrottigen MPEG2-SD-Streams außer Kubistik-Klötzchenartefakten nichts mehr zu sehen. Bei Arte HD hat man da perfektes Bild, auch bei den Einzelbildern, und sie haben auch noch auf 50 fps hochgedreht, d.h. es ruckelt auch weniger beim Schwenken. Das jetzt bitte auch noch für 3sat und Phoenix, dann bin ich zufrieden. Die anderen Kanäle brauche ich eh nicht. :-)
"Bad guys are encrypting their stuff now, so we need a methodology of hacking on that to try to break passwords," said C3 senior special agent Claude E. Davenport.Der Grund, wieso sie die PS3 benutzen, ist weil da Linux drauf läuft. Daher müssen sie auch die älteren Modelle nehmen.
So hatte ich vor einer Weile das Problem, dass auf meinem Notebook mein WLAN nicht mehr funktionierte. Das lag daran, dass der Intel-WLAN-Treiber anfing, eine Firmware hochzuladen, und dafür das Hotplug-Interface zu benutzen. Hotplug, das ist eine archaische Shellskript-Sammlung von Greg Kroah-Hartmann, in einem Shellskript /sbin/hotplug gipfelnd, das dann andere Shellskripte aus /etc/hotplug/* aufruft, und dort die eigentlichen Daten über magische Environment-Variablen übergibt. Nach einer Weile rumdebuggen habe ich damals rausgefunden, dass das Hotplug sich aus den magischen Environment-Variablen (der ganze Prozess ist m.W. nicht brauchbar dokumentiert) einen Pfad zusammenpopelt, und dann am Ende cp aufruft, um /lib/firmware/radeon/RV770_me.bin nach /sys/devices/platform/r600_cp.0/data zu kopieren. Welches cp das am Ende wird, das hängt von $PATH ab. Ich habe ein /usr/bin/cp, ein /bin/cp und ein /opt/diet/bin/cp, alle unterschiedlich. Mein /usr/bin/cp ist von GNU coreutils, und das meinte der Autor von hotplug wohl. /bin/cp ist ein Notfall-cp aus einer alten Version von embutils, falls ich /usr nicht mounten kann oder mir die glibc zerschossen habe. /usr/bin ist vor /bin im Pfad, daher betrifft das nie jemanden. /opt/diet/bin/cp ist das aktuelle cp aus embutils, das ist für meinen User noch vor /usr/bin im Pfad. Hotplug wird aber direkt vom Kernel aufgerufen und erbt daher das Environment von init. Und das hat das Default-Environment, das der Kernel setzt beim Aufruf von init, nämlich
PATH=/sbin:/bin:/usr/sbin:/usr/binAm Ende hat hotplug also das alte Notfall-cp aufgerufen, das in Blöcken zu 1024 Bytes kopiert. Versteht mich nicht falsch: alle dieser cp Binaries sind willens und in der Lage, eine Datei zu kopieren, und hotplug benutzt auch keine komischen GNU-only Flags. Aber das Firmware-Interface des Kernels hat damals Dinge angenommen, die nur GNU cp so gemacht hat. Ich habe die genauen Details vergessen, aber das Notfall-cp hat 1024-Bytes geschrieben, und der Kernel nahm an, dass die Firmware in nur einem Chunk geschrieben wird, und daher schlug das fehl.
Nachdem ich meine Fassungslosigkeit überwunden habe, habe ich damals /etc/hotplug/firmware.agent angefasst, damit er händisch /usr/bin/cp aufruft und nicht bloß cp über $PATH, und damit war das Problem gelöst.
Gestern habe ich jetzt anlässlich dieser Meldung hier den Kernel 2.6.32-rc6 auf meinem Desktop probiert. Mein Desktop hat kein WLAN und lädt an sich keine Firmware. Auf meinem Desktop ist auch seit irgendwann mal vorbeugend /bin/cp ein Symlink auf /usr/bin/cp. Um so größer war meine Überraschung, als mit dem neuen Kernel plötzlich X nur noch ohne Grafik-Beschleunigung hochkam. Nach einer Packung debuggen stellte sich raus, dass er die Firmware nicht laden konnte. Nachtigall, ick hör dir trapsen, dachte ich mir, und prüfte, ob /bin/cp das richtige ist. War es. Mhh, nanu. Ich habe also geprüft, ob hotplug das richtige cp aufruft. Tat er, /usr/bin/cp. Komisch. Weiter debugged. Mal ein strace auf /usr/bin/cp gemacht. Und, was soll ich sagen, /usr/bin/cp kopiert bei mir in 32k-Blöcken. Mein embutils-cp benutzt hingegen mmap und kopiert in 4 MB Blöcken. Also habe ich /etc/hotplug/firmware.agent angefasst, damit er /opt/diet/bin/cp aufruft, und was soll ich euch sagen, jetzt ist mein X wieder beschleunigt.
Nur damit ihr mal seht, auf was für einem Treibsand-Fundament dieses Linux gebaut ist.
Wobei wahrscheinlich ich über drei Ecken Schuld bin. Mein coreutils ist Version 7.6, das ist AFAIK aktuell, aber meine hotplug-Shellskripte sind von 2006. Vielleicht gibt es da ein Update inzwischen.
Aber die Ironie, dass dieses Firmware-Interface so verstrahlt ist, dass es erst mit dem Fefe-cp nicht tat, und jetzt mit dem GNU-cp nicht tut, und ich es fixen kann, indem ich das Fefe-cp benutze, das ist schon grotesk. Freut euch alle, dass ihr solche Details nicht sehen könnt bei euren Distributionen. Und, falls das hier jemand liest, der für das Firmware-Laden-Interface im Kernel verantwortlich ist: SCHANDE! SCHANDE! SCHANDE!!
Update: hotplug ist seit Jahren obsolet und sollte ja eh nicht mehr installiert sein, weil es durch udev abgelöst wurde, was ich ja auch installiert habe. Nur leider hat das Vorhandensein von udev bei mir nie dazu geführt, dass der Kernel nicht trotzdem hotplug aufruft. Jetzt habe ich einige Zuschriften gekriegt, die mir erklärt haben, dass man beim Booten
echo > /sys/kernel/uevent_helpermachen muss. Nun starte ich ja beim Booten den udevd, und hätte mir gedacht, hey, wenn ich den da schon starte, dann ist der bestimmt auch so smart, obiges zu tun. Ist er aber nicht.
I call the resulting codes "maximally embarrassing" since each function represents some significant failure to optimize.Und das übelste Beispiel, das sie bisher gefunden haben, ist:int ZZ_00005bbd(int x,int y){return m1s((x?0:x),a8s(y,y));}wobei m1s ein signed 16-bit multiply ist und a8s ein signed 8-bit add. Die Funktion sieht für meinen Geschmack schon mal nicht sehr offensichtlich aus, aber guckt sie euch genauer an. Der (x?0:x) Teil ist immer Null, hier wird also Null mal irgendwas gemacht, da kommt immer Null raus. gcc erkennt das und erzeugt Code, der konstant 0 zurück liefert. Wow.Update: Meine Folien machen gerade die Runde im Internet, und sind sowohl bei Lambda the Ultimate als auch bei Mike Melanson (der bei Adobe für das Portieren des Flash-Plugins nach x86_64-linux zuständig ist). Wow. :-)
Usually I make sure that my slides contain everything said at the actual talk, so they are useful on their own if there is no video of the talk, but in this case I had way more slides than I could possibly cover in the allotted time, so I left things out. Basically, the gist was that for normal programming tasks, people should not waste time on doing optimizations that the compiler is already doing for them, or should be doing for them. And, in particular, I wanted to demonstrate that doing integer overflow and range checks can be free in some cases or almost free in the others. Performance is not a valid excuse to not do range checks and then create security vulnerabilities.
In the slides, I basically say that for many cases the compiler is actually smarter than the programmer, and this is true, but it may have offended the handful of people for which it is not true. So let me state here: yes, some people are smarter than the compiler. The probability that you are one of those people or that you even know one of those people is very small. :-)
Nun ist das im Moment ein Proof of Concept. Das heißt noch lange nicht, dass jemand Wikipedia forkt, oder dass ein Fork sinnvoll wäre, zumal man ja weiterhin bei MediaWiki bliebe, wo sich ja an sich alle einig sind, dass das keine gute Basis für eine moderne Wikipedia ist.
Aber git ist schon mal die richtige Basistechnologie, auf der man sowas aufsetzen wollen würde.
Auf die Gefahr hin, mich als uninformierter Tourist zu outen: Dresdens Innenstadt ist beeindruckend, und nicht nur die Frauenkirche, auch drum herum haben die Dresdner echt was gerissen. Wer noch nie in Dresden war und sich für schöne alte Architektur interessiert, dem kann ich Dresden echt empfehlen.
Oh und wer das Chaosradio gestern nicht gehört hat, der sollte sich mal den Mitschnitt runterladen und anhören. Da gab es einige Überraschungen, z.B. als der Wikipedia-Admin da erzählte, dass ihm ja auch schon alle möglichen Artikel weggelöscht wurden, und dass ihn das geärgert hat, und dass alle möglichen Mitmach-Kennwerte wie Anzahl der Autoren, Anzahl der Admins und Anzahl der neuen Artikel rückläufig seien. Da fehlt also nicht mehr viel, bis die Wikipedianer da mal 2 und 2 zusammenzählen an der Stelle.
Ich sollte mal bei den Popcornherstellern meine Provision einfordern. Die habe ich gerade auf Jahre saniert, glaube ich.
Ansonsten gucken wir gerade, ob wir das nächste Chaosradio zur Wikipedia machen. Ich kann da aber leider nicht mitmachen, weil ich auf dem Weg zum Linux-Kongress in Dresden bin am 28. Aber egal ob es da um Wikipedia geht oder nicht — da lohnt sich das Zuhören grundsätzlich!1!!
Bei Kris gibt es noch ein paar lesenswerte Gedanken zur Wikipedia.
Oh und wer die Löschdiskussion noch nicht gelesen hat: die ist deutlich lesenswerter als der umstrittene Blogeintrag :-)
Update: Kurze Erklärung vom Wikipedia-Admin "avatar":
Das Wort "frei" im Titel der Wikipedia bezieht sich hingegen nur auf die verwendete Lizenz.
Das hätten sie vielleicht vor ihren Spendenmarathons mal ansagen sollen.
Nun macht sich der eine oder andere sicher Sorgen, ob man denn Truecrypt jetzt noch einsetzen kann.
Ich würde mir da ehrlich gesagt nicht so viel Sorgen machen, denn auf der Liste der NSA-affiliated IP ranges sind auch Institutionen wie das MIT (da kommen Kerberos und X11 her), MCI/Verizon/UUnet, die Mercedes Benz AG, Microsoft, Myspace, Nacamar (?!?), Cogent, Princeton University, Qwest, das RIPE NCC (harhar), Savvis, Schlund und Partner AG, Sprint, Tiscali, Telecom Italia, Telefonica (denen gehört u.a. Hansenet), Telekom Austria, Telia, Telstra, T-Mobile Ungarn, T-Online Frankreich und Ungarn, Versatel, Wanadoo, den Weather Channel (hahaha), XS4ALL, Yahoo, Youtube, oh und Level 3. Wenn ihr jetzt mal ein Traceroute zu einem beliebigen Open Source Projekt im Internet macht, kommt ihr mit großer Wahrscheinlichkeit bei Cogent, Telia, Sprint, Savvis oder Level 3 vorbei. Ein Traceroute von mir zuhause zu Sourceforge geht z.B. durch Telia und Savvis. Ein Traceroute zu ftp.gnu.org geht durch Cogent. Oh und auch die Route zu cryptome.org geht für mich über telia und savvis. :-)
Jeder Linux-User benutzt X11, jeder Windows-User benutzt Kerberos, und Microsoft ist ja eh auf der Liste.
Wer sich also Sorgen macht, der kann sich ja die Truecrypt-Sourcen mal in Ruhe angucken. Deshalb kommt Truecrypt ja mit Sourcen.
Update: Im Übrigen möchte ich mal aus einem Chat zitieren:
<Fefe> truecrypt ist jetzt nsa-unterwandert!1!!
<Andreas> Fefe: "jetzt"?
<Fefe> Andreas: wie, war schon immer NSA-unterwandert?
<Andreas> Fefe: Natürlich!!1!
* Andreas hat keine Beweise, aber das zeigt ja schon, wie gut die bei der NSA sind!!
In diesem Fall hat der Hersteller zwar eine Open Source Linux Software als Basis genommen, aber tut eine zweite Passphrase dazu, die dann leicht verschleiert im Flash steht.
Und weil man sowas bei kommerziellen Produkten nicht sehen kann, außer man reverse engineered sie, sollte man sowas selber machen. LUKS ist schon keine schlechte Basis für Platten-Krypto.
ACPI Warning (tbutils-0246): Incorrect checksum in table [OEMB] - EA, should be E8 [20090320]BIOS-Update brachte auch nichts.
--- a/fs/cifs/connect.cOhne das jetzt näher untersucht zu haben: so sieht ein Fix für einen Remote Buffer Overflow im SMB Filesystem aus. Wer also CIFS benutzt — updaten. Jetzt. Und warum sagen sie das nicht dazu? Weil, äh, das ja den Bösen verraten würde, wo sie gucken müssen. Was für eine Farce. Die Bösen gucken eh, aber die anderen sind jetzt nicht mehr informiert, die normalen User.
+++ b/fs/cifs/connect.c
@@ -3667,7 +3667,7 @@ CIFSTCon(unsigned int xid, struct cifsSesInfo *ses,
BCC(smb_buffer_response)) {
kfree(tcon->nativeFileSystem);
tcon->nativeFileSystem =
- kzalloc(length + 2, GFP_KERNEL);
+ kzalloc(2*(length + 1), GFP_KERNEL);
if (tcon->nativeFileSystem)
cifs_strfromUCS_le(
tcon->nativeFileSystem,
Nicht mal Multiplikatoren wie Heise, die dediziert über neue Kernel berichten, und eine eigene Security-Abteilung beschäftigen, fällt sowas jetzt auf. Ganz toll, Linuxer, ganz toll.
Ich bin ja sowieso zunehmend genervt von Linux. Ich habe heute einen Nachmittag mit Bluez verschwendet. Alles was ich tun wollte: ein paar JPEGs von einem Mobiltelefon ziehen. Ist offenbar zuviel verlangt. Höhepunkt war, dass der bluetoothd kommentarlos an einem SIGSEGV verstarb. Nach dem Fork und dem "alles OK" im syslog, natürlich.
Dann war da neulich diese Email-Debatte, die ich mit den Netzwerk-Spezialisten geführt habe, weil die ein Fehlverhalten in bind() mit IPv6 nicht fixen wollten. Nein, da linke ich jetzt nicht drauf. Könnt ihr ja selber googeln, wenn ihr es sehen wollt. Lächerlich, wie im Kindergarten.
Ich glaube ja so langsam, Linux muss mal jemand forken. Oder gleich ganz neumachen. So geht das jedenfalls nicht weiter.
Und fragt mich gar nicht erst nach meiner Meinung zu D-Bus. *göbel*
Update: Heise hat das aufgegriffen und ich habe dann auch mal den Bug ein bisschen erklärt im Heise-Forum.
What makes this document fascinating is that it contains both the original and modified text (in glorious colour, so it's really worth downloading it and taking a look), which means that we can see what exactly an organisation sympathetic to Microsoft – and partly funded by them – is worried about, and how it is trying to head off the threat.Hochspannend!
Bei C++ kann man z.B. Boost nehmen, oder die C++ Runtime von gcc hat auch atomare Operationen in ext/atomicity.h.
Das Problem bei Windows war, dass man da einen AcceptEx-Call mit overlapped I/O losgetreten hat, und der eine Call nahm dann halt eine Verbindung an, und signalisierte erst, wenn der was schickte. Wenn jetzt aber jemand eine Verbindung aufbaute und nichts schickte, dann nahm der Server gar keine Sockets mehr an. Kurz gesagt: ein dummes Denial of Service.
Nun, Linux hat auch sowas:
int one=1;Das habe ich irgendwann gesehen, in libowfat abstrahiert, und dann in gatling eingebaut. Und jetzt stelle ich gerade fest, dass die Linux-Implementation ein sehr ähnliches Problem hat. Nur halt dass nicht ein Socket für das DoS ausreicht.
setsockopt(sockfd,IPPROTO_TCP,TCP_DEFER_ACCEPT,&one,sizeof(one));
Ich habe da gerade eine Stunde rum debuggt (weil ich auch in meinem libowfat-Code gerade herum experimentiere und erst dachte, ich hab dabei was kaputt gemacht), bis ich beim Blick auf netstat gesehen habe, dass da 16 Verbindungen im SYN_SENT bzw SYN_RECV Stadium waren (SYN_SENT beim Client und SYN_RECV beim Server, liefen auf der selben Kiste hier), und ein Socket im SYN_SENT ohne dazu gehöriges SYN_RECV. 16 ist genau das Limit, das ich bei listen() als Backlog übergeben hatte. Die Verbindungen zählen also als "halbe Verbindungen", die man aber nicht annehmen kann; vom Problem her mit einer Syn Flood verwandt.
Und da fiel es mir wie Schuppen von den Augen. Das Linux-API ist gut gemeint aber ist in Wirklichkeit ein DoS gegen sich selbst, zumindest in der aktuellen Implementation in 2.6.27. Zu allem Überfluss wird das DoS auch noch von meinem eigenen bei gatling beiliegenden Benchmark-Tool getriggert. Ich hatte gedacht, dass mal bei früheren Versionen getestet zu haben, aber habe keine Aufzeichnungen und bin mir auch gerade nicht mehr sicher. Im Moment ist jedenfalls klar: vor dieser Funktionalität kann ich nur warnen. Benutzt das nicht in eurer Software!
Danke an Johannes, der mich überhaupt erst auf das Problem hingewiesen hat.
TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1Und dann ist Schluss. BIOS ist schon das aktuelle. Gestern gings noch. Weder Hardware noch Kernel geändert. Scheisse.
Bisschen Googeln legt nahe, mal "nolapic_timer", "noapic" und/oder "nolapic" zu probieren als Bootoptionen. Damit bootet er dann zwei-drei Zeilen weiter und hängt dort.
Und natürlich passiert sowas am Samstag Abend, nachdem die Läden geschlossen haben. Und wo ich Montag früh für 5 Tage in Hamburg bin.
Sachdienliche Hinweise, was man aus dieser Fehlerbeschreibung über das Problem sagen kann, werden gerne genommen.
Die Theorie bei MCE ist, dass der Fehlercode nach einem Reset-Knopf-Einsatz noch lesbar ist, d.h. man startet dann ein Dekoder-Tool, und das dekodiert einem die Nachricht. Habe ich getan, hat nichts gefunden. Also doch kein MCE? Ich habe also einen älteren Kernel gebootet, und mit dem kriege ich plötzlich ein paar richtige MCE-Meldungen. Das ist ein Hex-String der Form
CPU 0: Machine Check Exception: 4 Bank 0: b200004000000800Und wenn man das durch das Decoder-Tool laufen lässt, kommt folgendes dabei raus:
CPU 0 BANK 0 MCG status:MCIPIch weiss nicht, wie euch das geht, wenn ihr das lest, aber ich brauche für diesen Decoder noch einen Decoder. Ist das jetzt ein RAM? Die CPU? Das Mainboard? Hach, Computertechnik ist schon was tolles. Und wahrscheinlich lohnt es sich angesichts der aktuellen Hardwarepreise auch gar nicht, da gross rum zu debuggen. Seufz.
MCi status:
Uncorrected error
Error enabled
Processor context corrupt
MCA: BUS Level-0 Originated-request Generic Memory-access Request-timeout Error
BQ_DCU_READ_TYPE BQ_ERR_HARD_TYPE BQ_ERR_HARD_TYPE
timeout BINIT (ROB timeout)
STATUS b200004000000800 MCGSTATUS 4
-#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))Wer den auf Anhieb versteht, sollte sich direkt erschiessen, weil er zu viel C gemacht hat.
+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) \
+ + sizeof(typeof(int[1 - 2*!!__builtin_types_compatible_p(typeof(arr), \
+ typeof(&arr[0]))]))*0)
Für die anderen erkläre ich es kurz.
ARRAY_SIZE hat vorher die Anzahl der Elemente im Array zurück geliefert, und tut es auch danach. Man sieht, dass der Patch einen komplizierten Ausdruck *0 addiert, also immer Null.
Der einzige Sinn des komplizierten Ausdrucks ist, einen Compile-Zeit-Fehler zu produzieren, wenn __builtin_types_compatible_p 1 zurück liefert. Wenn da 0 rauskommt, macht er zweimal !, das logische NOT, d.h. wieder 0, mal 2 bleibt null, und er hat ein Array der Größe 1, das ist in Ordnung. Wenn da was anderes als 0 rauskommt, macht er zweimal !, d.h. 1, mal 2 ist 2, und damit ist die Arraygröße -1, d.h. negativ, und es ergibt einen Compile-Zeit-Fehler.
Anders formuliert: der Patch ändert das Makro so, dass es zur Compilezeit in die Luft fliegt, wenn man einen anderen Typen als ein Array übergibt, bei dem trotzdem [0] erlaubt ist, also mit anderen Worten einen Pointer.
Kleiner Insider-Joke: früher hat man das ohne 2* gemacht, da war es nämlich in C nicht erlaubt, ein Array mit Null Elementen zu deklarieren. Das hat sich kürzlich geändert, daher steht da jetzt 2*.
Wer das furchtbar findet, sollte von C++ weiträumig Abstand halten.
Der Autor des Hacks ist übrigens Rusty Russell, der u.a. an den module_init_tools und netfilter Verantwortung trägt.
Oh übrigens: __builtin_types_compatible_p ist eine gcc-Erfindung.
The new technology platform has been developed using the Microsoft .NET Framework, with support from Microsoft and AccentureDa haben sich ja die richtigen Technologien und Leute zusammen gefunden…Update: Die Betreibergesellschaft sagt, es war das Netz, nicht die Software. Halte ich für unwahrscheinlich, denn 1. dauert in solchen Fällen die Reparatur keine 7 Stunden, und 2. hat man gerade in solchen Setups alles mehrfach redundant am Start. Besonders peinlich ist ja, dass Microsoft fett damit Werbung gemacht hat, die Londoner Börse habe wegen der Zuverlässigkeit Windows statt Linux gewählt. Bwahahahaha
Oh und der verschwörungstheoretische Aspekt ist auch nicht zu verachten: das war der Tag, wo die Amis Fannie Mae und Freddie Mac verstaatlicht haben.
Also bin ich losgelaufen und habe mir eine neue geholt, und da hat das beste Preis-Leistungs-Verhältnis im Moment ATI (und abgesehen davon wären ja alle aktuellen Nvidia-Karten betroffen, was bleibt da schon groß übrig außer ATI).
Unter Linux supported der fglrx-Treiber das wohl, aber der kompiliert nicht mit 2.6.26. Der Open Source Treiber xf86-video-radeon aus dem git supported das so halb, wenn man die PCI IDs manuell reinpatcht. Dann kriegt man Bild, aber nur mit einer Auflösung von 1156x768 (!?!?). Ist mir völlig unklar, wo dieser Wert herkommt, jedenfalls nicht aus einer Modeline oder gar einer Auflösungs-Konfiguration fürs Display. Schlimmer noch: wenn ich ein Video mit xvideo abspielen will, ranzt X ab. Das sind echt mal wieder Zustände…
Immerhin tut die Karte unter Windows. Nur wer will schon unter Windows arbeiten. ATI-Treiber sind und bleiben halt Sondermüll.
Update: fglrx habe ich aufgegeben, aber inzwischen funktionieren radeonhd und ati aus dem git mit der nativen Display-Auflösung, aber leider beide ohne xvideo.
Option "AccelMethod" "EXA"in der Device-Section im xorg.conf. Ist auch im gerade heraus gekommenen Xserver 1.4.2 noch kaputt in XAA.
Die Release-Version von xf86-video-ati kann noch kein xvideo, da müsst ihr euch wie folgt einen Snapshot holen:
git-clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-atiund den dann halt kompilieren. Die haben wohl in einem Developer-Tree auch schon halb-funktionierendes 3d, aber das interessiert mich ja ehrlich gesagt überhaupt rein gar nicht unter Linux.
Falls jemand die ATI-Serienbeschreibungen nicht kennt: R500 ist die X1*00 Serie, wie z.B. in meinem Fall X1600 mobility.
Update: Mhh, auf Bluehat hatten sie da Screenshots gezeigt, wo man Fotos mit hunderten von Skimmern sah. Die Seite ist bei mir zumindest eher enttäuschend gerade. Aber gut, falls jemand nicht weiß, was das ist: die Verkaufen die Kits, mit denen man Geldautomaten manipuliert, so dass die eingesteckten Kartendaten ausgelesen werden.
Gestern abend kam mir dann die Idee, in mein cp aus den embutils einen Switch einzubauen, dass er die Zieldatei mit O_SYNC öffnet, und wenn man das benutzt, kriegt man genau den Durchsatz, wie man ihn erwartet hätte. Ich checke das mal die Tage ins cvs ein.
Kurzer Hintergrund: Bei x86 (und AMD64) gibt es String-Instruktionen, die z.B. ein Byte lesen und das Indexregister dann auch gleich hochzählen. Wenn das Direction Flag gesetzt ist, zählen sie dann halt nicht hoch sondern runter. Wenn man memcpy mit den String-Instruktionen implementiert, kriegt man dann Speicherkorruption.
Die Geschichte ist jetzt offenbar ein paar Leuten unter Linux aufgefallen, und natürlich gefunden von LISP-Leuten. Ich könnte mich ja immer nur endlos über die LISPer amüsieren. Aber hey, in unserer Gesellschaft ist auch Platz für Archäologen :-)
| Server capacity at breaking point | |
|---|---|
| OS | Queries/second |
| Linux Gentoo 2.6.20.7 | 93,000 |
| Linux Fedora Core 2.6.20.7 | 87,000 |
| FreeBSD-7-CURRENT 200708 | 84,000 |
| FreeBSD-6-stable 200708 | 55,000 |
| FreeBSD 6.2-RELEASE | 51,000 |
| Solaris-10 DevelExpr 5/07 | 50,000 |
| NetBSD-4.0-Beta 200708 | 42,000 |
| OpenBSD 4.1-snap-20070427 | 35,000 |
| Windows 2003 Server | 22,000 |
| Windows XP Pro64 5.2.3790 SP2 | 20,000 |
Nicht sonderlich Überraschend, wie ich finde. (Danke, Oliver)
Interessant an der Sache: sie suchen explizit Leute mit Unix/Linux-Kenntnissen. Aber ich mache mir da ehrlich gesagt wenig Sorgen. Sie suchen nur Leute mit Uni-Abschluß und das soll in C/C++ gemacht werden. Meiner Erfahrung nach muss man sich bei der Schnittmenge daraus keine Sorgen machen, dass das Projekt jemals fertig wird oder gar funktioniert.
Update: Die haben auch in der FAZ inseriert. Ich frage mich ja, was die glauben, welcher FAZ-Leser mit deren Gehaltsvorstellungen (11 TVÖD) zufrieden wäre. (Danke, Henner)
Bemerkenswert an dem Angebot sind folgende Details:
Ohne irgendwas davon mal in Aktion gesehen zu haben, maße ich mir mal folgende Glaskugel-Aussagen an:
Update: noch was vergessen: die verkaufen der Polizei auch gleich zwei (!) Proxy-Server zum Verschleiern der IPs. Zwei! Das finde ich bemerkenswert. Hat wohl doch mal jemand aufgepaßt bei unseren Tor-Vorträgen :-)
Soweit die Theorie. In der Praxis gibt es verschiedene Ansätze, wie man damit am besten umgeht. Ich habe das Problem in Hardware gelöst, indem ich USB-TV-Grabber mit eingebautem Audio-Sampling gekauft habe, so dass Video und Audio die selbe Taktquelle haben und es keine Sync-Probleme gibt. Nur leider stellt sich heraus, dass mencoder da trotzdem Sync-Probleme herbei halluziniert und alle paar tausend Frames einen Frame dupliziert. Nach zwei Stunden hat man da eine halbe Sekunde Unterschied zwischen Audio und Video.
Gut, dachte ich mir, löse das Problem mit dem Holzhammer, nimm Audio und Video separat auf, dann gibt es da keine Differenzen, die mencoder ausgleichen müsste. Doch weit gefehlt, selbst mit -nosound dupliziert mencoder Frames. Ich könnte kotzen. Jetzt habe ich meinen mencoder gepatcht, damit er auf Zuruf das Fummeln an den Frames läßt, und nehme damit ein paar Stunden lang arte auf, um zu gucken, ob das damit in sync bleibt. Moan ey, wie schwer kann das denn eigentlich sein alles? Offenbar benutzt mencoder da tatsächlich völlig sinnlos auch die PC-Systemzeit mit, die alles andere als zuverlässig ist und vor allem zum Aufnehmen von Video überhaupt gar keine Rolle spielen sollte. Ich erwähne nur mal am Rande "ntp". Laut man-Page müsste man das mit "-mc 0" ausschalten können, aber ich konnte da keine Verhaltensänderung feststellen.
Und falls jetzt jemand sagt, nimm halt was anderes als mencoder: der Treiber ist offenbar weitgehend im Eimer und funktioniert nur mit mencoder. vlc sagt
vlc: [00000272] v4l demuxer error: mmap unsupportedffmpeg sagt
[video4linux2 @ 0x2b068eec8040]The v4l2 frame is 614400 bytes, but 460800 bytes are expectedstreamer (von xawtv) sagt:
setformat: 16 bit YUV 4:2:2 (planar) (640x480): failedDie SVN-Version von vlc segfaultet direkt, noch vor dem Öffnen des Fensters, mit einer glibc-"der Heap ist korrupt"-Meldung.
Insofern habe ich mich sehr gefreut, dass mein Kumpel eRdgEiSt seinen opentracker auf Basis von libowfat geschrieben hat. Damit haben sie dann einen fetten öffentlichen Torrent-Tracker aufgesetzt, und der hat auch kräftig Skalierbarkeit demonstriert. Wir waren alle stolz auf uns. Aber der heilige Gral war es noch nicht. Der heilige Gral ist der größte Torrent-Tracker der Welt. Und, was soll ich euch sagen, jetzt ist es offiziell: PirateBay steigt auf Opentracker um. Im Moment läuft auf vier ihrer Tracker der Opentracker (der öffentliche Torrent-Tracker meiner Kumpels läuft unter BSD, das ist halt der Vorteil eines schönen Abstraktionslayers, das würde z.B. auch unter Solaris gut laufen, und beim PirateBay läuft es unter Linux) und frühstückt da 17000 Hits pro Sekunde ab mit vier Trackern, verteilt auf sieben Rechner (die benutzen da DNS Round Robin zur Lastverteilung). Ja, das ist ein bewegender Moment für mich, und ich gratuliere eRdgEiSt zu seiner coolen Tracker-Software.
SMB unterscheidet sich von HTTP dadurch, dass man große Dateien in vielen Blöcken zieht, d.h. ein Request pro 64k (oder gar nur 16k oder noch weniger), nicht pro Datei. Das Verhalten sieht im strace so aus, dass der Server die Daten rausschreibt, und dann 200 ms warten muss, bis der nächste Request reinkommt. Im Sniffer sieht man, dass der Client immer 200 ms warten muss, bis die Antworten reinkommen. Ich benutze unter Linux den TCP_CORK setsockopt und schalte auch Nagle aus. Nagle ist der übliche Grund für solche Pausen, und wenn ich am Ende der Antwort TCP_CORK auf 0 setze, müssten laut man tcp die Daten auch sofort rausgehen. Tun sie aber nicht.
Interessanterweise ist das Problem nur auf localhost, über Ethernet kriege ich fetten Durchsatz.
Mhhhh. Das ist das Problem, wenn man immer so esoterische Performance-Tweak-APIs benutzt, das funktioniert dann halt manchmal nicht.
Der interessanteste Teil daran ist, dass das bei mir zuhause auf dem Desktop funktioniert, selbe Kernelversion, ebenfalls AMD64.
Daher jetzt hier der Aufruf an die Bastler. Wer hat sowas auch schon mal gemacht? Welche Hardware kommt in Frage? Hier gibt es eine Übersicht der Plaste-Consumer-Geräte, auf denen Leute schon Linux aufgespielt haben.
CPU-Performance wäre mir weitgehend wurscht, solange ich das Gigabit Ethernet saturiert kriege, wenn die Daten im Buffer Cache waren. Aber wenn es so nen Quad Core 2 GHz MIPS64 für nen Appel und nen Ei irgendwo gäbe, würde ich auch nicht nein sagen :-)
Update: Mhh, bei Dell und Sony müsste man da sogar noch Geld raus kriegen unterm Strich, so viel überflüssige Gülle wie die da vorinstallieren…
Leute, wer obiges nicht selber erklärend und der expliziten Ansage nicht würdig findet, der soll bitte weg gehen und sich professionelle Hilfe suchen. Ich bin Hacker, keine Nervenheilanstalt.
Bei einem Update habe ich mir mal gcc-config geupdated, und plötzlich war gcc richtig doll langsam. Einfach nur gcc ohne Argumente aufrufen dauert plötzlich 0,6 Sekunden. WTF? Ich habe also mal ein strace gemacht, um zu gucken, was der da alles aufruft, und haltet euch fest:
Na gut, denke ich mir, guck ich mal in NEWS rein, das ist ja genau die Datei, wo man sowas erwähnt. Was steht da? Gar nichts zum Code in elf oder dem dynamischen Linker. Naja, wäre ja keinen Blog-Eintrag wert, es weiß ja jeder, was für ein Pfuscher das ist, aber dann fand ich das hier von 2004, und da fordert er ja explizit darauf auf, daß man anderswo über ihn meckern soll, und gerne dafür Blogs aufmachen soll. Nun, dafür ist er mir zu unwichtig, daß ich da noch nen Blog aufmachen würde für, aber hey, he had it coming. Ulrich Drepper ist für mich der Anti-Programmierer, der kann noch weniger als dieser Python-Schnösel oder dieser Ruby-Knallkopf. Ich traue den Kerberos- und X11-Leuten mehr Sachkenntnis zu als ihm. Wenn ich einen nennen sollte, der Linux am meisten schadet, ich müsste nicht lange nachdenken. Und bei Redhat ist der Mann auch prächtig aufgehoben, die haben sich gegenseitig verdient.
Hach wie ich das hasse, anderer Leute Bugs fixen zu müssen.
Update: das Problem ging bei mir weg, als ich in sysdeps/i386/i486/bits/atomic.h die Zeile
#if __GNUC_PREREQ (4, 1)gegen
#if __GNUC_PREREQ (4, 2)tauschte. Saubere Qualitätssicherung, Jungs, das habt ihr wirklich prima gemacht. Pah, wenn man eine neue libc rausbringt, warum sollte man da schon prüfen, ob das mit dem aktuellen gcc funktioniert. Wo kämen wir da hin. Linux muss spannend bleiben!
Aber wartet, kommt noch besser! Die Testsuite fällt auf die Fresse. Fehlermeldung:
iconv_prog: malloc.c:2575: do_check_chunk: Assertion `((char*)p) < min_address || ((char*)p) > max_address' failed.Hach, prima!
Peter Ganten vom Linux-Verband sieht in der Entwicklung einen herben Rückschlag für die Verbreitung freier Software. Vor allem kritisiert er aber die Vergabepraxis. "Andere Hersteller hatten keine Möglichkeit, sich für das Groupwaresystem des Bundestages zu bewerben. Es gab keine Ausschreibung, wie sie für jede Verwaltung Pflicht ist", haderte er gegenüber süddeutsche.de.
mplayer mms://213.254.239.51/tagesschau/msmedia/2007/0607/TV-20070607-1654-4901.wm.hi.wmv
kill_me_if_I_do(ACT_FORK|ACT_CLONE|ACT_PTRACE|ACT_KILL|ACT_EXECVE|Der wichtige Teil ist, daß dieser Prozeß nicht privilegiert ist, der läuft nicht als root, der läuft als User "smtpd". Selbst wenn der das nicht macht, darf der eh nur ptrace auf andere Prozesse machen, die als smtpd laufen. Ich will diesem Prozeß keinesfalls die Möglichkeit geben, in der System-Policy-Datenbank herum zu schreiben. Aber der soll für sich selbst freiwillig (und nicht rückgängig machbar) sagen können: wenn ich fork oder execve aufrufe, erschieß mich.
ACT_SOCKET|ACT_MKNOD|ACT_MOUNT);
I disagree. Saying you can either crash or get owned is a false dilemma.Crashing instead of getting owned does not help the customer, because he can still lose his data. He won't get a worm (unless you missed some other wormable issue), but still, that's just reducing the severity from "critical" to "moderate". It's still a bug. The customer still wants it fixed. The only one who has an actual advantage of this is you, because you only have to answer for a DoS, not a worm.
So my point of view is: crashing if you detect an error is a cop out, an ass covering mechanism big companies like to use, because it's easier to crash than to implement error handling.
Similar issue: using try/except to catch AVs and then pop up a window saying "uh, that Word file smelled funny". That is not error handling, that is ass covering.
Security is never simple. Security is work. Yes, you will actually have to do something to make your code more secure. Just adding a try/except or SafeInt band-aid does not make the product more secure, it's just ass covering. Why am I paying $500 for a piece of software that does not even really try to be secure but just applies some ass covering filter?
I'm not just ranting about Windows here, btw. Linux has limited the size_t arguments to read() and write() to below 2 gigs, because some crappy kernel code might use signed ints for lengths, and then it would blow up. O RLY? That's not security, that's just ass covering. And coming from the GNU people who used to distinguish their software from other Unix software by removing arbitrary limits.
This attitude is pervasive in the software industry, and I hate it. Also because you will do the work twice. First you will apply a band-aid, then someone will find a way around your band-aid, or someone will notice that a crash during trying to save a document can destroy data and is just as bad for the customer, and you will have to fix it again, this time for real.
Und falls noch jemand Zweifel an der vollständigen Inkompetenz dieses Ziercke-Menschen hat: sie wollen den Trojaner ohne Ausnutzung von Schwachstellen installieren, und sie wollen den Quellcode "einer solchen Untersuchung" beim Gericht hinterlegen. Der Mann weiß ja sowas von GAR NICHT, wovon er redet, das ist echt unfaßbar.
Ich kann euch ja mal sagen, was ich glaube, wie das funktionieren wird jetzt. Das BKA wird irgendeine studentische Hilfskraft dafür bezahlen, einen superschlechten Visual Basic Trojaner zu hacken, und wird den dann auf de Rechner installieren, indem sie einbrechen und einen USB-Stick in die Hardware schieben. Vermutlich werden sie eine Knoppix-CD dabei haben, damit sie an den Rechner rankommen. Wenn also jemand (wie ich) seinen Rechner ganzzeitig laufen läßt, und auch noch unter Linux, dann sieht man das ganz gut, ob da jemand dran war, weil die Uptime ruiniert ist. Abgesehen davon, daß die dann bei whole disk encryption verkackt haben. Wobei sich natürlich die Frage stellt, wieso sie nicht einfach ne Wanze in die Tastatur einbauen.
Update: Der Treiber selbst funktioniert zwar, aber die Ausgabe ist pink statt weiß und stark verrauscht. Seufz.
glibc installiert seine Header in /usr/include, und hat verschiedene Header für x86 und x86_64. Man kann aber gcc mit -m32 aufrufen, und dann kompiliert er für x86. Leider benutzt er dann immer noch /usr/include. In den meisten Fällen ist das OK, aber manchmal eben nicht, wie z.B. beim Java-Runtime von gcc. Nun hat gcc einen Override-Mechanismus für sowas. Z.B. included er vor /usr/include noch seinen Override-Pfad /usr/lib64/gcc/x86_64-unknown-linux-gnu/4.1.1/include (bei mir). Nun, leider ist auch dieser Pfad der selbe bei -m32.
gcc hat einen Mechanismus, um sowas zu fixen. Man kann ein specs-File erzeugen. Früher hat gcc das mitgeliefert, heute ist das built-in. Man kann das trotzdem noch extrahieren (ruft mal "gcc -dumpspecs" auf, um euch den Horror mal zu geben) und irgendwo geschickt platzieren, aber … wir haben 2007. Liebe gcc-Leute, das ist unter aller Sau. Fixt das mal. Und wenn die glibc-Deppen nicht pro Plattform andere Includes hätten, wäre das auch alles kein Problem. Das liegt im Übrigen u.a. daran, daß glibc die Kernel-Header included. Ich habe das am Anfang auch gemacht bei der dietlibc. Linus himself hat mir dann eine Mail geschrieben, daß ich das nicht machen soll, weil das nur Probleme macht, und hey, rückblickend hatte der Mann sowas von Recht… tja, nur bis zur glibc hat sich das noch nicht rumgesprochen.
Wenn ihr eine 64-bit Distribution fahrt, dann guckt euch mal an, wie die das regelt. Gentoo hat da echt einmal den Hazmat-Anzug angezogen und ein Konstrukt namens "multilib" gebaut. Auf meinem Gentoo-Testsystem sieht z.B. /usr/include/wchar.h so aus:
/* Autogenerated by create_ml_includes() in multilib.eclass */Na, ist das nicht wi-der-lich? Danke, liebe glibc, daß ihr Linux so effektiv kaputt gemacht habt. Nicht einmal offene Eiterwunden wie X oder Samba sind je so tief gesunken.#ifdef __i386__
# include
#endif /* __i386__ */#ifdef __x86_64__
# include
#endif /* __x86_64__ */
Oh, noch nen Nachschlag für die Variante mit dem "specs"-File: wenn ich das anfasse, und da z.B. folgendes bei cpp_options reineditiere:
{m32:-isystem /usr/include32}dann hängt mir das natürlich auch beim dietlibc-für-x86-Kompilieren /usr/include32 in den Pfad und macht alles kaputt. Ihr seht schon, wieso Gentoo diese Würg-Lösung gewählt hat.
Applications such as Internet Explorer have been tightly integrated with Windows and given administrator access control privileges, providing an intruder access to the entire system if the application is compromised via a security flaw.Ja, meine Damen und Herren, SO TIEF ist Suse gesunken, daß sie jetzt in ihrer Werbung nicht nur die Konkurrenz bashen müssen, anstatt auf ihre eigenen Stärken hinzuweisen, nein, sie sehen sich dabei auch noch zum Lügen gezwungen. Für mich sieht das aus wie ein Gerichtsverfahren in naher Zukunft. Und das fällt gleich negativ auf Linux zurück, soviel steht ja schon mal fest.
Damit ist er jetzt offziell noch beschissener als der Linux-Treiber, der mir folgendes mitteilt und dann den Dienst einstellt:
[fglrx] Maximum main memory to use for locked dma buffers: 1884 MBytes.Das ist besonders nervig, weil es keinen open source ATI Treiber für Linux gibt (für meinen X1600 Chip zumindest). Immerhin tut der 2d-Teil des ATI-Treibers, aber durch einen architekturellen Geniestreich funktioniert die Xvideo Extension nicht ohne funktionierendes Kernelmodul. Ich habe kurz überlegt, ob ich mir mal deren Binär-Blog disassemblieren soll, habe mich dann aber aus Selbsterhaltungstrieb-Gründen dagegen entschieden.
[fglrx] module loaded - fglrx 8.33.6 [Jan 8 2007] on minor 0
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
[fglrx:firegl_gps_init] *ERROR* Gps_GartInitialization failed.
[fglrx:firegl_init_pcie] *ERROR* Failed to initialize GPS.
Oh, warum ich Windows boote? Das mache ich immer bei den Patch-Tagen, damit ich, sollte ich mal irgendwo unfreiwillig Windows booten müssen, wenigstens den aktuellen Patchstand habe. Oh, übrigens, der normale ATI-Windows-Treiber funktioniert schon mal gar nicht auf meinem Notebook, das wird hier sicher der eine oder andere auch kennen, das Problem. Man kann ihn aber mit diesem gruseligen Tool hier zur Zusammenarbeit überreden. Stellt sich raus, daß der Treiber schon funktioniert, aber die in dem INF-File absichtlich die Mobile-Chips nicht listen, damit keiner auf die Idee kommt, das auf einem Notebook zu installieren. Ja, jetzt wo ihr mich so direkt fragt, finde ich auch, daß das eine absolute Zumutung ist, und ATI den Untergang verdient hat.
comment_arg = (char *) malloc((size_t) MAX_COM_LENGTH);NARF! MAX_COM_LENGTH ist 65000, falls es wen interessiert. Nun wollte ich mal wissen, wie denn da das Limit ist bei meinem x64_64 Linux. Habe also mal die Kernel-Sourcen ausgepackt, fs/exec.c geöffnet, und weil mir das zu kompliziert war, hab ich dann ein Beispielprogramm mit 65500 Zeichen Argument probiert, und das ging. Das mit dem Kernel erwähne ich, weil ich da folgende humoristische Deklaration fand:
if (comment_arg == NULL)
ERREXIT("Insufficient memory");
strcpy(comment_arg, argv[argn]+1);
#define EXTRA_STACK_VM_PAGES 20 /* random */Das in den JPEG-Sourcen, das war übrigens wrjpgcom. Falls das also jemand aus einer Webseite oder so mit anderer Leute Daten aufruft — ihr seit gerade 0wnbar.
c99: Fatal error in /tmp/opt/sun/sunstudiomars/prod/bin/ir2hf : Signal number = 11Whoa, beeindruckend. Signal 11 == SIGSEGV.
Jetzt gibt es Namen zu den Kunden: Credit Suisse, AIG und Deutsche Bank. Besonders bemerkenswert: Credit Suisse hat gar kein SuSE Linux im Einsatz.
Das zeigt mal wieder: große Firmen können auch Scheiße in Pappkartons verpacken, und sich das dann gegenseitig verkaufen.
Nun sieht es so aus als hat man mit den neueren ATI-Chipsätzen noch mehr die Arschkarte gezogen. Es gibt keine Open Source Treiber, als Framebuffer müsste man dann VESA nehmen, und X gibt es überhaupt nur mit dem Knödel-Treiber, auf den man nur in Notfällen angewiesen sein möchte. Wer mal nach X1600 und Linux googelt, findet lauter furchtbare Einzelschicksale von Leuten, die ihr X nicht zu Laufen kriegen. Meine Güte. Und ich war kurz davor, doch den Acer mit ATI zu kaufen, aber unter diesen Umständen ist das ja absolut ausgeschlossen.
Oder stimmt das nicht? Hat jemand bessere Informationen? Gibt es doch einen beschleunigten Konsolen-Framebuffer für Linux? Einen Open Source X.org Treiber (auf 3d könnte ich im Notfall verzichten unter Linux)?
Erschreckenderweise scheint im Moment die einzige politisch korrekte Grafikvariante der Intel Onboard Kram zu sein. Der performt zwar nicht, aber bis auf die den Macromedia-DRM-auf-TV-Ausgang gibt es das alles im Quellcode.
Und diese ATI-Situation ist auch der Grund, wieso ich gerade nach Alternativen zum Travelmate 8215 gucke. Aber irgendwie … wollen einen die Notebookhersteller alle verarschen, ist mein Eindruck.
Von Asus (kommt wegen früherer Kundendiensterfahrungen mit denen eh nicht in Frage, aber ich erwähn es trotzdem mal) gibt es ein Notebook mit Core 2 Duo 2 GHz (ich kauf mir kein beim Kauf schon veraltetes Notebook hier), und mit Nvidia-Grafik, und … die haben dann nur 1280xirgendwas Auflösung. WTF? Was denken die sich bloß?
Von FSC gibt es da noch ein Amilo aber auch mit kleinem Schirm (und das Äußere finde ich abstoßend).
Von HP gibt es ein Core 2 Duo 2 GHz Notebook mit … on-board-Grafik?! WTF?!?
Bei Lenovo gibt es ein Thinkpad mit richtigem Prozessor, kostet mehr als die anderen mit ATI oder Nvidia, aber hat onboard-Grafik. Die haben wohl echt nichts gelernt aus ihrer IBM-Zeit. Und die Platte ist auch nur halb so groß wie anderswo.
Maxdata hat zu kleine Auflösung.
Sogar Samsung verbaut jetzt ATI. Oh Mann. Was denken die sich nur alle?
Terra Mobile… hat jemand Erfahrung mit deren Notebooks? An dem Bildschirm steht "GLARE" dran, das macht mir Sorgen. Ich will einen Bildschirm, keinen Spiegel.
Kann das echt sein, daß da nur Dell übrig bleibt am Ende!? Dell ist auch ausgeschieden bei mir; ich habe bei denen gekauft und seit dem spammen die mich voll. Ich kaufe nicht bei Spammern. Abgesehen davon timed mir der Dell Webserver bei jeder 20. Verbindung aus. Wäre nicht so schlimm, wenn das nicht alles so Ajax-Scheiß wäre beim Konfigurieren. Warum machen die einem das alle so schwierig? Können die einem nicht einfach ein Rechts-Unten-Modell verkaufen und gut ist? Narf!
Was mich daran am meisten schockiert: das hat keiner gemerkt. Niemand. Avahi gibt es nen Jahr? Länger? Und niemand außer mir hat offenbar mal unabhängig mdns implementiert. Der Effekt ist, daß wenn man mit dem dietlibc Resolver nach einem von avahi beantworteten Host fragt, die Antwort gefressen wird. Ich habe mal einen Workaround in die dietlibc eingebaut, aber hey, ist das zum Kotzen oder was?
Update: Jemand hat dem avahi-Autor Bescheid gesagt, und der hat mich jetzt per Email angepinkelt. Die Situation stellt sich tatsächlich etwas differenzierter dar als bisher dargestellt. avahi implementiert die aktuelle Spec, ich eine ältere. Meine Schuld, hätte ich vor dem Meckern mal gucken können. In der aktuellen Spec steht, daß das RD Bit Null sein soll beim Senden, und daß man es beim Reinkommen ignorieren muss. Das stand früher nicht in der Spec, aber man muss die Wayback Machine bemühen, um auf frühere Versionen zugreifen zu können; offenbar sind den zeroconf-Leuten die früheren Versionen peinlich. Anyway, ich habe mir avahi bei der Gelegenheit noch mal kurz angesehen, und muss sagen, ist nicht so schlimm wie gnupg, aber leider auch nicht so richtig toll. Ich hab da jetzt keinen kompletten Audit gemacht, aber schon mal direkt nen (nicht exploitbaren) off-by-one buffer overflow gefunden, und eine Endlosschleife in der DNS Dekompression. Ich denke mal, für avahi wird es demnächst ein Update geben. Der CVS-Code bei der dietlibc akzeptiert jetzt konform zur aktuellen Spec auch mDNS-Pakete, die das Bit anders setzen als es bei ihnen ankam. Ich möchte an dieser Stelle übrigens die mDNS-Specschreiber aufrufen, diesen Blödsinn zu lassen, und die Regeln von DNS bezüglich dieser Bits weiter bestehen zu lassen — Eingabe == Ausgabe. Dann kann man mehr Code wieder verwenden und ihr ganzes Gefasel von wegen Code-Wiederverwerten und Protokoll-Beibehalten stimmt dann auch tatsächlich. Eines ihrer Argumente ist ja gerade, daß man die APIs beibehalten kann, und daraus folgt, daß res_query das Paket nicht selber baut, sondern res_mkquery tut das, und daher ist es auch nicht kosher, wenn res_query dann im Paket rumdoktorn soll, um das RD Bit zu löschen (immerhin sagt die mDNS-Spec dafür nur SHOULD, daher spare ich mir das). Leider sagt die aktuelle mDNS-Spec auch, daß bei rausgehenden Antworten das RD-Bit Null sein soll, und die DNS-Spec sagt, daß bei Antworten dieses Bit übernommen werden soll. Wenn die das Gefasel mit API-Beibehalten also ernst nehmen, dann sollte hier ganz klar Eingabe == Ausgabe gelten.
Und dabei hatte ich neulich erst wieder irgendwo gelesen, daß doch jeder wisse, daß der BSD IP Stack der beste der Welt sei, daß in Sachen Stabilität niemand an Solaris rankomme, und daß Linux beim Routen total krass Pakete verliere. Da sieht man mal, wie sehr man die ganzen BSD und Solaris Fanbois ernst nehmen kann.
BTW: FreeBSD 4 kann nicht nicht mehr runterladen, ohne ins Archiv zu laufen, daher zählt das nicht.
*** glibc detected *** git-http-fetch: double free or corruption (fasttop): 0x08085860 ***Und falls jetzt jemand denkt, ich hätte irgendwas ungezogenes mit git gemacht: ich rief "cg update" auf, im elinks tree.
Ich bin ja ansonsten ein großer Fan von Linux, und habe daher auch das hier erst mal für ein bedauerliches Mißverständnis gehalten, aber Linus persönlich hat das Ilja gegenüber verteidigt. Das ist da absichtlich drin. Grund? "Es gibt da draußen so viele kaputte Driver, und bevor wir die alle fixen, machen wir lieber diesen Code da rein". OMFG! Das Niveau ist ja schlimmer als bei Windows! Grusel!
XSearch provides powerful text searches on Linux using regular expressions for both the file name and the search text. It is the graphical equivalent of find + grep.
Beginnen wir mit dem guten Teil: bsearch und qsort. Das API ist wohldefiniert, funktioniert verläßlich, und taugt auch im täglichen Leben. Gut, es gibt da noch vereinzelt Details, über die man sich lustig machen kann, z.B. daß qsort in der glibc nicht etwa ein Quicksort ist, sondern ein Mergesort :-) Aber hey, darüber kann man hinweg sehen.
Die anderen Kracher sind alle in <search.h>. Es gibt da z.B. so Gemmen wie lsearch und lfind. Beide kriegen wie bsearch eine Vergleichs-Funktion als Function Pointer übergeben und suchen linear in einem Array. Ja, linear. In der Zeit, in der ich eine Vergleichs-Funktion implementiert habe, habe ich das auch schnell inline hingeschrieben. Und lesbarer ist das auch. Wieso gibt es da zwei Funktionen? Weil eine von ihnen im Falle des Nicht-Findens das gesuchte Element am Ende anhängt. Wer sich jetzt denkt, daß die Funktion dann da schon realloc machen wird, täuscht sich. "Wird schon passen". What could possibly go wrong? Oh, welche sucht und welche fügt auch an? Ist anhand der Namen ja schwer zu sagen, gell? Ich zitiere mal die Linux-Manpage: BUGS: The naming is unfortunate.
Aber das ist bestimmt nur ein Ausreißer, mhh? Der Rest der Datei ist bestimmt brauchbar. Na mal gucken… insque und remque überzeugen auch auf Anhieb. Es gibt da zwei VAX-Instruktionen gleichen Namens, die Elemente in eine doppelt verkettete Liste einfügen. Und so erwarten insque und remque Zeiger auf eine struct, die einen next und einen previous Pointer am Anfang haben. Leider kann man das in C nicht ausdrücken, und so kriegen die Funktionen void* übergeben! Type-Check? Brauchen wir nicht. Und es gibt auch kein Konzept einer leeren Liste, und remque kann einem auch nicht mitteilen, wenn die Liste jetzt leer ist. Kurz: voll für den Fuß.
Aber wartet, es kommt noch mehr: hsearch sucht in einer Hash-Tabelle. Ja, einer. Das ist kein Argument an die Funktion, es gibt nur eine, implizite, statisch deklarierte, auf die man auch nicht direkt zugreifen kann. Warum auch, man hat ja hsearch. Und wenn man mehr als eine Hash-Tabelle braucht? Geht nicht. (Es gibt eine GNU Extension, mit der das dann doch geht)
Nun fragt man sich: wer kann so auf Drogen gewesen sein, sich so beschissene APIs auszudenken? Das können doch eigentlich nur die BSD-Junkies gewesen sein? Nein! Das ist System V! Das ist das Stinke-Unix, dessen übelriechenden Kadaver SCO gekauft hat. Es gibt in der Datei auch noch APIs für Suchbäume. Ich habe sie mir noch nicht angesehen, aber es würde mich wundern, wenn die was taugen.
Zuerst muss man dafür Cross-binutils bauen, das sind Assembler und Linker und so, das ist auch normalerweise gar kein Problem.
./configure --prefix=/opt/cross --target=x86_64-linux --enable-static --disable-sharedund gut ist. Statisch deshalb, weil ich in /opt/cross auch Crosscompiler für zig andere Plattformen habe, um zu gucken, ob die diet libc noch mit allen Plattformen sauber baut. Wenn man da den Default nimmt, und ein Cross-Binutils für Alpha-Linux installiert, dann geht danach der Assembler für AMD64 nicht mehr, weil der die selbe Shared Library laden will, die aber von AMD64 nichts weiß. OK, damit kann ich leben. Fällt man einmal drauf rein, lernt man, gut ist.
Der nächste Schritt ist der Crosscompiler. Hier kommt die erste echt Hürde, denn der Crosscompiler baut normalerweise für C, C++, Java, Objective C, allen möglichen Schund Compiler. Die kommen alle mit Laufzeitumgebungen, die nicht kompilieren, weil sie eine funktionierende libc erwarten. Die haben wir nicht, wir bauen ja gerade den Compiler, mit dem wir sie dann übersetzen wollen. Daher sieht bei gcc die Configure-Zeile so aus:
./configure --prefix=/opt/cross --target=x86_64-linux --enable-static --disable-shared --enable-languages=c --disable-nlsDas --enable-static hier bezieht sich auf libgcc; wenn gcc die wie normal dynamisch zu bauen versucht, schlägt das mangels libc fehl. Aber auch so gibt es Ärger, weil libgcc von der Zielplattform die libc-Header haben will. Das finde ich persönlich ja einen groben Verlierer, ja geradezu den Stirnklatscher überhaupt. An der Stelle hat man normalerweise verloren. Übliche Notfall-Ansätze sind "Debian-Paket bzw Fedora-RPM der glibc der Zielplattform ziehen, von Hand die Header auspacken, und an die richtige Stelle (/opt/cross/x86_64-linux/include) kopieren". Wieso nicht einfach /usr/include nehmen? Weil bei der glibc die Header von der Plattform abhängen! Nicht so bei der dietlibc, und so habe ich für meine Crosscompiler immer die dietlibc-Header gesymlinkt, und dann ging das gut (mal abgesehen von Bizarro-Plattformen wie IA64, der will da Dateien und Symbole haben, von denen ich noch nie gehört habe, irgendwelcher libc-Support fürs Stack Unwinding… *grusel*).
Normalerweise höre ich an der Stelle auf, denn wenn ich einen Crosscompiler habe, kann ich damit die dietlibc übersetzen. Heute habe ich mich aber so über das Gentoo auf meinem Desktop geärgert, daß ich mir vorgenommen habe, meine Linux-Distro "Fefix" mal für AMD64 zu crosscompilen. Schritt 1: glibc. Und was soll ich euch sagen, glibc ist nicht crosscompilefähig! Der versucht, sizeof(long double) rauszufinden, indem er ein Programm übersetzt und ausführt. Das geht natürlich nicht. Gut, in configure fest 16 reingehackt (die Alternative ist, einen config.cache manuell zu erstellen, in dem das drin steht), und was sehen meine entzündeten Augen?
checking for libgd… no [libgd?!?!?…]WTF?! C cleanup handling? Und gcc 4.1.1 soll das nicht unterstützen?! ARGH! Na gucken wir uns doch mal das Testprogramm an:
checking for ANSI C header files… no [doh!]
checking for sys/types.h… no
checking for sys/stat.h… no
checking for stdlib.h… no
checking for string.h… no
checking for memory.h… no
checking for strings.h… no
checking for inttypes.h… no
checking for stdint.h… no
checking for unistd.h… no
checking for long double… no
checking size of long double… (cached) 16 [Warum macht er das überhaupt, wenn er glaubt, daß es kein long double gibt?!]
running configure fragment for sysdeps/x86_64/elf
checking for x86-64 TLS support… yes
running configure fragment for nptl/sysdeps/pthread
checking for forced unwind support… yes
checking for C cleanup handling… no
#include <stdio.h>Na und woran scheitert es wohl? RICHTIG! Kein stdio.h! Denn ich kompiliere ja gerade die libc, DAMIT ICH DIESES HEADER-FILE KRIEGE! Lieber Herr Drepper, warum erhängen Sie sich nicht einfach an der nächsten Eiche? Das würde uns allen viel Ärger sparen. Danke.
void cl (void *a) { }
int
main ()
{
int a __attribute__ ((cleanup (cl)));
puts ("test")
;
return 0;
}
IA-32 Instructions Database is a description of all IA-32 instructions in the form of SQL source, specifying operands, arguments, prefixes, encoding details, and description.But wait! There's more!OpenEMM is a feature-rich industrial-strength enterprise software for email marketing. OpenEMM runs on top of a proven open source software stack: Linux, MySQL, and a Web container like Tomcat.
PHPUsenet is a set of scripts that allow you to mirror a newsgroup in an SQL database. Users can read posts, browse, search, reply, and start new threads. Multiple newsgroups are supported for one frontend. The posting facility can be password protected.Und woran denkt man zuerst, wenn man PHP und SQL in einem Satz liest?Changes: Fixes improper sanitization of the "group" URL parameter.Richtig, SQL Injection.Ausnahmsweise noch eine Zugabe:
osinfo reports the type, the version, the architecture, and the kernel of the Linux distribution you are running.uname, anyone?
update-zoneinfo is a utility for synchronizing a host's time zone information according to definitions stored on a central server. Linux and Solaris are currently supported. It can be periodically run from crontab to deal with changes in daylight saving times.Äh, synchronize? Die Timezone-Daten beinhalten bereits Fixups für Sommerzeit und so, das ist genau deren Aufgabe. Da muss man nichts synchronisieren, und schon gar nicht mit perl per cron.Und hier noch einer, außer Konkurrenz, weil der wirklich alles hat, was man nicht haben will:
PyHJB is a Python-to-JMS gateway that makes it possible to access JMS 1.1 (Java Message Service) messaging providers via HJB, the HTTP JMS bridge. It acts as an HTTP gateway server for any JMS messaging provider, and provides a RESTful equivalent for most of the non-optional portions of the JMS API. It is distributed with a few demo scripts that show it being used with WebSphere MQ, Swift MQ, Active MQ, and JBoss Messaging.Bing-bing-bing-Bingo! :-)
Und Apple weiß das offensichtlich auch: "How to pick up and carry your iMac G5"
But wait, there's more! zu strfry gibt es auch noch ein Security Advisory (das ich allerdings für hirnrissig halte, das könnte man genau so gut bei strlen bemängeln), und der absolute Oberhammer ist dieser Debilian Bugreport. Un-fucking-believable. Wenn es ein Code-Killfile gäbe, Ulrich Drepper wäre drin.
Oh, und wo wir gerade beim glibc-Bashing sind: man kann bei der glibc Callbacks definieren, um bei printf neue Format-Zeichen zu definieren. Und nun ratet mal, welche Qualitätssoftware dieses großartige Feature benutzt: richtig, reiserfsprogs. Die definieren damit z.B. einen Callback, um ein Tupel von zwei Zahlen auszugeben IIRC. Unfaßbar. Aber hey, reiserfs benutzt ja eh niemand, oder? Oder?!
Vielleicht sollte ich echt mal eine Webseite aufmachen, und dort ein Coder-Killfile unterhalten. Drepper, die Reiserfs-Jungs, Schilling, … da kämen aber nur die besonders harten Fälle hin. Ich will ja auch noch zu anderen Sachen kommen.
int range_ptrinbuf(const void* buf,unsigned long len,const void* ptr) {
register const char* c=(const char*)buf;
return (c && c+len>c && (const char*)ptr-c<len);
}und hier ist ein Test der Testsuite:assert(range_ptrinbuf(buf,(unsigned long)-1,buf+1)==0);Dieser Test übergibt einen Buffer, bei dem die Länge einen Integer-Overflow produziert. Genau für diesen Fall ist der c+len>c Teil in der Funktion da. Und was passiert zu meinem Entsetzen? Mit gcc 4.1 kompiliert akzeptiert meine Funktion diesen Buffer, und zwar mit oder ohne Optimizer. Mit dem alten gcc 3.4.5 geht es.
Wieso blogge ich das? Weil das genau der Code ist, mit dem man diese Art von Problem erkennt. Und es gibt viele Stellen, wo man diese Art von Problem erkennen will — im Linux-Kernel, in Samba, … Wenn ihr also euren Linux-Kernel mit gcc 4.1 kompiliert hat, oder Samba, dann wäre jetzt eine gute Gelegenheit, das noch mal mit gcc 3 zu kompilieren. An der Stelle vielleicht auch erwähnenswert: gut, daß ich gleich eine Testsuite gemacht habe für meine Funktionen! Testsuiten finden nicht nur Bugs in der eigentlichen Software, sondern auch in der Infrastruktur drum herum. Daher immer schön Testsuiten bauen! Ach ja, nur um das mal erwähnt zu haben: auch gcc hat eine Testsuite, und zwar nicht zu knapp. Ich bin ehrlich gesagt erschüttert, daß diese Art von Bug nicht von deren Testsuite gefunden wurde. Bug 27180.
Auch wenn die Riposte Graduée inzwischen als solche vom Tisch war (siehe La Riposte Dégradée), so gibt es durchaus weitere eigenartige Regelungen, zum Beispiel findet die französische Regierung nichts daran auszusetzen, daß ein Künstler von den 99c, die ein Titel online kostet, genau 4c (in Worten: vier Cent) bekommen soll. Die restlichen 95c gehen an die Regierung (19.6% MwSt), die Rechteverwerter und die Plattenlabels. In der Debatte ließ Christian Paul (PS) verlauten, daß Versuche, die Mehrwertsteuer für Musik auf die von Büchern (5.5%) zu senken, von der Regierung wohl geblockt worden waren. […](Danke, Fabian)Vorsichtig ausgedrückt, zeigte sich hier in welchem Ausmaß die Musikindustrie das geschehen beeinflußte. Der Gripfel war wohl, daß selbige als erste in der Geschichte der "Fünften Republik" die Assemblée Nationale belagert hat, um kommerziell motivierte Werbung für ihre Produkte zu machen. Den Boden endgültig aus dem Faß gehauen hat dann die Vergabe von bereits bezahlten Downloadgutscheinen im Wert von 9,99? an die Abgeordneten.
Die Vorlage selbst zielte darauf ab, ein Überwachungssystem für das gesamte französische Internet umsetzen, welches an 1984 erinnerte und eine effiziente Umsetzung und Anwendung der 'Riposte Graduée' ermöglichen sollte, also des 'abgestuften Zurückfeuerns', so daß erst das dritte Abspielen einer DVD unter Linux mit 3 Jahren Haft und 300.000 Euro Geldstrafe geahndet wird, und nicht bereits das erste. Die effiziente Umsetzung des Überwachungssystemes sollte durch eine Privatpolizei garantiert werden.
Jedenfalls, bei dem Benchmark ist ihre eigene Technologie natürlich das schnellste auf dem Markt, aber Cairo hat ungefähr 20-25% der Performance von GDI+. Wie peinlich ist DAS denn bitteschön!? Von Windows-Steinzeit-GDI überholt zu werden!? Oh Mann. Manchmal wünschte ich mir, es gäbe da so eine Darwinistische Grundeinstellung wie bei den Japanern, daß sich solche Leute dann einfach in einem stillen Stüblein entleiben und gut ist. Unfaßbar. Zumindest muss man da Modalitäten für Schadensbegrenzung finden. Bei solcher Infrastrukturarbeit ist es ja kein Wunder, daß Firefox unter Windows eine Größenordnung flinker wirkt als unter Linux.
….supported unsere Hardware ausschließlich nur FAT und NTFS. Andere Dateisysteme wie die von Linux oder Unix bedürfen aufgrund ihrer aggressiven Schreibtechnik spezieller Festplatten. Das weiß aber heutzutage inzwischen jedes Kind. Aus diesem Grunde kann davon ausgegangen werden, dass die Verwendung eines von uns nicht zerifizierten Betriebssystems zum beschriebenen Schaden geführt hat. Ein Garantieanspruch ist damit leider erloschen(Gefunden bei Su-Shee)aus diesem Grunde würden wir Ihnen dringlichst anraten, das für dieses spezielle Gerät besonders angepasste Betriebssystem Windows XP Home fortan alleinig zu verwenden. Damit erhöht sich die Nutzungsdauer ihres Gerätes dramatisch
Vielleicht fragt sich jetzt der eine oder andere, wieso ich überhaupt OpenBSD zuerst installiert habe; nach den Ergebnissen vom letzten Mal war ja mit einem Desaster zu rechnen, und die OpenBSDler mögen mich ja eh nicht :-) Das liegt daran, daß OpenBSD ein Alleinstellungsmerkmal hat: bei den Installationsdateien liegt ein pxeboot bei, und ein so bootbarer Kernel. So ist das Einrichten einer Netzwerk-Installation für OpenBSD eine Sache von Minuten. Schade, daß die anderen BSDs (und die ganzen Linux-Distros) nicht auch anbieten. Einige Linux-Distros bieten PXE-Install an, aber das ist dann in ihrer eigenen Umgebung. Ich möchte hier gerne ein PXE-Bootmenü haben, wo man auswählt, daß man jetzt ein NetBSD 2.1 installieren will, und dann kommt der NetBSD 2.1 PXE-Installator. Ist das zuviel verlangt? Es sind gute Ansätze wie diese, die mich immer wieder zu OpenBSD bringen. An sich sind das ja gute Leute, es kümmert sich nur keiner um die entscheidenden Details. Was schert mich die Sicherheit von OpenBSD, wenn ich damit nicht mal genug Plattendurchsatz kriege, um Fast Ethernet zu saturieren? Ich bin ja auch bereit, Abstriche zu machen, so ist das ja nicht. Ich habe mir extra eine Intel Gigabit NIC geholt, weil keines der BSDs die NVidia-Onboard-Gigabit-NIC unterstützt, obwohl es dafür bei Linux einen Open Source Treiber gibt (genau wie für DMA beim NVidia IDE-Controller übrigens).
Der Vollständigkeit halber: man kann auch FreeBSD und NetBSD PXE-fähig machen. Es gibt da obskure Dokumente, wie man sich das pxeboot-File aus dem ISO-Image rauskratzen muss und so. Von drei Dokumenten funktionieren alle nicht, aber man kann sich da wohl was zurecht fummeln. Ich hatte das vor zwei Monaten schon mal kurz angetestet und hab jetzt hier immerhin ein pxeboot für NetBSD. Es ist also nicht so, daß die das gar nicht anbieten; sie bieten es nur nicht so an, daß es eine Option wäre in der Praxis.
Oh, und zur Sicherheit: wenn man den i386-Kernel von OpenBSD auf der Hardware bootet, dann bleibt der bei der Kernel-Initialisierung stehen. Falls jetzt jemand kommt und sagt, AMD64 sei ja eh experimentell und ich hätte ja das gut abgehangene i386-Zeug nehmen sollen.
Ich finde es allerdings eine interessante Metrik, a) wie viele Szenarien sich die OS-Fans selbst ausdenken können, in denen ihr Favorit klar führt, und b) wie realitätsnah die sind. Letztes Mal ging es mir nur darum, interessante Messungen durchzuführen. Nachdem dann zwei der drei Beteiligten als Antwort auf die Benchmarks deutliche Verbesserungen vorgenommen haben, die allen etwas gebracht haben, habe ich das dieses Mal auch zu meinem Anspruch gemacht, Sachen zu finden, die besonders verbesserungswürdig sind, und auf die mal jemand pressewirksam mit dem Finger zeigen sollte.
Bisher ist übrigens noch kein Benchmarkvorschlag bei mir eingegangen. Auf der einen Seite schön, weil die Leute vielleicht keine Benchmarks manipulieren wollen, auf der anderen Seite kann es ja auch an Verpeilung oder Desinteresse liegen, oder daran, daß es tatsächlich keine Szenarien gibt, in denen BSD Linux outperformt.
Manche Leute haben vermutet, es ginge darum, den Vorwurf des Linux-Bashings zu vermeiden. Darum geht es nicht. Es geht mir voll am Arsch vorbei, wenn BSDler keine andere Verteidigung finden, als den Benchmark-Durchführer persönlich anzugreifen, im Gegenteil, das ist in sich ein prima Meßwert über das jeweilige BSD. Weil das so ist, habe ich letztes Mal NetBSD so gelobt, die es nicht gemacht hatten.
Aber es läßt sich ganz deutlich sagen, daß meine Benchmarks letztes Mal gezeigt haben, daß Linux 2.6 schon weitgehend perfekt ist von der Skalierbarkeit, und so hat Linux 2.6 keine vorteilhaften Veränderungen gemacht, als einziger Teilnehmer keinen Gewinn gezogen. Dieses Mal möchte ich, daß auch für Linux etwas heraus fällt. Ganz einfach.
Der Unix-Ansatz ist, daß man die Sockets alle auf "non-blocking" setzt. Wenn man dann read aufruft, aber nichts da ist zum Lesen, blockt der Prozeß nicht, sondern man kriegt "probier später nochmal" als "Fehler"-Meldung. Dann benutzt man ein Event Notification API, um sich sagen zu lassen, auf welchen Sockets gerade Daten reingekommen sind.
Unter Windows ist der Ansatz umgekehrt: es gibt keinen Non-Blocking Mode für Sockets. Man startet ein read mit fixem Zielpuffer, und das Event Notification Framework von Windows sagt einem dann nicht, wenn es was zu lesen gibt, sondern wenn es was zu lesen gab, d.h. zu dem Zeitpunkt ist das schon gelesen. Das Problem dabei: Wie macht man Timeout-Handling? Man kann nicht unterwegs fragen, wie weit der Datei-Rausschieben-Job schon gekommen ist! Also kann man auch nicht wissen, ob die Verbindung seit 10 Minuten hängt, oder ob da nur ein sehr langsames Modem auf der Gegenseite ist.
Und dann schreiben die Man-Pages was von Background-Threads, … also kurz gesagt: der Windows-Ansatz ist: "gib mal her, der Kernel macht das schon". Nur leider macht der Kernel das nicht besonders gut. Kernel-Threads, das erweckt eine Vision von einem Thread pro ausstehendem I/O-Request, anstelle einer anständigen State Machine.
Ein anderes Problem ist, wie man Handles alloziert. Man macht einen Socket oder eine Datei auf, und kriegt ein Handle vom System. Unter Unix ist das traditionelle Problem, daß das ein Integer ist, und das man die kleinste unbelegte Zahl als Integer kriegt. Linux und die BSDs haben sich da unglaubliche Algorithmen überlegt, um das schnell zu erledigen (einfach ist es jedenfalls nicht). Windows liefert einfach nicht den kleinsten Integer aus, sondern irgendeinen. Man sollte denken: Problem erledigt. Aber dann stößt man auf Funktionen wie AcceptEx, wo man einen Deskriptor wiederverwenden kann, weil es offenbar unter Windows immer noch immens teuer ist, ein Handle zu allozieren. WTF?!
Schlimmer noch: der Normalfall bei TransmitFile (dem sendfile-Ersatz unter Windows) ist, daß das ganze File am Stück gesendet wird, und man kann dann per Flag sagen: "mach danach mal die Verbindung zu". Kurzum: Timeout-Handling, nein danke. Und dieses Handle-Wiederverwerten legt die Vermutung nahe, daß typische Server, selbst wenn sie dieses Ultra-Skalierbarkeits-API verwenden, trotzdem nur n Verbindungen parallel haben können, weil man die Handles unter Windows halt vorher als Pool alloziert und mehr geht dann halt nicht. Oder wie?
Man darf gespannt sein, wie sich das dann unter realen Gesichtspunkten mißt. Aber ich mache mir da keine großen Hoffnungen, wenn ich Formulierungen wie "The server optimizes the TransmitFile function for high performance. Workstations optimize the function for minimum memory and resource utilization." lese. Ich hab hier "nur" Windows XP Professional zum Testen, und da performt das ja offensichtlich absichtlich scheiße, damit die Leute lieber die Advanced Datacenter Ultra Monster HeadShot Edition kaufen. Überhaupt ist TransmitFile der Kludge des Jahres. Man sendet immer Chunks aus einer Datei, als Länge maximal 32 Bit. Dateien mit mehr als 4 Gigabyte schickt man dann, indem man halt mehrfach TransmitFile aufruft. Womit wir dazu kommen, wie man sagt, ab welchem Offset in der Daten TransmitFile schicken soll. TransmitFile sendet ab der aktuellen Byteposition im File, aber die Man Page rät einem, man möge die Overlapped-Struktur (die für alle anderen Fälle opak ist und interne Fortschrittsinformationen für asynchrones I/O für den System-Thread ablegt, der es bearbeitet) manipulieren, um das Offset zu setzen. Es ist Pfusch wie dieser, der das alles nicht schön aussehen läßt. Na mal gucken.
Die IT-Strukturen der Stadtverwaltung sind viel komplexer als erwartet.sagt der Projektleiter, Florian Schießl. Schade, schade, schade, daß ausgerechnet die Vorzeigeprojekte immer so vor die Wand gefahren werden müssen.
Wir haben die Firma IABG mit der Kontrolle des Projekts beauftragt, sagt die Stadträtin Strobl.
Die IABG soll sicherstellen, dass weder Kosten noch Zeitaufwand des LiMux-Projekts aus dem Ruder laufen. Soso, das wäre das erste Mal, dass in einer öffentlichen Verwaltung durch Consultant-Einsatz Kosten nicht aus dem Ruder laufen… (Anwesende natürlich ausgeschlossen) (Danke, Hans)