Was für ein SCHEISS diese ganze Software ist!
Felix von Leitner
in den ersten n Bytes m zufällige Veränderungen vornimmt. Damit rennt
er los, wendet das auf Dateien an, und bringt Software zum Absturz. Ich
nenne das zu faul zum anständigen Codelesen, aber in der
Security-Industrie nennt sich das offenbar "fuzzing".
Dieses Programm hat er gestern abend mal auf ein UFS-Image angewendet,
und hat nach drei Anläufen ein Image gehabt, das OpenBSD und NetBSD zu
Panikattacken verleitet. Ich vermute dringend, daß auch FreeBSD und OS
X abrauchen, wenn sie das zu mounten versuchen. Die Frage ist aber eine
weiter gehende.
Wieso ist die ganze Software da draußen so unglaublich beschissen?
Er versicherte mir glaubwürdig, daß das bei Linux nicht anders aussieht,
und von Windows weiß ich, daß es nicht anders aussieht.
Das ist ja alles nicht zu fassen.
Ist das zuviel verlangt, wenn ich erwarte, daß ich einen USB Stick
reinstecken und mounten kann, den mir ein Typ auf einer Party in die
Hand drückt? (Und ich rede jetzt absichtlich nicht von Windoze
Autostart-Spielchen)
Fe "schlechte Laune" lix
Holger Marzen
> Dieses Programm hat er gestern abend mal auf ein UFS-Image angewendet,
> und hat nach drei Anläufen ein Image gehabt, das OpenBSD und NetBSD zu
> Panikattacken verleitet. Ich vermute dringend, daß auch FreeBSD und OS
> X abrauchen, wenn sie das zu mounten versuchen. Die Frage ist aber eine
> weiter gehende.
>
> Wieso ist die ganze Software da draußen so unglaublich beschissen?
Weil sie kompiliert ist.
Um einen Schutz vor Abstürzen zu haben, müsste man nicht nur alle Zeiger
verifizieren (ob sie auf was Sinnvolles zeigen, das dann wieder auf was
Sinnvolles zeigt), sondern auch noch jede Maschinenanweisung, ob sie
ungefährlich ist. Bei dem Zeigercheck käme bloß unglaublich lahme
Software raus, beim Check des Maschinencode muss der checkende Code ja
auch gecheckt werden -> Endlosrekursion.
Nur mal so ins Grobe gedacht, vor der ersten Tasse Kaffee.
Ignatios Souvatzis
> Ein Bekannter hat mal ein Trivial-Programm gehackt, das aus einer Datei
> in den ersten n Bytes m zufällige Veränderungen vornimmt. Damit rennt
> er los, wendet das auf Dateien an, und bringt Software zum Absturz. Ich
> nenne das zu faul zum anständigen Codelesen, aber in der
> Security-Industrie nennt sich das offenbar "fuzzing".
>
> Dieses Programm hat er gestern abend mal auf ein UFS-Image angewendet,
> und hat nach drei Anläufen ein Image gehabt, das OpenBSD und NetBSD zu
> Panikattacken verleitet.
_Nach_ einem erfolgreichen fsck?
> Ich vermute dringend, daß auch FreeBSD und OS
> X abrauchen, wenn sie das zu mounten versuchen. Die Frage ist aber eine
> weiter gehende.
>
> Wieso ist die ganze Software da draußen so unglaublich beschissen?
>
> Er versicherte mir glaubwürdig, daß das bei Linux nicht anders aussieht,
Auch ext2fs ist eine variante von UFS, hat mithin pointer-ähnliche
Metadaten-doppel (naja, redundante Information) im Superblock und den
Zylindergruppen - wenn du da etwas hinreichend widersprüchlich machst,
krachts. Deswegen ja der fsck, der es vor dem Mounten konsistent machen
soll. Wenn das nicht reicht, ist das allerdings ein Fehler.
> Ist das zuviel verlangt, wenn ich erwarte, daß ich einen USB Stick
> reinstecken und mounten kann, den mir ein Typ auf einer Party in die
> Hand drückt? (Und ich rede jetzt absichtlich nicht von Windoze
> Autostart-Spielchen)
Da würde ich _maximal_ ein tar oder ein FAT - und auch letzteres nur mit
mtools - anfassen. Du spritzt doch auch nicht jede Droge intravenös, die
dir jemand auf einer Party anbietet?
Tschö
-is
--
seal your e-mail: http://www.gnupg.org/
Harald Wenninger
> Um einen Schutz vor Abstürzen zu haben, müsste man nicht nur alle Zeiger
> verifizieren (ob sie auf was Sinnvolles zeigen, das dann wieder auf was
> Sinnvolles zeigt), sondern auch noch jede Maschinenanweisung, ob sie
> ungefährlich ist. Bei dem Zeigercheck käme bloß unglaublich lahme
> Software raus, beim Check des Maschinencode muss der checkende Code ja
> auch gecheckt werden -> Endlosrekursion.
<delurk>
Naja, es gibt sowas wie "Proof Carrying Code", der in etwa das macht, was du
vorschlägst. Aber auch hier: Wer beweist den Beweiser?
</delurk>
Gruß,
Harald
--
Trying is the first step towards failure.
Homer Simpson
Lutz Donnerhacke
> Um einen Schutz vor Abstürzen zu haben, müsste man nicht nur alle Zeiger
> verifizieren (ob sie auf was Sinnvolles zeigen, das dann wieder auf was
> Sinnvolles zeigt), sondern auch noch jede Maschinenanweisung, ob sie
> ungefährlich ist.
Bullshit.
Juergen P. Meier
> Wieso ist die ganze Software da draußen so unglaublich beschissen?
Weil Programmierer nunmal zum einen Faul sind, zum anderen Gutglaeubig?
> Er versicherte mir glaubwürdig, daß das bei Linux nicht anders aussieht,
> und von Windows weiß ich, daß es nicht anders aussieht.
Ach. Es ist *ueberall* so. Und welch Wunder - nicht einmal nur in der
IT Welt!
Beschicke doch mal ein elektronisches Geraet (!Computer) deiner Wahl
mit einem Eingangsstrom von 20 statt 50 HZ Wechselstrom (Mach das
bitte in einem Feuerfesten Raum mit guter Entlueftung).
> Das ist ja alles nicht zu fassen.
Nur wenn man in einem Elfenbeinturm mit Fenstern aus Milchglas lebt.
> Ist das zuviel verlangt, wenn ich erwarte, daß ich einen USB Stick
> reinstecken und mounten kann, den mir ein Typ auf einer Party in die
> Hand drückt? (Und ich rede jetzt absichtlich nicht von Windoze
> Autostart-Spielchen)
Nein. Aber es ist zuviel verlangt, wenn du erwartest, dass dabei
nichts kaputtgehen kann.
> Fe "schlechte Laune" lix
Dagegen hilft Abschalten (den Computer vor dem du sitzt) und in den
grossen Blauen Raum gehen.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Peter Heitzer
>* On 13 Jun 2006 02:02:26 GMT, Felix von Leitner wrote:
>> Dieses Programm hat er gestern abend mal auf ein UFS-Image angewendet,
>> und hat nach drei Anläufen ein Image gehabt, das OpenBSD und NetBSD zu
>> Panikattacken verleitet. Ich vermute dringend, daß auch FreeBSD und OS
>> X abrauchen, wenn sie das zu mounten versuchen. Die Frage ist aber eine
>> weiter gehende.
>>
>> Wieso ist die ganze Software da draußen so unglaublich beschissen?
>Weil sie kompiliert ist.
>Um einen Schutz vor Abstürzen zu haben, müsste man nicht nur alle Zeiger
>verifizieren (ob sie auf was Sinnvolles zeigen, das dann wieder auf was
>Sinnvolles zeigt), sondern auch noch jede Maschinenanweisung, ob sie
>ungefährlich ist. Bei dem Zeigercheck käme bloß unglaublich lahme
Also bei einem Mount sollte die Filesystemstruktur schon vorher auf
Plausibilität geprüft werden. Das dürfte keine grossen Performanceeinbussen
hervorrufen.
--
Dipl.-Inform(FH) Peter Heitzer, peter....@rz.uni-regensburg.de
HTML mails will be forwarded to /dev/null.
Christian Hoffmann
Holger Marzen wrote:
> Bei dem Zeigercheck käme bloß unglaublich lahme
> Software raus, beim Check des Maschinencode muss der checkende Code ja
> auch gecheckt werden -> Endlosrekursion.
>
> Nur mal so ins Grobe gedacht, vor der ersten Tasse Kaffee.
...oder Computer mit Rückwärtsgang?
Christian
Falk Willberg
>> Er versicherte mir glaubwürdig, daß das bei Linux nicht anders aussieht,
>> und von Windows weiß ich, daß es nicht anders aussieht.
>
> Ach. Es ist *ueberall* so. Und welch Wunder - nicht einmal nur in der
> IT Welt!
>
> Beschicke doch mal ein elektronisches Geraet (!Computer) deiner Wahl
> mit einem Eingangsstrom von 20 statt 50 HZ Wechselstrom (Mach das
> bitte in einem Feuerfesten Raum mit guter Entlueftung).
Lass die Entlüftung weg und beobachte mal, was bei 5% CO2 passiert. Das
System (Mensch) verreckt einfach, obwohl genügend O2 vorhanden ist. Und
das ist nicht nur bei Menschen so!elf
Falk
Falk Willberg
> Ein Bekannter hat mal ein Trivial-Programm gehackt, das aus einer Datei
> in den ersten n Bytes m zufällige Veränderungen vornimmt. Damit rennt
> er los, wendet das auf Dateien an, und bringt Software zum Absturz.
Wow, super! Ich kenne einen, der füllt Diesel in Benziner-Tanks und
freut sich, wenn die Motoren verrecken.
> Ich nenne das zu faul zum anständigen Codelesen, aber in der
> Security-Industrie nennt sich das offenbar "fuzzing".
Ich würde das als "Realität" beschreiben.
> Wieso ist die ganze Software da draußen so unglaublich beschissen?
Du hast die Chance, das zu ändern:
http://www.heise.de/newsticker/meldung/74156 ;-)
Falk
Erhard Schwenk
> * On 13 Jun 2006 02:02:26 GMT, Felix von Leitner wrote:
>>Wieso ist die ganze Software da draußen so unglaublich beschissen?
> Weil sie kompiliert ist.
Naja.
> Um einen Schutz vor Abstürzen zu haben, müsste man nicht nur alle Zeiger
> verifizieren (ob sie auf was Sinnvolles zeigen, das dann wieder auf was
> Sinnvolles zeigt),
Stimmt so nicht ganz. Man kann auch einfach eine Sprache benutzen, die
das direkte Manipulieren von Zeigern gar nicht erst zuläßt. Dann reicht
es, die Runtime-Library und den Compiler zu verifizieren sowie zur
Laufzeit auf Null-Pointer zu checken. Der Ansatz z.B. von Java geht in
diese Richtung.
Das heißt natürlich nicht, daß man in Java keine Fehler macht, aber zur
Produktion von Buffer Overflows mit Code Injection muß man schon
ziemlich mutwillig was falsch machen.
Das wesentliche Problem ist dabei vor Allem die Verifikation der
Runtime-Library. Aber trotzdem ist das Problem schon deutlich eingeschränkt.
> sondern auch noch jede Maschinenanweisung, ob sie
> ungefährlich ist.
Prinzipiell reicht es, zu verifizieren, daß der Compiler nur
"ungefährliche" Maschinenanweisungen produziert und daß das Programm
nicht mehr anderweitig modifiziert wurde.
> Bei dem Zeigercheck käme bloß unglaublich lahme
> Software raus,
Naja, Java ist nicht unbedingt für Geschwindigkeit berühmt, allerdings
ist das mehr ein Gerücht als Realität. Bei Einzelanwendungen dauert es
halt, bis die Runtime geladen und der Hotspot angelaufen ist. Aber z.B.
JSP sind durchaus performanter als PHP oder in Webseiten eingebettetes
Perl. Und die meisten proprietären 4GL-Tools, die die Hauptkonkurrenz
von J2EE darstellen, sind auch nicht performanter.
> beim Check des Maschinencode muss der checkende Code ja
> auch gecheckt werden -> Endlosrekursion.
> Nur mal so ins Grobe gedacht, vor der ersten Tasse Kaffee.
Da gibts schon Verfahren, die sind aber ziemlich aufwendig.
--
Erhard Schwenk
Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de/
APAYA running System - http://www.apaya.net/
Erhard Schwenk
> Holger Marzen <hol...@marzen.de> wrote:
>
>>* On 13 Jun 2006 02:02:26 GMT, Felix von Leitner wrote:
>
>
>>>Dieses Programm hat er gestern abend mal auf ein UFS-Image angewendet,
>>>und hat nach drei Anläufen ein Image gehabt, das OpenBSD und NetBSD zu
>>>Panikattacken verleitet. Ich vermute dringend, daß auch FreeBSD und OS
>>>X abrauchen, wenn sie das zu mounten versuchen. Die Frage ist aber eine
>>>weiter gehende.
>>>
>>>Wieso ist die ganze Software da draußen so unglaublich beschissen?
>
>
>>Weil sie kompiliert ist.
>
>
>>Um einen Schutz vor Abstürzen zu haben, müsste man nicht nur alle Zeiger
>>verifizieren (ob sie auf was Sinnvolles zeigen, das dann wieder auf was
>>Sinnvolles zeigt), sondern auch noch jede Maschinenanweisung, ob sie
>>ungefährlich ist. Bei dem Zeigercheck käme bloß unglaublich lahme
>
>
> Also bei einem Mount sollte die Filesystemstruktur schon vorher auf
> Plausibilität geprüft werden. Das dürfte keine grossen Performanceeinbussen
> hervorrufen.
Du willst vor jedem Mount nen fsck -f machen? Und das bezeichnest Du
dann als "keine großen Performanceeinbußen"?
Joerg Hoh
> Also bei einem Mount sollte die Filesystemstruktur schon vorher auf
> Plausibilität geprüft werden. Das dürfte keine grossen Performanceeinbussen
> hervorrufen.
einen fsck beim Mounten? Ich möchte irgendwann auch mal noch arbeiten
und nicht nur der Kiste beim Booten zuschauen.
Gruß
Jörg
--
What did you do to the cat? It looks half-dead. -Schroedinger's wife
Marc Haber
>Peter Heitzer wrote:
>> Also bei einem Mount sollte die Filesystemstruktur schon vorher auf
>> Plausibilität geprüft werden. Das dürfte keine grossen Performanceeinbussen
>> hervorrufen.
>
>Du willst vor jedem Mount nen fsck -f machen? Und das bezeichnest Du
>dann als "keine großen Performanceeinbußen"?
Nicht jedes Filesystem ist beim fsck so uneffektiv wie ext[23].
Grüße
Marc, der unter anderem aus diesem Grund auf dem Notebook XFS
einsetzt. Nur das rootfilesystem ist noch ext3.
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Alexander Schreiber
Freundlich formuliert: grober Unfug.
Grundsätzlich muß man, um die von Felix beschriebenen Katastrophen
zu verhindern, einfach nur ordentlich arbeiten[0]. Und das schließt u.a.
ein, daß man eingelesene Daten nicht einfach verwendet ("wird schon
passen"), sondern sie so weit wie sinnvoll auf Korrektheit prüft. Das
man nicht über das Ende (oder den Anfang) von Datenstrukturen
drüberschreibt, sondern vorher entsprechend prüft und vieles mehr.
Das verlangt dummerweise wesentlich mehr Erfahrung, Wissen, Disziplin
und Sorgfalt als die meisten Programmierer haben. Von den zusätzlichen
Einflußfaktoren bei kommerzieller Software mal ganz abgesehen.
Geeignete Werkzeuge können dabei viel helfen[1]. Und nein, C gehört
schlicht nicht in die Hände durchschnittlicher Programmierer.
> Nur mal so ins Grobe gedacht, vor der ersten Tasse Kaffee.
Das merkt man.
Man liest sich,
Alex.
[0] Höre ich hier ein höhnisches Gelächter?
[1] Lutz? *g*
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Dietz Proepper
^^^
dd if=baz.tar of=/dev/sda ? Warum eigentlich nicht...
Dietz Proepper
> Ein Bekannter hat mal ein Trivial-Programm gehackt, das aus einer Datei
> in den ersten n Bytes m zufällige Veränderungen vornimmt. Damit rennt
> er los, wendet das auf Dateien an, und bringt Software zum Absturz. Ich
> nenne das zu faul zum anständigen Codelesen, aber in der
> Security-Industrie nennt sich das offenbar "fuzzing".
>
> Dieses Programm hat er gestern abend mal auf ein UFS-Image angewendet,
> und hat nach drei Anläufen ein Image gehabt, das OpenBSD und NetBSD zu
> Panikattacken verleitet. Ich vermute dringend, daß auch FreeBSD und OS
> X abrauchen, wenn sie das zu mounten versuchen.
Dumme Frage - das ist doch seit mindestens +inf Jahren bekannt, oder? (Es hieß
zwar, man habe die Dateisystemtreiber überarbeitet, was davon bei ausreichend
komplexen Datenstrukturen zu halten ist weißt Du selber.)
Du würdest btw. so richtig kotzen wenn Du untersuchen würdest, wie wenig
Aufwand nötig ist, um über den Weg Codeinjektion zu betreiben...
> Die Frage ist aber eine weiter gehende.
Was ist an "never trust user input" neu? Was ist neu an der Aussage, daß dies,
wenn überhaupt, nur für einfache Protokolle (bzw. Datenstrukturen) anständig
gemacht wird?
Abgesehen davon, *seufz*.
Holger Marzen
Was macht man stattdessen?
Nein, Exceptions gelten nicht, denn die nötigen Routinen müssen designed
und hinterlegt werden, was letztlich nichts fundamental Anderes ist.
Holger Marzen
> Holger Marzen <hol...@marzen.de> wrote:
>>* On 13 Jun 2006 02:02:26 GMT, Felix von Leitner wrote:
>
>>> Dieses Programm hat er gestern abend mal auf ein UFS-Image angewendet,
>>> und hat nach drei Anläufen ein Image gehabt, das OpenBSD und NetBSD zu
>>> Panikattacken verleitet. Ich vermute dringend, daß auch FreeBSD und OS
>>> X abrauchen, wenn sie das zu mounten versuchen. Die Frage ist aber eine
>>> weiter gehende.
>>>
>>> Wieso ist die ganze Software da draußen so unglaublich beschissen?
>
>>Weil sie kompiliert ist.
>
>>Um einen Schutz vor Abstürzen zu haben, müsste man nicht nur alle Zeiger
>>verifizieren (ob sie auf was Sinnvolles zeigen, das dann wieder auf was
>>Sinnvolles zeigt), sondern auch noch jede Maschinenanweisung, ob sie
>>ungefährlich ist. Bei dem Zeigercheck käme bloß unglaublich lahme
>
> Also bei einem Mount sollte die Filesystemstruktur schon vorher auf
> Plausibilität geprüft werden. Das dürfte keine grossen Performanceeinbussen
> hervorrufen.
Also Zeiger verifizieren.
Holger Marzen
> Holger Marzen wrote:
>> * On 13 Jun 2006 02:02:26 GMT, Felix von Leitner wrote:
>
>>>Wieso ist die ganze Software da draußen so unglaublich beschissen?
>
>> Weil sie kompiliert ist.
>
> Naja.
>
>> Um einen Schutz vor Abstürzen zu haben, müsste man nicht nur alle Zeiger
>> verifizieren (ob sie auf was Sinnvolles zeigen, das dann wieder auf was
>> Sinnvolles zeigt),
>
> Stimmt so nicht ganz. Man kann auch einfach eine Sprache benutzen, die
> das direkte Manipulieren von Zeigern gar nicht erst zuläßt. Dann reicht
> es, die Runtime-Library und den Compiler zu verifizieren sowie zur
> Laufzeit auf Null-Pointer zu checken. Der Ansatz z.B. von Java geht in
> diese Richtung.
Haben wir da nicht schon wieder was Interpretiertes?
Holger Marzen
> Holger Marzen <hol...@marzen.de> wrote:
>> * On 13 Jun 2006 02:02:26 GMT, Felix von Leitner wrote:
>>
>>> Dieses Programm hat er gestern abend mal auf ein UFS-Image angewendet,
>>> und hat nach drei Anläufen ein Image gehabt, das OpenBSD und NetBSD zu
>>> Panikattacken verleitet. Ich vermute dringend, daß auch FreeBSD und OS
>>> X abrauchen, wenn sie das zu mounten versuchen. Die Frage ist aber eine
>>> weiter gehende.
>>>
>>> Wieso ist die ganze Software da draußen so unglaublich beschissen?
>>
>> Weil sie kompiliert ist.
>>
>> Um einen Schutz vor Abstürzen zu haben, müsste man nicht nur alle Zeiger
>> verifizieren (ob sie auf was Sinnvolles zeigen, das dann wieder auf was
>> Sinnvolles zeigt), sondern auch noch jede Maschinenanweisung, ob sie
>> ungefährlich ist. Bei dem Zeigercheck käme bloß unglaublich lahme
>> Software raus, beim Check des Maschinencode muss der checkende Code ja
>> auch gecheckt werden -> Endlosrekursion.
>
> Freundlich formuliert: grober Unfug.
>
> Grundsätzlich muß man, um die von Felix beschriebenen Katastrophen
> zu verhindern, einfach nur ordentlich arbeiten[0]. Und das schließt u.a.
> ein, daß man eingelesene Daten nicht einfach verwendet ("wird schon
> passen"), sondern sie so weit wie sinnvoll auf Korrektheit prüft. Das
Aha. Ist ja ganz was Neues. Hab ich auch nicht ein paar Zeilen weiter
oben geschrieben:
Andreas Lobinger
Holger Marzen wrote:
> * On 13 Jun 2006 02:02:26 GMT, Felix von Leitner wrote:
>>Dieses Programm hat er gestern abend mal auf ein UFS-Image angewendet,
>>und hat nach drei Anläufen ein Image gehabt, das OpenBSD und NetBSD zu
>>Panikattacken verleitet. Ich vermute dringend, daß auch FreeBSD und OS
>>X abrauchen, wenn sie das zu mounten versuchen. Die Frage ist aber eine
>>weiter gehende.
>>
>>Wieso ist die ganze Software da draußen so unglaublich beschissen?
> Weil sie kompiliert ist.
Du hast einen Buchstabendreher und es fehlt ein 'z'.
Einen fröhlichen Tag wünschend
LOBI
Mark Neis
>Naja, Java ist nicht unbedingt für Geschwindigkeit berühmt, allerdings
>ist das mehr ein Gerücht als Realität. Bei Einzelanwendungen dauert es
>halt, bis die Runtime geladen und der Hotspot angelaufen ist. Aber z.B.
>JSP sind durchaus performanter als PHP oder in Webseiten eingebettetes
>Perl. Und die meisten proprietären 4GL-Tools, die die Hauptkonkurrenz
>von J2EE darstellen, sind auch nicht performanter.
Mag ja sein, dass Java mittlerweile erträglich schnell geworden ist -
aber die Laufzeitumgebungen und "Application Server" sind unerträglich
instabil. Ich hatte schon Apachen hier, die liefen Jahre. Die Tomcats
hauts spätestens alle paar Wochen auf die Nase.
Mark
Lutz Donnerhacke
> * On Tue, 13 Jun 2006 06:33:25 +0000 (UTC), Lutz Donnerhacke wrote:
>> * Holger Marzen wrote:
>>> Um einen Schutz vor Abstürzen zu haben, müsste man nicht nur alle Zeiger
>>> verifizieren (ob sie auf was Sinnvolles zeigen, das dann wieder auf was
>>> Sinnvolles zeigt), sondern auch noch jede Maschinenanweisung, ob sie
>>> ungefährlich ist.
>>
>> Bullshit.
>
> Was macht man stattdessen?
Programmieren, statt stümpern. So schwer ist das nicht.
Selbst Fefe kann in C ein Protokoll wie LDAP parsen.
Joerg Hoh
> Erhard Schwenk <esch...@fto.de> wrote:
>>Peter Heitzer wrote:
>>> Also bei einem Mount sollte die Filesystemstruktur schon vorher auf
>>> Plausibilität geprüft werden. Das dürfte keine grossen Performanceeinbussen
>>> hervorrufen.
>>
>>Du willst vor jedem Mount nen fsck -f machen? Und das bezeichnest Du
>>dann als "keine großen Performanceeinbußen"?
>
> Nicht jedes Filesystem ist beim fsck so uneffektiv wie ext[23].
sieht das fsck.xfs nicht wie folgt aus?
#!/bin/sh
exit 0
Warum es dann extra Tools wie xfs_check und xfs_repair gibt, erschliesst
sich mir nicht ganz.
Ignatios Souvatzis
> Peter Heitzer schrieb
>> Also bei einem Mount sollte die Filesystemstruktur schon vorher auf
>> Plausibilität geprüft werden. Das dürfte keine grossen Performanceeinbussen
>> hervorrufen.
>
> einen fsck beim Mounten? Ich möchte irgendwann auch mal noch arbeiten
> und nicht nur der Kiste beim Booten zuschauen.
Das ist nur ein Problem, wenn du andauernd bootest ;-)
Helmut Springer
> sieht das fsck.xfs nicht wie folgt aus?
>
> #!/bin/sh
> exit 0
>
>
> Warum es dann extra Tools wie xfs_check und xfs_repair gibt,
> erschliesst sich mir nicht ganz.
Hard links auf mkfs.xfs aus Kompatibilitaetsgruenden?
--
MfG/Best regards
helmut springer
Falk Willberg
> Hard links auf mkfs.xfs aus Kompatibilitaetsgruenden?
Watt sind denn "hard links"? Die Gegenstücke zu symbolischen Links?
SCNR,
Falk
Gert Doering
>>> Plausibilit=E4t gepr=FCft werden. Das d=FCrfte keine grossen =
>Performanceeinbussen
>>> hervorrufen.
>>
>>Du willst vor jedem Mount nen fsck -f machen? Und das bezeichnest Du=20
>>dann als "keine gro=DFen Performanceeinbu=DFen"?
>Nicht jedes Filesystem ist beim fsck so uneffektiv wie ext[23].
Auch zur Laufzeit muss man gewisse Plausibilitaetschecks durchfuehren
("ist die angegebene Blocknummer innerhalb der Grenzen dieser Partition"),
die aber vergleichsweise minimalen Overhead mit sich bringen duerften.
Ansonsten ist mir ohnehin nicht klar, wie ein sauber programmierter
Filesystem-Treiber einen PANIC verursachen kann - andererseits habe ich
das bei FreeBSD ($alt) schon oefters gesehen, insofern geht es wohl...
gert
--
Wege entstehen, wenn wir sie gehen. | gert doering
Vielleicht sollte ich meinen Beobachterposten | ge...@greenie.muc.de
an der Strassenkreuzung aufgeben. | 2:2480/55.4
Michael Kamper
> Wieso ist die ganze Software da draußen so unglaublich beschissen?
Weil man sie im Nachhinein meist problemlos austauschen kann. Was so
manche Code-Schmiede an Patches raushaut, das könnte sich kein
Hardwarehersteller der Welt erlauben. Ganz davon abgesehen, dass wohl
ein Großteil der Software, die heutzutage released wird, defekt ist.
Gruß
Michael
Helmut Springer
> Watt sind denn "hard links"? Die Gegenstücke zu symbolischen Links?
man ln #aber Du weisst es ja anscheinend
Hilmar Steinhauer
> Ist das zuviel verlangt, wenn ich erwarte, daß ich einen USB Stick
> reinstecken und mounten kann, den mir ein Typ auf einer Party in die
> Hand drückt?
Nein. Aber warum lässt Du Dir trojanische Pferde andrehen?
SCNR,
Hilmar
Holger Marzen
Nein, "hard links" sind das Gegenstück zu "soft links", wogegen
"symbolische Links" das Gegenstück zu "marktüblichen Links" sind.
Arnim Sommer
A!S
Falk Willberg
...
> Nein, "hard links" sind das Gegenstück zu "soft links", wogegen
Also bspw. Schäkel vs. Gummiband?
> "symbolische Links" das Gegenstück zu "marktüblichen Links" sind.
s/marktüblichen//
Links gab es vor symbolischen solchen.
Falk
--
Wenn das letzte Haar gespalten, die letzte Erbse gezählt
und der letzte Paragraph geritten,
dann werden Ihr merken, daß man Korinthen auch essen kann.
Jens Link
> Nein, "hard links" sind das Gegenstück zu "soft links", wogegen
> "symbolische Links" das Gegenstück zu "marktüblichen Links" sind.
Ich bin weder Soft, noch symbolisch und schon gar nicht marktüblich.
Lasst also meinen Namen aus dem Spiel.
Jens, der gerade seinen zukünftigen Arbeitsplatz bestaunt hat.
--
sage@guug Berlin: http://www.guug.de/lokal/berlin/index.html
Hilmar Steinhauer
Peter Heitzer
>Also Zeiger verifizieren.
Ja.
--
Dipl.-Inform(FH) Peter Heitzer, peter....@rz.uni-regensburg.de
HTML mails will be forwarded to /dev/null.
Ralph Lehmann
> Arnim Sommer schrieb:
>
>> Hilmar Steinhauer wrote:
>>> Felix von Leitner schrieb:
>>>
>>>> Ist das zuviel verlangt, wenn ich erwarte, daß ich einen USB Stick
>>>> reinstecken und mounten kann, den mir ein Typ auf einer Party in die
>>>> Hand drückt?
>>>
>>> Nein. Aber warum lässt Du Dir trojanische Pferde andrehen?
>>>
>> Holz-USB-Sticks?
>
> Nö, eher so:
> http://www.heise.de/newsticker/meldung/74135
Mit Verlaub: Der Artikel lässt mich vermuten, dass die Opfer den
Keylogger von Hand gestartet haben. Beim Mounten selbst sollte (ohne
Autostart) nix passieren.
F'up2 dcsm
ciao Ralph
Alexander Schreiber
*seufz*
C ist nicht die einzige Programmiersprache. Und die besondere Krankheit
von C, daß Arrayzugriff == direkte Pointerfrickelei, haben zum Glück auch
nicht alle kopiert.
HTH,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Christoph Kliemt
> Holger Marzen <hol...@marzen.de> wrote:
>>* On 13 Jun 2006 07:34:32 GMT, Peter Heitzer wrote:
>
>>> Holger Marzen <hol...@marzen.de> wrote:
>>>>* On 13 Jun 2006 02:02:26 GMT, Felix von Leitner wrote:
>>>
>>>>> Dieses Programm hat er gestern abend mal auf ein UFS-Image
>>>>> angewendet, und hat nach drei Anläufen ein Image gehabt, das
>>>>> OpenBSD und NetBSD zu Panikattacken verleitet. Ich vermute
>>>>> dringend, daß auch FreeBSD und OS X abrauchen, wenn sie das zu
>>>>> mounten versuchen. Die Frage ist aber eine weiter gehende.
[...]
>>> Also bei einem Mount sollte die Filesystemstruktur schon vorher auf
>>> Plausibilität geprüft werden. Das dürfte keine grossen
>>> Performanceeinbussen hervorrufen.
>
>>Also Zeiger verifizieren.
> Ja.
Ich denke, damit ist die Frage des OP nach dem "warum" beantwortet.
*röchel*
gruss Christoph
Alexander Schreiber
Klares, eindeutiges Jain.
Es gibt Java-Umgebungen, die laufen als reine Interpreter des
Java-Bytecodes, welche die hinten fertige native Executables ausspucken
und alle möglichen Formen dazwischen. Gerade wenn der Code auch schnell
sein soll, dann wird üblicherweise irgendwann irgendwo Maschinencode
draus gemacht.
Man liest sich,
Markus Brueckner
> Felix von Leitner schrieb:
>> Ein Bekannter hat mal ein Trivial-Programm gehackt, das aus einer Datei
>> in den ersten n Bytes m zufällige Veränderungen vornimmt. Damit rennt
>> er los, wendet das auf Dateien an, und bringt Software zum Absturz.
>
> Wow, super! Ich kenne einen, der füllt Diesel in Benziner-Tanks und
> freut sich, wenn die Motoren verrecken.
Du wirst lachen: so einfach ist das (zumindest in eine Richtung) gar
nicht. Und jetzt rat mal, wieso.
Bis dann
Markus
--
>Und *BSD ist wie fischertechnik.
Haesslich, aber viele Zahnraeder?
Jan Völkers und Gert Doering in dasr
Ulrich Schwarz
[...]
> Grundsätzlich muß man, um die von Felix beschriebenen Katastrophen
> zu verhindern, einfach nur ordentlich arbeiten[0]. Und das schließt u.a.
> ein, daß man eingelesene Daten nicht einfach verwendet ("wird schon
> passen"), sondern sie so weit wie sinnvoll auf Korrektheit prüft. Das
> man nicht über das Ende (oder den Anfang) von Datenstrukturen
> drüberschreibt, sondern vorher entsprechend prüft und vieles mehr.
>
> Das verlangt dummerweise wesentlich mehr Erfahrung, Wissen, Disziplin
, Zeit, Anerkennung (oder Einkommen, nach Ausrichtung)
> und Sorgfalt als die meisten Programmierer haben. Von den zusätzlichen
> Einflußfaktoren bei kommerzieller Software mal ganz abgesehen.
> [0] Höre ich hier ein höhnisches Gelächter?
Ich war lange genug Hiwi. Ich befürchte, die Unis lassen B.Sc. (Inf)s
los, die nicht mal in der Lage wären, systematisches Debugging zu
machen, geschweige denn, von vorn herein halbwegs robust zu
programmieren. (Keine formale Verifikation mehr, Matheausbildung
verwässert.)
Ulrich
Ooooooh, gutes Krümelmonster!
--
The fact that programs written for these systems work should not be
taken as a sign of intelligence, wisdom, or skill in the authors, but
rather as an indication of the existence of a kind and benevolent God.
-- On Perl 5.003_05 and GCC 2.7.2.3 (Author known)
Ulrich Schwarz
> Aloha,
>
> Holger Marzen wrote:
>
>> * On 13 Jun 2006 02:02:26 GMT, Felix von Leitner wrote:
[...]
>>>Wieso ist die ganze Software da draußen so unglaublich beschissen?
>> Weil sie kompiliert ist.
>
> Du hast einen Buchstabendreher und es fehlt ein 'z'.
"Interpretiertes Programm:
Was wollte uns der Autor damit sagen? Na, wenigstens ist es nicht so
kompiliziert."
Ulrich
--
struct a{typedef int foo;};struct a1:a{};struct a2:a{};
#define X(b,a) struct a##1:b##1,b##2{};struct a##2:b##1,b##2{};
X(a,b)X(b,c)X(c,d)X(d,e)X(e,f)X(f,g)X(g,h)X(h,i)X(i,j)X(j,k)X(k,l)
X(l,m)X(m,n) n1::foo main(){} /* -- /bin/true-Clone von SR. Testen! */
Lothar Kimmeringer
> * On Tue, 13 Jun 2006 10:00:09 +0200, Erhard Schwenk wrote:
>>
>> Stimmt so nicht ganz. Man kann auch einfach eine Sprache benutzen, die
>> das direkte Manipulieren von Zeigern gar nicht erst zulنكt. Dann reicht
>> es, die Runtime-Library und den Compiler zu verifizieren sowie zur
>> Laufzeit auf Null-Pointer zu checken. Der Ansatz z.B. von Java geht in
>> diese Richtung.
>
> Haben wir da nicht schon wieder was Interpretiertes?
Seit ca. 8 Jahren eigentlich nicht mehr. Zwar produziert der
Compiler Bytecode, vom Hotspot der Runtime werden die zeitkritischen
Passagen zur Laufzeit aber in Maschinencode umgewandelt (und dabei
zum Teil evtl. veraendert, wenn z.B. festgestellt wird, dass
der "then"-Zweig einer if Anweisung seltener zum Zuge kommt, als
der "else"-Zweig.
Das kann mitunter sogar dazu fuehren, dass eine Javaanwendung
nach einer Weile schneller laeuft als eine C-Anwendung.
Der Nachteil dabei ist aber, dass eine Javaanwendung erst "warm-
laufen" muss, bevor aussagekraeftige Performancetests gemacht
werden koennen.
Fuer die Serverprogrammierung finde ich Java aber die im Vergleich
zu C bessere der beiden Sprachen, da damit Themen wie Buffer
Overflow und was es da so gibt, prinzipiell nicht moeglich sind.
Im schlimmsten Fall kommt es zu einer ArrayIndexOutOfBoundsException,
die - wenn mach echt viel falsch macht - den kompletten Prozess in
den Abgrund reisst. Normalerweise erwischt es aber nur den
entsprechende RequestThread, das ganze landet sauber in einem
Logfile (inkl. Stacktrace, der auch gleich die Zeilennummer
in der Source anzeigt, wo man Mist gebaut hat) und einer neuer
Thread wird aufgebaut, der dann wieder auf Eingangsdaten wartet.
Gruesse, Lothar
--
Lothar Kimmeringer E-Mail: spam...@kimmeringer.de
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)
Always remember: The answer is forty-two, there can only be wrong
questions!
Lothar Kimmeringer
> Holger Marzen wrote:
>
>>>Wieso ist die ganze Software da draußen so unglaublich beschissen?
>> Weil sie kompiliert ist.
>
> Du hast einen Buchstabendreher und es fehlt ein 'z'.
Und jetzt wo Du das schreibst, stelle ich fest, dass ich obiges
die ganze Zeit falsch gelesen habe (naemlich so, wie Du das
gerade korrigiert hast).
Lothar Kimmeringer
> dd if=baz.tar of=/dev/sda ? Warum eigentlich nicht...
Eine Disk ist ja auch nichts anderes als ein sehr dicht
aufgewickeltes Band, das man auf der Bandseite beschreibt, oder?
Falk Willberg
> Gerade wenn der Code auch schnell
> sein soll, dann wird üblicherweise irgendwann irgendwo Maschinencode
> draus gemacht.
Ohne geht es ja auch selten. Dabei ist Assembler¹ bah: GOTO, ON $VAR
GOTO, GOSUB und vielleicht 4 Datentypen.
Bei Zeile 200 habe ich dann auf C gewechselt. Mein RAM, mein ROM, mein
Prozessor: A byte saved is a minute wasted.
Falk
¹) Ich weiß, Maschinencode != Assembler
--
Du suchst eine schöne Programmiersprache? Dann nimm Assembler. Einen Tag
lang, danach sind alle andern schön.
Falk Willberg
> Falk Willberg <Fawegl...@falk-willberg.de> writes:
>
>> Felix von Leitner schrieb:
>>> Ein Bekannter hat mal ein Trivial-Programm gehackt, das aus einer Datei
>>> in den ersten n Bytes m zufällige Veränderungen vornimmt. Damit rennt
>>> er los, wendet das auf Dateien an, und bringt Software zum Absturz.
>> Wow, super! Ich kenne einen, der füllt Diesel in Benziner-Tanks und
>> freut sich, wenn die Motoren verrecken.
>
> Du wirst lachen: so einfach ist das (zumindest in eine Richtung) gar
> nicht. Und jetzt rat mal, wieso.
Wie beim Sex: Es kommt nicht auf die Länge an, sondern..... aber das
hatten wir ja schon...
Mittels geeigneter Adapter lässt sich aber alles in jedes füllen. Sogar
Erdgas in einen Propangastank. Ist ein paar Jahre her: 2 Tote.
Es mal jemand geschafft haben, einen Smart auf der linken Seite zu
tanken. Gut, der Verschluß ging schlecht ab und der Motor war sofort
hinüber. Bis zum Anlassen ging aber alles gut.
Falk
Arnim Sommer
> Holger Marzen <hol...@marzen.de> writes:
>
>
>>Nein, "hard links" sind das Gegenstück zu "soft links", wogegen
>>"symbolische Links" das Gegenstück zu "marktüblichen Links" sind.
>
>
> Ich bin weder Soft, noch symbolisch und schon gar nicht marktüblich.
> Lasst also meinen Namen aus dem Spiel.
>
A!S
--
In der Stadt lebt man zu seiner Unterhaltung, auf dem Lande zur
Unterhaltung der anderen.
-- Oscar Wilde
Falk Willberg
> Jens Link schrieb:
>> Holger Marzen <hol...@marzen.de> writes:
>>
>>
>>> Nein, "hard links" sind das Gegenstück zu "soft links", wogegen
>>> "symbolische Links" das Gegenstück zu "marktüblichen Links" sind.
>>
>> Ich bin weder Soft, noch symbolisch und schon gar nicht marktüblich.
>> Lasst also meinen Namen aus dem Spiel.
>>
> Du bist also ein ganz harter...
Können wir ausprobieren:
1)
ln /tmp/datei /tmp/Link
rm /tmp/Link
2)
ln -s /tmp/datei /tmp/Link
rm /tmp/Link
Welches hat wehgetan?
frank paulsen
> Eine Disk ist ja auch nichts anderes als ein sehr dicht
> aufgewickeltes Band, das man auf der Bandseite beschreibt, oder?
Stirnseite
Jens Link
> Du bist also ein ganz harter...
ABER SICHER IHR LUSCHEN! ICH MACH EUCH RUND! WENN ICH EUCH ALS
MITARBEITER BEKOMME, DANN WIRD HIER NICHT MEHR RUMGEGAMMELT! DANN
ADMINISTRIERT IHR ALLE RICHTIGE SERVER! WINDOWS! ABER ZACK ZACK!
ICH HAB MENSCHENFÜHRUNG BEIM BUND GELERNT! WER NICHT SPURT KOMMT IN DEN
BAU! BEI WASSER UND BROT!
Jens
Falk Willberg
ooo
da fehlt ein !elf !elf
Ignatios Souvatzis
> Auch zur Laufzeit muss man gewisse Plausibilitaetschecks durchfuehren
> ("ist die angegebene Blocknummer innerhalb der Grenzen dieser Partition"),
> die aber vergleichsweise minimalen Overhead mit sich bringen duerften.
Die macht nicht der Filesystemcode, sondern der Gerätetreiber....
> Ansonsten ist mir ohnehin nicht klar, wie ein sauber programmierter
> Filesystem-Treiber einen PANIC verursachen kann - andererseits habe ich
> das bei FreeBSD ($alt) schon oefters gesehen, insofern geht es wohl...
Division durch 0, oder overflow, glaube ich, bei der Auswertung
irgendwelcher abstruser Parameter, die bei antiken BSD-UFS-Varianten der
Minimierung mechanischer Verzögerungen dienten. Mit Zone Bit Recording
theoretisch obsolet, aber erst FFSv2 (WIMNI) hat sie tatsächlich entfernt.
-is
Arnim Sommer
Manchmal sind Flashbacks irgendwie seltsam... Ich mußte gerade an irgendeinen
SF-Roman denken, in dem das Gedächtnis eines Menschen auf vier $bänder
gespeichert wird; der Erfinder der $bänder stirbt, die $bänder werden verkauft,
kommen wieder zusammen und das Gedächtnis wird in einen neuen Körper transferiert...
A!S
--
Zuviel Enthusiasmus in der Tugend macht auf den folgenden Augenblick
desto kälter und schadet also.
-- Jean Paul
Ulrich Schwarz
> Es mal jemand geschafft haben, einen Smart auf der linken Seite zu
> tanken. Gut, der Verschluß ging schlecht ab und der Motor war sofort
> hinüber. Bis zum Anlassen ging aber alles gut.
-v bitte. Fahrgastraum wird's ja wohl nicht gewesen sein, oder?
Ulrich
--
Tobias, wenn du nicht endlich mit deiner SCHEIß-positiven Einstellung
und diesem Gänseblümchenzeug aufhörst, kaufe ich eine Rasenmäher und
nagel ihn dir an die Decke!!!
-- Ilja, auf www.aschgrau.de
Erhard Schwenk
> Peter Heitzer schrieb
>
>>Also bei einem Mount sollte die Filesystemstruktur schon vorher auf
>>Plausibilität geprüft werden. Das dürfte keine grossen Performanceeinbussen
>>hervorrufen.
>
>
> und nicht nur der Kiste beim Booten zuschauen.
Booten tut man doch eh nur nach Stromausfall ;)
--
Erhard Schwenk
Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de/
APAYA running System - http://www.apaya.net/
Ignatios Souvatzis
> Manchmal sind Flashbacks irgendwie seltsam... Ich mußte gerade an irgendeinen
> SF-Roman denken, in dem das Gedächtnis eines Menschen auf vier $bänder
> gespeichert wird; der Erfinder der $bänder stirbt, die $bänder werden verkauft,
> kommen wieder zusammen und das Gedächtnis wird in einen neuen Körper transferiert...
Von der Sorte gibt's zwei:
John Sladek, Der Müller-Fokker-Effekt und noch eins, das nicht am Regalende
1m von meinem Auge entfernt steht und an dessen Name ich mich jetzt nicht
erinnere.
-is
Holger Marzen
> Falk Willberg <Fawegl...@falk-willberg.de> writes:
>
>> Es mal jemand geschafft haben, einen Smart auf der linken Seite zu
>> tanken. Gut, der Verschluß ging schlecht ab und der Motor war sofort
>> hinüber. Bis zum Anlassen ging aber alles gut.
>
> -v bitte. Fahrgastraum wird's ja wohl nicht gewesen sein, oder?
Ist ein Fahrgas-Traum der Zustand, in den man gerät, wenn Gas aus dem
Tank in den Fahrgast-Raum gerät?
Erhard Schwenk
> * On Tue, 13 Jun 2006 10:00:09 +0200, Erhard Schwenk wrote:
>
>
>>Holger Marzen wrote:
>>
>>
>>>>Wieso ist die ganze Software da draußen so unglaublich beschissen?
>>
>>>Weil sie kompiliert ist.
>>
>>
>>
>>>Um einen Schutz vor Abstürzen zu haben, müsste man nicht nur alle Zeiger
>>>verifizieren (ob sie auf was Sinnvolles zeigen, das dann wieder auf was
>>>Sinnvolles zeigt),
>>
>>Laufzeit auf Null-Pointer zu checken. Der Ansatz z.B. von Java geht in
>>diese Richtung.
>
>
> Haben wir da nicht schon wieder was Interpretiertes?
Nein. Die Java-VM ist kein Interpreter, sondern eine virtuelle Maschine,
die Bytecode versteht. Der Bytecode hat aber mit den Java-Sourcen direkt
relativ wenig zu tun. Man könnte das Konzept prinzipiell (wenn auch
nicht ganz identisch mit Java) auch so umsetzen, daß anstatt Bytecode
hinten Maschinencode oder Asm rausfällt. Nur wäre dann natürlich das
Compilat nicht mehr portabel.
Falk Willberg
> Falk Willberg <Fawegl...@falk-willberg.de> writes:
>
>> Es mal jemand geschafft haben, einen Smart auf der linken Seite zu
>> tanken. Gut, der Verschluß ging schlecht ab und der Motor war sofort
>> hinüber. Bis zum Anlassen ging aber alles gut.
>
> -v bitte. Fahrgastraum wird's ja wohl nicht gewesen sein, oder?
Nein, siehe hierą: http://f23.parsimony.net/forum49387/messages/143153.htm
Falk
ą) Das Betrachten von WEBSeiten in der Schwangerschaft schadet Ihrem Kind
Arnim Sommer
irgendwie bekannt an...
A!S
--
Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.
frank paulsen
> Nein. Die Java-VM ist kein Interpreter, sondern eine virtuelle
> Maschine, die Bytecode versteht.
ein bytecode-interpreter ist also kein interpreter?
du solltest auf zebrastreifen vorsichtig sein...
--
frobnicate foo
Felix von Leitner
> Programmieren, statt stümpern. So schwer ist das nicht.
> Selbst Fefe kann in C ein Protokoll wie LDAP parsen.
Ich nehme das mal als Kompliment.
Felix von Leitner
> Nicht jedes Filesystem ist beim fsck so uneffektiv wie ext[23].
XFS ist in etwa genau so schnell wie ext3, aber bei ext3 gibt es Grund
für Vertrauen in den fsck. Mir erschließt sich nicht, wieso jemand XFS
haben wollen würde, mal ganz ehrlich.
Felix
Felix von Leitner
> Stimmt so nicht ganz. Man kann auch einfach eine Sprache benutzen, die
> das direkte Manipulieren von Zeigern gar nicht erst zuläßt. Dann reicht
> es, die Runtime-Library und den Compiler zu verifizieren sowie zur
> Laufzeit auf Null-Pointer zu checken. Der Ansatz z.B. von Java geht in
> diese Richtung.
Ach weißt du, alleine die VM von Sun hatte schon mehr Sicherheitslöcher
als alle meine gesammelte Software zusammen.
> Prinzipiell reicht es, zu verifizieren, daß der Compiler nur
> "ungefährliche" Maschinenanweisungen produziert und daß das Programm
> nicht mehr anderweitig modifiziert wurde.
Vielen Dank für diese tiefschürfende Einsicht.
Komm doch bitte zurück, sobald du dich mal mit Compilern und
Maschinenanweisungen beschäftigt hast.
Meine Einstellung ist da zwar ähnlich praxisfern, aber zumindest
funktionierte sie, wenn wir sie mal umsetzen würden:
"Wir müssen einfach aufhören, Fehler zu machen"
HTH. HAND.
Felix
Felix von Leitner
> die Bytecode versteht.
sigged.
Felix von Leitner
> Mag ja sein, dass Java mittlerweile erträglich schnell geworden ist -
Diese Sorge ist völlig unbegründet.
Felix von Leitner
> > Dieses Programm hat er gestern abend mal auf ein UFS-Image angewendet,
> > und hat nach drei Anläufen ein Image gehabt, das OpenBSD und NetBSD zu
> > Panikattacken verleitet.
> _Nach_ einem erfolgreichen fsck?
Nein. USB Stick einlegen, mounten, panic.
> Auch ext2fs ist eine variante von UFS, hat mithin pointer-ähnliche
> Metadaten-doppel (naja, redundante Information) im Superblock und den
> Zylindergruppen - wenn du da etwas hinreichend widersprüchlich machst,
> krachts.
Es gibt keinen Grund, wieso das krachen muß. Offsets prüft man vor der
Benutzung, und schon kracht da gar nichts.
> Deswegen ja der fsck, der es vor dem Mounten konsistent machen
> soll. Wenn das nicht reicht, ist das allerdings ein Fehler.
Also als ich das letzte Mal geguckt habe, hat man erst die
Root-Partition read-only gemounted (an dieser Stelle kommt die
beschriebene Panik), dann hat man von dieser Partition fsck geladen, und
damit dann eventuell ein fsck durchgeführt.
Das von mir bemängelte Problem ist ja gerade, daß es nicht soweit kommt.
Wobei ich nicht ausschließen wollen würde, daß auch fscks zu Segfaults
zu überreden sind. Das müßte mal jemand prüfen. Mal schauen, ob ich im
August genug Zeit dafür habe.
> > Ist das zuviel verlangt, wenn ich erwarte, daß ich einen USB Stick
> > reinstecken und mounten kann, den mir ein Typ auf einer Party in die
> > Hand drückt? (Und ich rede jetzt absichtlich nicht von Windoze
> > Autostart-Spielchen)
> Da würde ich _maximal_ ein tar oder ein FAT - und auch letzteres nur mit
> mtools - anfassen. Du spritzt doch auch nicht jede Droge intravenös, die
> dir jemand auf einer Party anbietet?
Ach und du meinst mtools können da nicht abrauchen und bei dir Code
ausführen? Und womöglich sind die Devices sauber geschützt, so daß
mtools als root laufen muß?
Felix
Felix von Leitner
> Du hast die Chance, das zu ändern:
> http://www.heise.de/newsticker/meldung/74156 ;-)
Habe ich heute morgen gesehen und gleich mal was eingereicht :)
Felix von Leitner
> Dumme Frage - das ist doch seit mindestens +inf Jahren bekannt, oder?
Ich habe da so eine Policy. Infrastrukturteile, für die ich keinen
Ersatz habe, gucke ich mir nicht so genau an, daß mich eventuell zu
gewinnende Erkenntnisse dazu bringen würden, ihren Einsatz umgehend
zu terminieren.
Und im Übrigen bin ich kein BSD-User, insofern ging mir UFS bisher voll
am Arsch vorbei.
> (Es hieß zwar, man habe die Dateisystemtreiber überarbeitet, was davon
> bei ausreichend komplexen Datenstrukturen zu halten ist weißt Du
> selber.)
Ich habe für soetwas kein Verständnis. So gar nicht. Niemand zwingt
die Leute, ihre Datenstrukturen besonders komplex zu machen. Wenn sie
es trotzdem tun, haben sie die Konsequenzen zu tragen.
> Du würdest btw. so richtig kotzen wenn Du untersuchen würdest, wie wenig
> Aufwand nötig ist, um über den Weg Codeinjektion zu betreiben...
Ich könnte jetzt Geschichten erzählen... leider bindet mich ein NDA.
Vielleicht mal beim Bierchen.
Felix
Holger Marzen
> Erhard Schwenk <esch...@fto.de> writes:
>
>> Nein. Die Java-VM ist kein Interpreter, sondern eine virtuelle
>> Maschine, die Bytecode versteht.
>
> ein bytecode-interpreter ist also kein interpreter?
Das erinnert mich an das BASIC des Sinclair Spectrum, dessen Editor die
BASIC-Befehle als Bytes ("Token") gespeichert hatte.
Juergen P. Meier
Es steht bei umgekehrter Alphabetischer Sortierung ganz oben in der
Liste. Naja, demnaechst gibt es ZFS...
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Michael van Elst
>Es gibt keinen Grund, wieso das krachen muß. Offsets prüft man vor der
>Benutzung, und schon kracht da gar nichts.
if (offset_falsch)
panic("offset is falsch");
Pech.
--
--
Michael van Elst
Internet: mle...@serpens.de
"A potential Snark may lurk in every tree."
Uwe Ohse
>ABER SICHER IHR LUSCHEN! ICH MACH EUCH RUND! WENN ICH EUCH ALS
>MITARBEITER BEKOMME, DANN WIRD HIER NICHT MEHR RUMGEGAMMELT! DANN
>ADMINISTRIERT IHR ALLE RICHTIGE SERVER! WINDOWS! ABER ZACK ZACK!
>ICH HAB MENSCHENFÜHRUNG BEIM BUND GELERNT! WER NICHT SPURT KOMMT IN DEN
>BAU! BEI WASSER UND BROT!
Du solltest das noch auf maximal 40 Zeichen oder so umformatieren,
dann wirkt es glaubwürdiger.
Gruß, Uwe
Lutz Donnerhacke
So ist das auch gemeint.
Wo bekommt man heute noch brauchbaren Code zum drin rumschnüffeln?
Mir reichen die Decompilate, um Workarounds vorherzusehen.
Lutz Donnerhacke
> Bei Zeile 200 habe ich dann auf C gewechselt. Mein RAM, mein ROM, mein
> Prozessor: A byte saved is a minute wasted.
Embedded ... Smartcards ... oh, wie knapp.
Falk Willberg
Dafür steckt da keiner irgendwelche One-Night-Stand USB-Sticks von
Partybekannschaften oder verseuchte CDs 'rein.
8KB¹ should be enough for all.
Falk
¹) Selbstv. ROM, RAM < 1K für den Stack *g*
Ignatios Souvatzis
> Thus spake Ignatios Souvatzis (u50...@beverly.kleinbus.org):
>> > Dieses Programm hat er gestern abend mal auf ein UFS-Image angewendet,
>> > und hat nach drei Anläufen ein Image gehabt, das OpenBSD und NetBSD zu
>> > Panikattacken verleitet.
>> _Nach_ einem erfolgreichen fsck?
>
> Nein. USB Stick einlegen, mounten, panic.
>
>> Auch ext2fs ist eine variante von UFS, hat mithin pointer-ähnliche
>> Metadaten-doppel (naja, redundante Information) im Superblock und den
>> Zylindergruppen - wenn du da etwas hinreichend widersprüchlich machst,
>> krachts.
>
> Es gibt keinen Grund, wieso das krachen muß. Offsets prüft man vor der
> Benutzung, und schon kracht da gar nichts.
>
>> Deswegen ja der fsck, der es vor dem Mounten konsistent machen
>> soll. Wenn das nicht reicht, ist das allerdings ein Fehler.
>
> Also als ich das letzte Mal geguckt habe, hat man erst die
> Root-Partition read-only gemounted (an dieser Stelle kommt die
> beschriebene Panik),
Aha - du hast von besagtem Medium zu booten versucht. Sag das doch.
> dann hat man von dieser Partition fsck geladen, und
> damit dann eventuell ein fsck durchgeführt.
>
> Das von mir bemängelte Problem ist ja gerade, daß es nicht soweit kommt.
Eine gewagte Anwendung - aber ich stimme dir zu, dass man dafür robusteren
Filesystemcode haben wollen würde.
> Wobei ich nicht ausschließen wollen würde, daß auch fscks zu Segfaults
> zu überreden sind. Das müßte mal jemand prüfen. Mal schauen, ob ich im
> August genug Zeit dafür habe.
Wg. zu grosse interne Tabellen durch kaputte Daten - das könnte ich mir
vorstellen, ja.
> Ach und du meinst mtools können da nicht abrauchen und bei dir Code
> ausführen? Und womöglich sind die Devices sauber geschützt, so daß
> mtools als root laufen muß?
Die devices, wo Teile meiner User USB-Sticks reinstecken dürfen, sind so
geschützt, dass diese User darauf zugreifen dürfen. Als nichtroot.
-is
--
seal your e-mail: http://www.gnupg.org/
Jens Link
> Meine Einstellung ist da zwar ähnlich praxisfern, aber zumindest
> funktionierte sie, wenn wir sie mal umsetzen würden:
>
> "Wir müssen einfach aufhören, Fehler zu machen"
Vielleicht würde es für viele ersteinmal reichen aus den eigenen und den
Fehlern anderer zu lernen.
Jens
--
sage@guug Berlin: http://www.guug.de/lokal/berlin/index.html
Christian Ehrhardt
> ABER SICHER IHR LUSCHEN! ICH MACH EUCH RUND! WENN ICH EUCH ALS
> MITARBEITER BEKOMME, DANN WIRD HIER NICHT MEHR RUMGEGAMMELT! DANN
> ADMINISTRIERT IHR ALLE RICHTIGE SERVER! WINDOWS! ABER ZACK ZACK!
> ICH HAB MENSCHENFÜHRUNG BEIM BUND GELERNT! WER NICHT SPURT KOMMT IN DEN
> BAU! BEI WASSER UND BROT!
Du bis jetzt bei Jamba und entwickelst ``Ausbilder Bob''?
Gruesse Christian
--
THAT'S ALL FOLKS!
Marc Haber
Auf dem Notebook wollte ich es einfach nur mal ausprobieren und bin so
weit zufrieden. Deswegen hat auch die neue Platte wieder XFSse
bekommen.
Der Verzicht auf das ständige fsck beim Booten macht den Arbeitsbeginn
auch schneller.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Ekki Plicht
> Es mal jemand geschafft haben, einen Smart auf der linken Seite zu
> tanken. Gut, der Verschluß ging schlecht ab und der Motor war sofort
> hinüber. Bis zum Anlassen ging aber alles gut.
BTDT. Allerdings mit einem Hausboot.
Backbord: Frischwasseranschluss.
Steuerbord: Dieselanschluß.
Beide Anschlüsse sehen absolut identisch aus und sind mit dem gleichen
Werkzeug zu öffnen.
Wir haben in 3 Wochen _immer_ so geparkt (oder wie man das nennt) das der
Frischwasseranschluß am Steg lag. Nur den einen Tag eben nicht. Danach sind
wir noch ca. 50m weit gekommen. Der Mechaniker musste den kompletten Motor
zerlegen um das Wasser aus dem Teil rauszubekommen. Nett. Diesel sind
robust, nach nur 4h gings weiter.
Ahoi!
Ekki
Falk Willberg
... Wasser statt Diesel
> Diesel sind robust, nach nur 4h gings weiter.
Naja, wenn Wasser statt Diesel eingespritzt wird, passiert eben
garnichts, ausser daß man das Zeug wieder ausspült und hofft, daß die
Einspritzpumpe keinen Schaden genommen hat.
Wird $FLÜSSIGKEIT statt Luft angesaugt, verbiegen sich eher die Pleuel
als daß eine merkliche Kompression stattfindet.
> Ahoi!
Eher werden Motorboote gegrüßt als Hausboote. Und das auch nur, wenn es
sich nicht vermeiden lässt.
> Ekki
73,
Falk
Till Potinius
>BTDT. Allerdings mit einem Hausboot.
>
>Backbord: Frischwasseranschluss.
>Steuerbord: Dieselanschluß.
>Beide Anschlüsse sehen absolut identisch aus und sind mit dem gleichen
>Werkzeug zu öffnen.
Spätestens bei der Feststellung obiger Tatsachen sollte man eigentlich
anfangen, eine entsprechende Beschriftung anzubringen.
MFG, Till
--
"Es gibt zwei Arten von Menschen, solche, die Menschen in
zwei Arten einteilen, und solche, die das nicht tun."
- Quelle unbekannt
Michael Hellwig
> Wir haben in 3 Wochen _immer_ so geparkt (oder wie man das nennt) das der
> Frischwasseranschluß am Steg lag. Nur den einen Tag eben nicht. Danach sind
> wir noch ca. 50m weit gekommen. Der Mechaniker musste den kompletten Motor
> zerlegen um das Wasser aus dem Teil rauszubekommen. Nett. Diesel sind
> robust, nach nur 4h gings weiter.
>
siehe auch der unzerstörbare Toyota Pickup bei Top Gear .... (scheiss
Fussball-WM! 5 Wochen Pause! wie kann man uns das antun!)
--
Michael Hellwig aka The Eye olymp.idle.at admin
to contact me via email, use michael...@uni-ulm.de
don't hesitate to look at http://laerm.or.at
Falk Willberg
> Ekki Plicht <df...@web.de> schrieb:
>
>> BTDT. Allerdings mit einem Hausboot.
>>
>> Backbord: Frischwasseranschluss.
>> Steuerbord: Dieselanschluß.
>> Beide Anschlüsse sehen absolut identisch aus und sind mit dem gleichen
>> Werkzeug zu öffnen.
>
> Spätestens bei der Feststellung obiger Tatsachen sollte man eigentlich
> anfangen, eine entsprechende Beschriftung anzubringen.
Unnötig: Erstens ist das Standart, zweitens passiert bei guter
Seemannschaft nix!elf Diesel im Trinkwasser ist aber !recovery.
Falk
Mark Neis
>Unnötig: Erstens ist das Standart, zweitens passiert bei guter
Kauf dir mal ein 'e', das fehlt da nämlich. *argl*
Mark
Falk Willberg
> Falk Willberg schrieb:
>
>> Unnötig: Erstens ist das Standart, zweitens passiert bei guter
>
> Kauf dir mal ein 'e', das fehlt da nämlich. *argl*
Da felt garnichts! Da hast Du wohl nicht aufgepasst, als "Standart" hier
durchgenommen wurde! Standard ist was anderes!elf
Falk
Arnim Sommer
> On Wed, 14 Jun 2006 11:15:20 +0200, Ekki Plicht wrote:
>> Wir haben in 3 Wochen _immer_ so geparkt (oder wie man das nennt) das der
>> Frischwasseranschluß am Steg lag. Nur den einen Tag eben nicht. Danach sind
>> wir noch ca. 50m weit gekommen. Der Mechaniker musste den kompletten Motor
>> zerlegen um das Wasser aus dem Teil rauszubekommen. Nett. Diesel sind
>> robust, nach nur 4h gings weiter.
>>
>
> siehe auch der unzerstörbare Toyota Pickup bei Top Gear .... (scheiss
> Fussball-WM! 5 Wochen Pause! wie kann man uns das antun!)
>
A!S
Arnim Sommer
Volker Birk
> Watt sind denn "hard links"?
Hard links ist lynx.
Soft links ist w3m.
Viele Grüße,
VB.
--
"If you want to play with a piece of windows software that makes you
click all over the place, there's always minesweeper."
Kyle Stedman about "Personal Firewalls" in c.s.f
Volker Birk
Volker Birk
> XFS ist in etwa genau so schnell wie ext3, aber bei ext3 gibt es Grund
> für Vertrauen in den fsck. Mir erschließt sich nicht, wieso jemand XFS
> haben wollen würde, mal ganz ehrlich.
Ich verwende es gerne statt ext3, nachdem mir wiederholt ext3 abgespackt
ist bei Plattformen != x86.
XFS ist mir schon bei Irix eigentlich nie abgespackt.
Volker Birk
> Das kann mitunter sogar dazu fuehren, dass eine Javaanwendung
> nach einer Weile schneller laeuft als eine C-Anwendung.
Was für ein schönes Märchen. Und hartnäckig wird dieser Unsinn immer
und immer wieder erzählt.
Und dass Hotspot lahm ist, stellst Du selber schnell fest, sobald Du es
mit einem IBM JDK vergleichst.
Volker Birk
> Die Java-VM ist kein Interpreter, sondern eine virtuelle Maschine,
> die Bytecode versteht.
Ein Bytecode-Interpreter also.
Volker Birk
> >Es gibt keinen Grund, wieso das krachen mu?. Offsets pr?ft man vor der
> >Benutzung, und schon kracht da gar nichts.
> if (offset_falsch)
> panic("offset is falsch");
Ich hab kürzlich mal irgendwo gehört, dass "Panic" nicht die einzige
Art ist, wie ein Syscall einen Fehler signalisieren könnte.