[linux-l] Microsoft B.G. about bugs

[Oliver Bandel]

On Fri, Feb 21, 2003 at 09:00:55AM +0100, Jan-Benedict Glaw wrote:
> On Thu, 2003-02-20 21:50:45 +0100, Oliver Bandel <oliver at first.in-berlin.de>
> wrote in message <20030220205045.GA1155 at first.in-berlin.de>:
> > On Thu, Feb 20, 2003 at 09:09:21PM +0100, Carsten Posingies wrote:
> > 1.: Vorher testen, und zwar so, wie die experimentierfreudigen User,
> >     und nicht wie die selbstgefälligen Programmierer.
> 
> "Optimier'" mal eine Funktion, die an vielen Stellen benutzt wird. Wenn
> Du es schaffst, einen Randbereich der Funktion zu optimieren, fällt's
> u.U. nicht gleich auf, daß Du sie kaputtgemacht hast. Wenn dann passende
> Daten ins System kommen, läuft gleich garnichts mehr...
> 
> (Da fällt mir als Beispiel aus dem Linux-Kernel copy_to_user ein, und
> zwar die Implementierung für MIPS-Maschinen. Die ist durch Einsetzen
> einiger Prefetch-Befehle auf zusätzliche Geschwindigkeit optimiert
> worden. Prefetches auf MIPS machen (bei den 32bittern) immer volle 32
> Bit, auch, wenn Du nur 'nen Byte haben wolltest). Das Problem kam dann
> auf, wenn copy_to_user() Daten kopieren sollte, die gerade am Ende einer
> page lagen, sodaß der Prefetch dann den Anfang der nächsten Seite
> angeknappert hat, die nicht gemapt war. Oops...)


Tja, wenn man was optimieren will, sollte man sich eben
auch sicher sein, was man da tut.
Wenn man als jemand, der im kernel rumfummeln will, das
tut, ohne verständnis der Dinge, dann ist das Töricht.
Und ansonsten - gerade wenn man im kernel rum fummelt -,
sollte man eben die Finger davon lassen, wenn man
das noch nicht ganz versteht.

Dafür gibt's ja auch die Trennung kernel-/Userspace,
damit nicht jeder Dussel die Sicherheit des gesamten
Systems gefährdet, wenn er gerade mal seine ersten
Programmierversuche unternimmt.



> 
> > 2.: Mal über's SW-Design nachdenken und sich mal Gedanken machen,
> >     wie es kommen kann, daß kleine Neuerungen quer durch's System
> >     greifen.
> 
> Wenn's Simpel-Funktionen sind (copy_to_user(), strlen(), ...) die sich
> auf Mal komisch verhalten, dann kann sowas vorkommen.


Ich rede jetzt mal nur vom Userspace, da ich meine ohnehin schon
strengen Programmierregeln für die Kernelprogrammierung
noch mal drastisch verschärfen würde.


Das selbstverschuldete Bufferoverflow-Problem
fängt schon da an, wo Leute nicht mal sizeof()
kennen oder nutzen, sondern die Längen hart
eincodieren. Habe ich tatsächlich in der Arbeitswelt
(mehrfach) erlebt. Bei Software, die als fertig an die
Kunden raus gehen sollte. Gerechtfertigt mit: "Was soll
schon passieren, ist doch oben in der datei der
gleiche Wert zu finden".
Spätestens bei der Anpassung beim Kunde vor Ort baut
man dann möglicherweise was ein, was einem Monate später
irgendwo zufällig auf die Füsse fällt.


Oder wenn man zu faul ist, ein Argument mehr zu übergeben,
bzw. denkt, "es kann ja nichts schief gehen,
es kommen hier ja nur die Daten an, die so-und-so aussehen"
und deswegen strcpy(3) statt strncpy(3) nutz.

Spart ja schliesslich soooo viel Zeit beim Programmieren
und so viel Rechenzeit bei der Ausführung, wenn man
diese Tests weg lässt.

Und Bums, hat man drei Wochen Mehraufwand am Hals, wenn
dann der "idiotische Kunde" mal hier und mal da klickert.

DAS sind die Fehler und Nachlässigkeiten, die ich meine.

Und die gibt's leider bei GPL-Hackern auch.


> 
> Anderes Beispiel - bei einem Freund haben wir ein Shell-Script
> geschrieben, daß einige Daten aus HTML-Seiten 'rausholt und über die
> Nomen (besser: alle großgeschriebenen Wörter...) einen (sortierten)
> Index aufbaut. Wörter wie "Ihrem", "Der", ... sollte weggelassen werden.
> 
> Irgendwann lief das Script nicht mehr, da ging so ziemlich *alles*
> Schief. Woran lag's? Er hatte an irgendeiner der LOCALES-Variablen
> gefummelt und grep, sed & Co. brachten aufmal quasi falsche Ergebnisse
> an den Tag. Eine Variable umgesetzt - jede 10. Zeile kaputt...
> (Ein "LANG=C" am Anfang des Scripts hat dann Besserung versprochen...)


Ja, das ist eben das problem mit globalen Variablen,
die man ja grundätzlich meiden sollte.


Ciao,
   Oliver