Ich kann dein Problem nicht nachvollziehen, was dieses Tool prüft und wo die Grenzen liegen ist klar beschrieben. Und natürlich führt das Tool keinen Exploit aus um eine Lücke zu bestätigen sondern fragt die Daten des Kernels ab und stellt diese übersichtlich zusammen. Alles das ist deutlich beschrieben.
Von Verfluchtnochmal-05995bd7b am Mo, 20. August 2018 um 10:39 #
Was genau kannst du daran nicht nachvollziehen dass am 14.08.2018 gepatchte Kernel rausgingen wo das Tool weder den Fix noch die Lücke kannte aber das sysfs der Kernel dir sehr wohl den Erfolg anzeigen konnte?
CentOS: grep . /sys/devices/system/cpu/vulnerabilities/* /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: Load fences, __user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full retpoline
Fedora: grep . /sys/devices/system/cpu/vulnerabilities/* /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation: Speculative Store Bypass disabled via prctl and seccomp /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline, IBPB, IBRS_FW
Obwohl das Changelog des betreffenden Fedora Kernels behauptet hat dass der Build das Problem fixt "/sys/devices/system/cpu/vulnerabilities/l1tf" nicht vorhanden
Das Tool hätte hier nicht geholfen weil es am 14.08.2018 noch gar nicht wusste dass es "/sys/devices/system/cpu/vulnerabilities/l1tf" überhaupt gibt während du davon ausgehen kannst wenn bei so einer neuen Lücke ein Patch daher kommt du das im sysfs siehst und wenn sich nichts geändert hat was nicht stimmt
Ich kann deine Kritik nach wie vor nicht nachvollziehen. Das Tool war zum Zeitpunkt 14.08.2018 ausschließlich für Spectre 1-4 und Meltdown vorgesehen was klar und deutlich dokumentiert war. Wenn du es nicht bestimmungsgemäß einsetzt, liegt dies ausschließlich in deiner persönlichen Verantwortung. Dafür kannst du niemand anderen die Schuld geben.
Im Übrigen ist die Situation bei Longterm-Kerneln und distributionseigenen Fixes bei weitem nicht so eindeutig wie du es darstellst, da sich die Abfrageschnittstellen teilweise unterschieden oder überhaupt nicht vorhanden waren oder sind.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 20. Aug 2018 um 17:03.
Von Verfluchtnochmal_5987109 am Mo, 20. August 2018 um 20:19 #
Ja war es nicht, erzähl mir was neues! Genau DARAUF habe ich hingewiesen und du willst es warum auch immer nicht kapieren
Das Tool ist zusätzlich super aber wenn du brandneue patches für gestern noch nicht bekannte issues einspielst komplett sinnlos weil das falsche Werkzeug - Nicht mehr und nicht weniger habe ich gesagt und mir fehlen leider die Buntstifte um es dir zu erklären
Was soll bei LTS Kernel grossartig anders sein?
Per sysfs stellen die genauso die Informationen bereit, siehe CentOS mit einem Kernel dessen major Version aus dem Jahre Schnee ist aber trotzdem alles ersichtlich
Wenn dir der Kernel irgendwo vulnerable anzeigt hat er entweder einen Bug (siehe erste Fedora builds) oder dir fehlen microcode updates
Ja, du hast etwas umständlich darauf hingewiesen, dass dieses Tool nur die Lücken aufzeigt, wofür es zum gegebenen Zeitpunkt entwickelt und die in der Dokumentation aufgezeigt werden. Die Diskussion lässt sich also auf 4 Buchstaben zusammenfassen: RTFM
Was soll bei LTS Kernel grossartig anders sein?
Die Implementierungen haben sich besonders zur Anfangszeit teils signifikant zwischen den Kerneln und teilweise selbst zwischen den Distributionen unterschieden und sind auch heute noch nicht identisch. So fehlt beispielsweise im 3.16.57 nach wie vor die Anzeige der CPU-Bugs in der /proc/cpuinfo.
Von Verfluchtnochmal_5987109 am Di, 21. August 2018 um 00:49 #
/proc/cpuinfo ist in dem Kontext auch völlig wurscht, sysfs wie im Artikel beschrieben ist das korrekte Tool und selbst RHEL6 mit 2.6.x ist hier korrekt
Genau auf das wollte ich hinaus als das Tool zur Sprache gekommen ist: im zweifel ist die einzig korrekte Instanz /sys und die passt auch immer zum Kernel den du eben eingespielt hast ganz ohne RTFM
Das Tool gibt es schon länger als die sysfs-Einträge, eben gerade wegen der uneinheitlichen Lage. Mir fehlen auch die Buntstifte um dir das aufzumalen, aber ich kann immerhin auf hier verweisen.
Und ob die sysfs-Einträge nun zuverlässig sind kann ich schwer einschätzen, Kernel 4.9.110 sagt zu einem alten Pentium M zu spec_store_bypass:Vulnerable. Intel listet die CPU hingegen nicht als betroffen.
Diese ganzen CPU-Bugs sind nach wie vor ein reines Chaos.
Von Verfluchtnochmal_5987109 am Di, 21. August 2018 um 10:21 #
Ändert nichts an der simplen Tatsache dass das tool im Kontext des Artikels und zum Zeitpunkt des Kommentars wenig hilfreich war und auf nicht mehr und nicht weniger habe ich hingewiesen
Der Artikel mischt alte und neue Lücken wild durcheinander, der Kontext zum Spectre Meltdown Checker sind detailliertere Informationen welche eben sysfs gerade nicht bereitstellt. Sysfs sagt dir nicht warum eine Lücke vulnerable ist. Sysfs sagt dir nicht ob und welche unterschiedlichen Mitigations es zur selben Lücke gibt und ob ein weiterer Schutzlevel verfügbar und wie erreichbar ist.
Von Verfluchtnochmal-05995bd7b am Di, 21. August 2018 um 15:27 #
Himmel erzähl mir was neues, es hat halt trotzdem der Hinweis gefehlt dass das Tool meistens nicht aktuell ist und zu neuen Dingen wie der News-meldung eben gar nichts sagt
Du windest dich herum wie ein Aal, zum Zeitpunkt des Hinweises auf den Spectre Meltdown Checker war die initiale Unterstützung für L1TF bereits vorhanden, wie unschwer aus den Commits ersichtlich ist.
Es bleibt also lediglich der Hinweis, vor dem Einsatz eines Sicherheitstools dessen Dokumentation zu lesen. Dies sollte eigentlich eine Selbstverständlichkeit sein.
Von Verfluchtnochmal-05995bd7b am Di, 21. August 2018 um 19:04 #
Bla - Das Tool ist bei Distributionen in Repos die abgesicherte Kernel zum Zeitpunkt des Artikels ausgelifert haben aber das Tool nicht entsprechend aktualisiert weil völlig unterschiedliche Maintainer
Und schon fällt deine Argumentation erneut zusammen, deine fucking Dokumentation kann dir nicht Dinge erklären die beim Schreiben selbiger gar noch nicht bekannt waren
Da kann das Tool schlicht nichts für. Beschwere dich bei deiner Distro oder warne meinetwegen vor dem Einsatz deiner Distro oder der veralteten Version wie sie deine Distro ausliefert. Nichts davon hast du gemacht.
Und schon fällt deine Argumentation erneut zusammen, deine fucking Dokumentation kann dir nicht Dinge erklären die beim Schreiben selbiger gar noch nicht bekannt waren
Da fällt überhaupt nichts zusammen. Die Doku listet explizit jede einzelne Lücke auf welche geprüft wird. Wenn deine Lücke nicht dabei ist, wird sie ganz offensichtlich nicht geprüft *facepalm*
Von Verfluchtnochmal_5987109 am Mi, 22. August 2018 um 03:12 #
Facepalm denke ich mir bei dir die ganze Zeit
Der fucking normale User hat ein Problem wenn irgendwer irgendwas von irgendwo empfiehlt und ist noch nichtmal in der Lage irgendeine technische Doku zu verstehen noch sollte er überhaupt auf die Schnapsidee kommen irgendwas das in den repos ist am package manager vorbei zu installieren
Warum? Weil das ganz schnell überhaupt nicht mehr aktualisiert wird und er 6 Monate später noch nichtmal wüsste wie und woher
Dass ich mit dem allem kein Problem habe und typischerweise security updates in production ausgerollt habe bevor ihr blitzmerker überhaupt wisst das was kommt hilft dem der irgendeinem Trottelpost ohne Warnung folgt genau gar nicht
Der freut sich dann auf ewig ein zweites Arschloch dass das tool sagt "eh alles bestens" und das war es dann auch schon
Das ist ein simples Shellscript, da muss nichts am Paketmanagement vorbei installiert werden. Ein veraltetes Script welches eine Lücke nicht kennt sagt zu dieser auch nicht "eh alles bestens" sondern es sagt schlicht gar nichts dazu, die Lücke kommt in der kompletten Ausgabe schlicht nicht vor. Der Nutzer erhält keinerlei Hinweise darauf, dass die Lücke behoben sein könnte. Das Verhalten ist exakt identisch mit dem von sysfs, auch hier erfolgt keine Ausgabe zu Lücken, welche dem Kernel nicht bekannt sind.
Aber wer keine Argumente hat muss natürlich auf Kraftausdrücke ausweichen, da erübrigt sich jede weitere Diskussion.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 22. Aug 2018 um 03:52.
Von Verfluchtnochmal-05995bd7b am Mi, 22. August 2018 um 12:25 #
Ja nur dass der Kernel eben aus dem Repo kommt und dessen sysfs immer aktuell ist - Keine Ahnung was dein Spatzenhirn nicht daran begreifen will dass der typische User nicht in der Lage ist irgendwas manuell auf Stand zu halten
Ich kann dein Problem nicht nachvollziehen, was dieses Tool prüft und wo die Grenzen liegen ist klar beschrieben. Und natürlich führt das Tool keinen Exploit aus um eine Lücke zu bestätigen sondern fragt die Daten des Kernels ab und stellt diese übersichtlich zusammen. Alles das ist deutlich beschrieben.
Was genau kannst du daran nicht nachvollziehen dass am 14.08.2018 gepatchte Kernel rausgingen wo das Tool weder den Fix noch die Lücke kannte aber das sysfs der Kernel dir sehr wohl den Erfolg anzeigen konnte?
CentOS:
grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation:
Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: Load
fences, __user pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full
retpoline
Fedora:
grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Mitigation:
Speculative Store Bypass disabled via prctl and seccomp
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user
pointer sanitization
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full
generic retpoline, IBPB, IBRS_FW
Obwohl das Changelog des betreffenden Fedora Kernels behauptet hat dass der Build das Problem fixt "/sys/devices/system/cpu/vulnerabilities/l1tf" nicht vorhanden
Das Tool hätte hier nicht geholfen weil es am 14.08.2018 noch gar nicht wusste dass es "/sys/devices/system/cpu/vulnerabilities/l1tf" überhaupt gibt während du davon ausgehen kannst wenn bei so einer neuen Lücke ein Patch daher kommt du das im sysfs siehst und wenn sich nichts geändert hat was nicht stimmt
Ich kann deine Kritik nach wie vor nicht nachvollziehen. Das Tool war zum Zeitpunkt 14.08.2018 ausschließlich für Spectre 1-4 und Meltdown vorgesehen was klar und deutlich dokumentiert war. Wenn du es nicht bestimmungsgemäß einsetzt, liegt dies ausschließlich in deiner persönlichen Verantwortung. Dafür kannst du niemand anderen die Schuld geben.
Im Übrigen ist die Situation bei Longterm-Kerneln und distributionseigenen Fixes bei weitem nicht so eindeutig wie du es darstellst, da sich die Abfrageschnittstellen teilweise unterschieden oder überhaupt nicht vorhanden waren oder sind.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 20. Aug 2018 um 17:03.Ja war es nicht, erzähl mir was neues! Genau DARAUF habe ich hingewiesen und du willst es warum auch immer nicht kapieren
Das Tool ist zusätzlich super aber wenn du brandneue patches für gestern noch nicht bekannte issues einspielst komplett sinnlos weil das falsche Werkzeug - Nicht mehr und nicht weniger habe ich gesagt und mir fehlen leider die Buntstifte um es dir zu erklären
Was soll bei LTS Kernel grossartig anders sein?
Per sysfs stellen die genauso die Informationen bereit, siehe CentOS mit einem Kernel dessen major Version aus dem Jahre Schnee ist aber trotzdem alles ersichtlich
Wenn dir der Kernel irgendwo vulnerable anzeigt hat er entweder einen Bug (siehe erste Fedora builds) oder dir fehlen microcode updates
Ja, du hast etwas umständlich darauf hingewiesen, dass dieses Tool nur die Lücken aufzeigt, wofür es zum gegebenen Zeitpunkt entwickelt und die in der Dokumentation aufgezeigt werden. Die Diskussion lässt sich also auf 4 Buchstaben zusammenfassen: RTFM
Die Implementierungen haben sich besonders zur Anfangszeit teils signifikant zwischen den Kerneln und teilweise selbst zwischen den Distributionen unterschieden und sind auch heute noch nicht identisch. So fehlt beispielsweise im 3.16.57 nach wie vor die Anzeige der CPU-Bugs in der /proc/cpuinfo.
/proc/cpuinfo ist in dem Kontext auch völlig wurscht, sysfs wie im Artikel beschrieben ist das korrekte Tool und selbst RHEL6 mit 2.6.x ist hier korrekt
Genau auf das wollte ich hinaus als das Tool zur Sprache gekommen ist: im zweifel ist die einzig korrekte Instanz /sys und die passt auch immer zum Kernel den du eben eingespielt hast ganz ohne RTFM
Das Tool gibt es schon länger als die sysfs-Einträge, eben gerade wegen der uneinheitlichen Lage. Mir fehlen auch die Buntstifte um dir das aufzumalen, aber ich kann immerhin auf hier verweisen.
Und ob die sysfs-Einträge nun zuverlässig sind kann ich schwer einschätzen, Kernel 4.9.110 sagt zu einem alten Pentium M zu spec_store_bypass:Vulnerable. Intel listet die CPU hingegen nicht als betroffen.
Diese ganzen CPU-Bugs sind nach wie vor ein reines Chaos.
Ändert nichts an der simplen Tatsache dass das tool im Kontext des Artikels und zum Zeitpunkt des Kommentars wenig hilfreich war und auf nicht mehr und nicht weniger habe ich hingewiesen
Der Artikel mischt alte und neue Lücken wild durcheinander, der Kontext zum Spectre Meltdown Checker sind detailliertere Informationen welche eben sysfs gerade nicht bereitstellt. Sysfs sagt dir nicht warum eine Lücke vulnerable ist. Sysfs sagt dir nicht ob und welche unterschiedlichen Mitigations es zur selben Lücke gibt und ob ein weiterer Schutzlevel verfügbar und wie erreichbar ist.
Himmel erzähl mir was neues, es hat halt trotzdem der Hinweis gefehlt dass das Tool meistens nicht aktuell ist und zu neuen Dingen wie der News-meldung eben gar nichts sagt
Du windest dich herum wie ein Aal, zum Zeitpunkt des Hinweises auf den Spectre Meltdown Checker war die initiale Unterstützung für L1TF bereits vorhanden, wie unschwer aus den Commits ersichtlich ist.
Es bleibt also lediglich der Hinweis, vor dem Einsatz eines Sicherheitstools dessen Dokumentation zu lesen. Dies sollte eigentlich eine Selbstverständlichkeit sein.
Bla - Das Tool ist bei Distributionen in Repos die abgesicherte Kernel zum Zeitpunkt des Artikels ausgelifert haben aber das Tool nicht entsprechend aktualisiert weil völlig unterschiedliche Maintainer
spectre-meltdown-checker-0.39-1.fc28.noarch
kernel-core-4.17.17-200.fc28.x86_64
Und schon fällt deine Argumentation erneut zusammen, deine fucking Dokumentation kann dir nicht Dinge erklären die beim Schreiben selbiger gar noch nicht bekannt waren
Da kann das Tool schlicht nichts für. Beschwere dich bei deiner Distro oder warne meinetwegen vor dem Einsatz deiner Distro oder der veralteten Version wie sie deine Distro ausliefert. Nichts davon hast du gemacht.
Da fällt überhaupt nichts zusammen. Die Doku listet explizit jede einzelne Lücke auf welche geprüft wird. Wenn deine Lücke nicht dabei ist, wird sie ganz offensichtlich nicht geprüft *facepalm*
Facepalm denke ich mir bei dir die ganze Zeit
Der fucking normale User hat ein Problem wenn irgendwer irgendwas von irgendwo empfiehlt und ist noch nichtmal in der Lage irgendeine technische Doku zu verstehen noch sollte er überhaupt auf die Schnapsidee kommen irgendwas das in den repos ist am package manager vorbei zu installieren
Warum? Weil das ganz schnell überhaupt nicht mehr aktualisiert wird und er 6 Monate später noch nichtmal wüsste wie und woher
Dass ich mit dem allem kein Problem habe und typischerweise security updates in production ausgerollt habe bevor ihr blitzmerker überhaupt wisst das was kommt hilft dem der irgendeinem Trottelpost ohne Warnung folgt genau gar nicht
Der freut sich dann auf ewig ein zweites Arschloch dass das tool sagt "eh alles bestens" und das war es dann auch schon
Das ist ein simples Shellscript, da muss nichts am Paketmanagement vorbei installiert werden. Ein veraltetes Script welches eine Lücke nicht kennt sagt zu dieser auch nicht "eh alles bestens" sondern es sagt schlicht gar nichts dazu, die Lücke kommt in der kompletten Ausgabe schlicht nicht vor. Der Nutzer erhält keinerlei Hinweise darauf, dass die Lücke behoben sein könnte. Das Verhalten ist exakt identisch mit dem von sysfs, auch hier erfolgt keine Ausgabe zu Lücken, welche dem Kernel nicht bekannt sind.
Aber wer keine Argumente hat muss natürlich auf Kraftausdrücke ausweichen, da erübrigt sich jede weitere Diskussion.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 22. Aug 2018 um 03:52.Ja nur dass der Kernel eben aus dem Repo kommt und dessen sysfs immer aktuell ist - Keine Ahnung was dein Spatzenhirn nicht daran begreifen will dass der typische User nicht in der Lage ist irgendwas manuell auf Stand zu halten
Das ist hier so schön eingerückt. Der pro-linux Webdesigner muss ein Python-entwickler sein