《Echtzeit-Linux würde alle diese Anforderungen erfüllen, ist aber für viele Geräte, die auf dem Markt sind oder noch erscheinen werden, zu groß, bietet eine zu große Angriffsfläche und kann nur mit stetigen Updates sicher gehalten werden.》 Und wie hält man dann Zephyr sicher? Lasst mich raten - Man behebt Fehler noch seltener als Smartphone-Hersteller das aktuell tun.
Das muss nicht sein und es wird sicherlich verschiedene Möglichkeiten geben. Z.B. könnte das System wie bei Mikrocontrollern mittels USB-Bootloader oder In System Programmer Updates ermöglichen. Auch das Flashen einer SD-Karte, von der das System geladen wird, wie beim Raspberry Pi, wäre denkbar. Auf ein selbstupdatendes System wird wohl verzichtet um das System schnell und übersichtlich zu halten. Bei spezialisierten Systemen kann man das, nach meiner Meinung, durchaus so handhaben.
Bei Wegwerfgeräten, wird es natürlich keine Updates geben - weder durch im System integrierten, noch externen Updatemechanismus.
Und nun stellen wir uns den aktuellen glibc Fehler (news vor 2 Tagen) auf einem solchen IoT-Gerät (DNS-Abfrage nicht unwahrscheinlich) vor. Dann wird die hochspezialisierte Glühlampe zum Spamserver, und ohne Update bleibt sie das auch. Ungetrennte Adressräume tun das ihrige zum Problem.
Wieso würde ein Echtzeitlinux dieses erfüllen und warum hat dieses eine zu große Angriffsfläche? Und warum müssten da ständige Updates ran? Das ist ja nicht der WUFtp:P
Btw: Die Aktualisierungsrate wird wohl auch unter der "linux auf dem Desktop"rate sein, leider.
Die statistische Anzahl von Fehler pro 1000 Zeilen Code ist seit vielen Jahren allgemein anerkannt und je kompatker etwas ist umso weniger Fehler schon alleine dadurch
ABER und das ist der springende Punkt: Je kompatker etwas gehalten wird desto durchschaubarer ist es auch für einzelne Personen oder kleinere Teams versus einem Moloch der 100fach so gross ist so dass jeder nur einen kleinen Bruchteil davon verstehen KANN egal wieviel Zeit er in die Fehlersuche investiert
Rate mal was NATURGEMÄSS sicherer ist - Ein Moloch der alles kann uns supported was sich jemals wer ausgedacht hat oder ein speizielisiertes System dass nor absolut notwendigen Code enthält
Aber Hauptsache du hast mal einen blöden Kommentar abgegeben
Super, jetzt haben wir eine übliche Schankungsbreite von 0,1 bis 50 Fehlern auf 1000 Zeilen. Damit kann ein Programm 500 mal größer sein und trotzdem die selbe Anzahl an Fehlern aufweisen.
Oder legst du hier die Annahme zugrunde, daß Linux und das neue Betriebssystem den exakt gleichen oder zumindest einen sehr ähnlichen Fehlerquotienten aufweisen?
Außerdem ist das eine sehr perspektivische Betrachtungsweise welche mit viel Vorsicht zu genießen ist. Ansonsten wären Prepared Statements per se unsicherer als herkömmliche Statements, da sie wesentliche mehr Code benötigten.
Desweiteren legst du hier scheinbar die Annahme zugrunde, daß die Anzahl der Fehler zu der Anzahl an Sicherheitslücken in einem direkten Verhältnis stehen würden.
Selbst deine Beleidigungen sind unkreativ. Aber ohne diese scheinst du ja gar nicht argumentieren zu können. Denn an fachlicher Kompetenz hast du ja nichts vorzubringen.
Deine Aussage verkürzt wiedergegeben --> viel Code = unübersichtlicher Moloch
Daran sieht man, daß du von professioneller Arbeit keine Ahnung hast, geschweige denn jemals einen Blick in die Sourcen des Linux Kernels geworfen hast.
Du raffst es einfach nicht - Verkürzt: "weniger code = in jedem fall übersichtlicher, speziell für jemanden der ihn nicht geschrieben hat und einen audit machen soll"
Von kamome umidori am Mo, 22. Februar 2016 um 09:38 #
Wenn dem System 8KB Speicher genügen, ist es vermutlich so klein, dass man tatsächlich (nach einigen Revisionen) gegen Fehlerfreiheit streben kann (da auch nicht ständig neue Sachen implementiert werden müssen).
... ja, exakt daran habe ich auch schon gedacht. Wie ist das aber mit den Lizenzen? Die MINIX 3 Lizenz ist ein Klon der BSD-Lizenz (BSD license). Versteht jemand den Unterschied?
Ich verstehe vielleicht nicht genug von der IoT-Materie, aber ist es sicherheitstechnisch nicht eher ein Albtraumszenario, wenn sich System und Anwendungen ein und denselben Adressraum teilen?
Im Prinzip und gerade bei dynamischer Reservierung - JA
Wenn allerdings wirklich die Reservierung des Speichers, wie im Artikel beschrieben, statisch erfolgt so sollte es kein Problem darstellen.
Stelle mir das so vor, dass die ersten 20% fix dem System gehörten und die restlichen 80% von den Anwendungen belegt werden können. Aber der benötigte Speicher muss direkt beim Start von der jeweiligen Applikation reserviert werden und ein nachträgliches Ändern zur Laufzeit ist nicht mehr möglich.
"und kann nur mit stetigen Updates sicher gehalten werden."
also ist Zephyr mit Version 1.0.0 fertig ausgereift und man muss es nicht mehr updaten ? Dann kann man ja die Leute wieder aus der Arbeitsgruppe entlassen denn Updaten ist ja nicht mehr von nöten....
Cool jetzt haben wir endlich ein System das man nicht mehr updaten müssen...
《Echtzeit-Linux würde alle diese Anforderungen erfüllen, ist aber für viele Geräte, die auf dem Markt sind oder noch erscheinen werden, zu groß, bietet eine zu große Angriffsfläche und kann nur mit stetigen Updates sicher gehalten werden.》
Und wie hält man dann Zephyr sicher? Lasst mich raten - Man behebt Fehler noch seltener als Smartphone-Hersteller das aktuell tun.
Das muss nicht sein und es wird sicherlich verschiedene Möglichkeiten geben. Z.B. könnte das System wie bei Mikrocontrollern mittels USB-Bootloader oder In System Programmer Updates ermöglichen. Auch das Flashen einer SD-Karte, von der das System geladen wird, wie beim Raspberry Pi, wäre denkbar.
Auf ein selbstupdatendes System wird wohl verzichtet um das System schnell und übersichtlich zu halten. Bei spezialisierten Systemen kann man das, nach meiner Meinung, durchaus so handhaben.
Bei Wegwerfgeräten, wird es natürlich keine Updates geben - weder durch im System integrierten, noch externen Updatemechanismus.
Und nun stellen wir uns den aktuellen glibc Fehler (news vor 2 Tagen) auf einem solchen IoT-Gerät (DNS-Abfrage nicht unwahrscheinlich) vor. Dann wird die hochspezialisierte Glühlampe zum Spamserver, und ohne Update bleibt sie das auch. Ungetrennte Adressräume tun das ihrige zum Problem.
Wieso würde ein Echtzeitlinux dieses erfüllen und warum hat dieses eine zu große Angriffsfläche? Und warum müssten da ständige Updates ran? Das ist ja nicht der WUFtp:P
Btw: Die Aktualisierungsrate wird wohl auch unter der "linux auf dem Desktop"rate sein, leider.
" ... das extrem kompakt und damit auch sicherer als Linux ist ... "
Was für eine Begründung -.-
Was genau verstehst DU daran nicht?
Die statistische Anzahl von Fehler pro 1000 Zeilen Code ist seit vielen Jahren allgemein anerkannt und je kompatker etwas ist umso weniger Fehler schon alleine dadurch
https://de.wikipedia.org/wiki/Fehlerquotient#Fehlerdichte_in_der_Informatik
ABER und das ist der springende Punkt: Je kompatker etwas gehalten wird desto durchschaubarer ist es auch für einzelne Personen oder kleinere Teams versus einem Moloch der 100fach so gross ist so dass jeder nur einen kleinen Bruchteil davon verstehen KANN egal wieviel Zeit er in die Fehlersuche investiert
Rate mal was NATURGEMÄSS sicherer ist - Ein Moloch der alles kann uns supported was sich jemals wer ausgedacht hat oder ein speizielisiertes System dass nor absolut notwendigen Code enthält
Aber Hauptsache du hast mal einen blöden Kommentar abgegeben
Super, jetzt haben wir eine übliche Schankungsbreite von 0,1 bis 50 Fehlern auf 1000 Zeilen. Damit kann ein Programm 500 mal größer sein und trotzdem die selbe Anzahl an Fehlern aufweisen.
Oder legst du hier die Annahme zugrunde, daß Linux und das neue Betriebssystem den exakt gleichen oder zumindest einen sehr ähnlichen Fehlerquotienten aufweisen?
Außerdem ist das eine sehr perspektivische Betrachtungsweise welche mit viel Vorsicht zu genießen ist. Ansonsten wären Prepared Statements per se unsicherer als herkömmliche Statements, da sie wesentliche mehr Code benötigten.
Desweiteren legst du hier scheinbar die Annahme zugrunde, daß die Anzahl der Fehler zu der Anzahl an Sicherheitslücken in einem direkten Verhältnis stehen würden.
Hättest du Schwachkopf doch einfach nach dem Wikilink weitergelesen, scroll rauf, nochmal erkläre ich es dir nicht
Selbst deine Beleidigungen sind unkreativ. Aber ohne diese scheinst du ja gar nicht argumentieren zu können. Denn an fachlicher Kompetenz hast du ja nichts vorzubringen.
Deine Aussage verkürzt wiedergegeben --> viel Code = unübersichtlicher Moloch
Daran sieht man, daß du von professioneller Arbeit keine Ahnung hast, geschweige denn jemals einen Blick in die Sourcen des Linux Kernels geworfen hast.
Du raffst es einfach nicht - Verkürzt: "weniger code = in jedem fall übersichtlicher, speziell für jemanden der ihn nicht geschrieben hat und einen audit machen soll"
Wenn dem System 8KB Speicher genügen, ist es vermutlich so klein, dass man tatsächlich (nach einigen Revisionen) gegen Fehlerfreiheit streben kann (da auch nicht ständig neue Sachen implementiert werden müssen).
Kann Minix3 das nicht schon alles?
... ja, exakt daran habe ich auch schon gedacht. Wie ist das aber mit den Lizenzen? Die MINIX 3 Lizenz ist ein Klon der BSD-Lizenz (BSD license). Versteht jemand den Unterschied?
Ich verstehe vielleicht nicht genug von der IoT-Materie, aber ist es sicherheitstechnisch nicht eher ein Albtraumszenario, wenn sich System und Anwendungen ein und denselben Adressraum teilen?
Im Prinzip und gerade bei dynamischer Reservierung - JA
Wenn allerdings wirklich die Reservierung des Speichers, wie im Artikel beschrieben, statisch erfolgt so sollte es kein Problem darstellen.
Stelle mir das so vor, dass die ersten 20% fix dem System gehörten und die restlichen 80% von den Anwendungen belegt werden können. Aber der benötigte Speicher muss direkt beim Start von der jeweiligen Applikation reserviert werden und ein nachträgliches Ändern zur Laufzeit ist nicht mehr möglich.
"und kann nur mit stetigen Updates sicher gehalten werden."
also ist Zephyr mit Version 1.0.0 fertig ausgereift und man muss es nicht mehr updaten ?
Dann kann man ja die Leute wieder aus der Arbeitsgruppe entlassen denn Updaten ist ja nicht mehr von nöten....
Cool jetzt haben wir endlich ein System das man nicht mehr updaten müssen...
Leider wird vermehrt irgendwelches Zeugs verbreitet aber keine Links zu den Quellen gegeben. Das ist unseriös und nicht im Sinne des WWW.