|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
Von Anonymer Feigling am Thursday 26. October 2006, 14:19 MEW (#1)
|
|
|
|
|
Zum Thema Proactive Security: sicher ist SSP drinne. Weiss wer mehr?
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 26. October 2006, 16:03 MEW (#2)
|
|
|
|
|
Upstart ist überigens nicht einfach ein Werkzeug um den Systemstart zu konfigurieren, wie es im Text steht, sondern ein Ersatz für das bisher verwendete sysvinit...
|
|
|
|
|
|
|
|
|
|
|
|
|
google-suche nach ubuntu 6.10 proactive security liefert das hier als ersten treffer:
https://features.launchpad.net/distros/ubuntu/+spec/memory-protection
Edgy is already using several (heap and stack segment protection, stack and ldd randomization), but we need more.
Heisst also konkret SSP & PIE. PIE ist ein gewagter Schritt, immerhin resultiert das in ca. ~10% performance-decrease auf nicht-AMD64 Systemen. Ich bin mir nicht sicher, ob ich das auf meinem Desktop wirklich will...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich hab nochmal nachgeschlagen. Um meine vorherige Aussage etwas zu praezisieren: Nicht auf allen Architekturen kostet PIE/PIC 10% Performance, aber eine kleine Einbusse ist sicher, mit Ausnahme von AMD64, weil dort Code PIC sein *muss*. Auf x86 mit seiner beschraenkten Register-Anzahl wirkt sich PIC aber happig aus: 20% langsamerer Code, grob gesagt. SSP streicht nochmal 3-5% ab, macht summa Sumarum 25% fuer x86. Das ist dann doch recht derb...
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 26. October 2006, 23:42 MEW (#7)
|
|
|
|
|
Ich halte Deine Prozentzahlen für völlig willkürlich und damit sinnfrei. x86 hat sehr "kreative" Addressierungsmethoden, sodass man sehr oft gar keine Register braucht, selbst wenn man um 3 Ecken herum addressiert. Seit OOP-Sprachen "in" sind, sind die CPUs sowieso darauf optimiert. Dass weniger Register den Code langsamer machen, ist spätenstens bei den heutigen CPU-Caches auch nur noch bedingt wahr, da der Cache quasi so schnell wie Register ist.
Du kannst ja einfach mal sha1 oder MPlayer testen. Dann hast Du sinnvolle Zahlen.
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 27. October 2006, 17:00 MEW (#15)
|
|
|
|
|
Da steht *bis zu* 20% langsamerer Code. Unter "grob gesagt" verstehe ich eher im Durchschnitt. Ich glaube auch gern, dass spezieller Code d.h. eine einzelne Funktion (in C-speak) um ein Vielfaches langsamer wird. Das sagt aber rein gar nichts über die Gesamtperformanz aus. Soweit ich das verstehe
greift SSP ja nur bei Funktionseintritt und -austritt ein. Performanzkritischer Code ist aber in der Regel als eine Funktion geschrieben oder nutzt inlining, was den Overhead des Funktionsaufrufs weitestgehend irrelevant macht.
Der Blog-Eintrag gibt aber auch nicht mehr her als Du geschrieben hast. Ich würde ganz gern mal Zahlen für konkrete Programme oder wenigstens Micro-Benchmarks sehen.
Ich glaube auch die Einschätzung, dass SSP nur für Server sinnvoll sei, ist völlig falsch. Sicherlich ist der Schaden bei einem kompromittierten Server höher. Allerdings werden Server meist wesentlich stärker überwacht sowie gewartet und nur die Software genutzt, die absolut notwendig ist.
Auf dem Desktop dagegen hat der Nutzer meist sehr viel weniger Übersicht und installiert lauter Gimmicks, die potentiell alle Sicherheitslücken haben. Dazu kommen Konfigurationsfehler mit denen eher harmlose Lücken zur Eskalation führen. Auch würden die wenigsten Heimanwender eine Kompromittierung bzw. einen Einbruch bemerken, wenn der Hacker nicht allzu unbedarft ist. Zudem sind die Desktopsysteme fast immer überdimensioniert, im Gegensatz zu Servern, die nie schnell genug sein können und auch Reserven haben müssen. Irgendwelche Desktop-Spielereien wie z.B. 3D-Effekte, Font-Aliasing oder einfach eine höhere Auflösung aber auch fettleibige Shells (es gibt sicher bessere Beispiele) ziehen die Performanz locker um einige Prozentpunkte herunter und sind dabei desöfteren weitgehend sinnfrei.
Wie gesagt, dort steht "bis zu 20%". Wenn es im Durchschnitt eher 10% sind und es nicht gerade MPlayer zur Gurke macht, dann halte ich das Preisleistungsverhältnis für ziemlich gut.
Andererseits hat Systrace weit weniger Overhead (d.h. nur für syscalls) und bietet einen weit effektiveren Schutz auch gegen Bugs die nicht ausnutzbar sind, aber generell viel Schaden anrichten können. Es ist allerdings grundsätzlich orthogonal zu SSP und muss mühsam für jedes Programm einzeln konfiguriert werden. Gerade bei Multimedia-Anwendungen möchte ich aber darauf nicht verzichten. Schließlich lassen sich viele Fehler in Programmen ganz ohne Stack-Smashing oder Heap-Overflows ausnutzen eben solche Bugs vor denen auch Java nicht schützt.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PIC? Position Independant Code? gcc -fPIC?
Wenn ja, dann ist das doch kalter Kaffee...
|
|
|
|
|
|
|
|
|
|
|
|
|
Nein. -fPIC is standard fuer shared libs, schliesslich kann man sich so die DT_TEXTRELs sparen was wieder Geschwindigkeitsvorteile beim laden bringt. Fuer Applikationen sind die Addressen aber auf jedem gaengigen (jetzt mal von den Sicherheitsfanatikern abgesehen ;)) System statisch, somit gibts auch keine DT_TEXTRELs zu ersetzen, also gibts auch keinen Geschwindigkeitsvorteil mehr, der die Mehrkosten beim ausfuehren wieder aufhebt.
(hint: -fPIE)
|
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 26. October 2006, 21:01 MEW (#6)
|
|
|
|
|
Hoffe FreeBSD wird demnächst Wochen nachziehen ;)
|
|
|
|
|
|
|
|
|
|
|
|
|
Beim Download (Kubuntu) vom switch mirror erreichte ich Downloadraten von ca. 40 KB/s.. Zuerst dachte ich es liegt an meiner Verbindung zuhause, doch in der Schule hatte ich dasselbe Verhalten..
Anschliessend habe ich den franz. Mirror versucht.. Immer wieder stalled und schlechte Raten...
Vom Canonical Ltd Server (http://releases.ubuntu.com/) sauge ich im Moment mit ca. 450 KB/s (konstant)...
Kann es sein dass der switch mirror ueberlastet ist? Konnte jemand aehnliches beobachten?
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 27. October 2006, 15:02 MEW (#12)
|
|
|
|
|
cablecom?
try bittorrent..
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich denke nicht dass die FH (Biel/Bern) einen cc anschluss hat.. :D
|
|
|
|
|
