|
|
|
|
|
|
|
@Richter 
Ich denke der hat recht. Aber warum brauchen manche CPUs kein Microcodeupdate oder wie viel muss man für die Lösung ohne Microcode opfern?
https://access.redhat.com/articles/3311301
http://www.pro-linux.de/sicherheit/2/41869/mehrere-probleme-in-linux.html
| | pti 1 ibrs 1 ibpb 1 -> fix variant#1 #2 #3
pti 1 ibrs 0 ibpb 0 -> fix variant#1 #3 (for older Intel systems with no microcode update available) | |
Hat Intel ab bestimmten CPUs "noch mehr verkackt") und braucht für einen Fix gegen SPECTREv2 ein Microcodeupdate oder vermindert das Microcodeupdate die Auswirkungen auf die Performance. Orginiär soll ja Retpoline SPECTREv2 als ganzes angehen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 11.01.2018 13:51]
|
|
|
|
|
|
|
|
|
Skylake und neuer sind auch mit Retpoline anfällig. Wahrscheinlich macht der Microcode da einfach dieses Feature aus, sodass sich Skylake+ wie Haswell verhält.
https://github.com/marcan/speculation-bugs <- Übersicht.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 11.01.2018 13:48]
|
|
|
|
|
|
|
|
|
Danke. Und da haben wir es:
| | | Alternatively, Intel is recommending retpolines for [BTI], especially on current processors where that may be faster than the microcode patches for IBPB. Retpolines also require a microcode patch on Broadwell and newer CPUs, presumably because on those even ret ends up being predicted in an exploitable way. | |
BTI == SPECTREv2
Intel reagiert bei der ganzen Sache ungeschickt. Eine eigene Website, klare Ansagen und Beschreibung hätte die Reputation retten können, so stehen sie zu recht wie eine Firma da die das Problem möglichst bequem vertuschen will (so wie VW halt, keine klare Ansage, Minimallösung, Wahrheit darf man sich selber suchen...).
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 11.01.2018 13:59]
|
|
|
|
|
|
|
|
|
|
Ist der Fehler eigentlich für alle relevant oder nur für virtuelle Maschinen? Und wessen performance würde ein Patch da einschränken?
|
|
|
|
|
|
|
|
|
|
|
Der Link von Ratte erklärte das recht kurz und gut. Ich würde es so sagen, der sofortige Weltuntergang ist nicht dabei, das Problem sind viel mehr die Möglichkeiten die entstehen?
SPECTREv2 zielt mehr auf virtuelle Maschinen, wohl deshalb war eBPF der gewählte Angriffsvektor. Ist aber nicht auf virtuelle Maschinen beschränkt! MELTDOWNv3 ist hart unangenehm, weil man an Kernelspeicher kommt und weil es mit jeder JIT-Sprachen ausgenutzt werden kann, insbesondere JavaScript im Webbrowser (deswegen sind die Browserupdates neben KPTI so wichtig). Und SPECTREv1 ist ebenso anfällig gegen Angriffe über JIT-Sprachen (wieder Browserupdates).
Das Gute ist, dass keine harte Remotelücke dabei ist wie wir sie aus Softwarefehlern kennen. Die Browserupdates darf man sich nicht als einfache Updates der Software vorstellen, die wollen letztlich die Architektur der Webbrowser so umbauen, dass* JavaScript in eigenen Prozessen läuft. Sandbox hilft nicht. Zugute kommt uns, dass WebKit2, Gecko und Blink diesen Weg auf Grund der vergangenen Problem schon recht weit gegangen sind.
Ein Argument gegen JavaScript war immer, dass das Ausführen fremden Codes grundsätzlich ein Sicherheitsproblem darstellt. Anders als bei eBPF, kann da halt jeder kommen. Wegen den unzähligen Problemen haben sie uns Sandboxen gegeben und dann die Optionen zum Abschalten von JavaScript aus der UI entfernt. Hauptsache die Websiten sind dynamisch?
* Ich hoffe, ich habe dass mit zwei s hier richtig geschrieben. Ich bin verunsichert 
|
|
[Dieser Beitrag wurde 15 mal editiert; zum letzten Mal von hoschi am 11.01.2018 22:44]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Was heißt denn "higher system reboots"?
Das klingt so, als wäre es normal das der Server hin und wieder spontan rebootet, aber zweimal am Tag ist halt "high"
|
|
|
|
|
|
|
|
|
|
|
Da sind Windowsadmins dabei, die starten ihre Gammelsoftware nicht per Cronjob neu...
|
|
|
|
|
|
|
|
|
|
|
Ahhh. Diese Dinger sehen überall anders aus, auf dem Laptop ist es ein kleiner winziger weißer Geist - wie ein Buchstabe. Unter Fedora ein grünlicher lächelender Geist - wie ein Smilie.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Als ob jemand den Knaller gezündet hätte.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
grade mein erstes richtiges problem bei nem uprgade von debian stretch auf jessie gehabt.
bei mir ging einfach mal in der NFS infrastruktur garnichtsmehr.
ist natürlich bekannt aber irgendwie ignoriert?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868747
bin ein bischen verwundert und gleichzeitig entäuscht, frag mich echt wieso? da müssen doch schon hunderte leute reingerannt sein?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
grade mein erstes richtiges problem bei nem uprgade von debian stretch auf jessie gehabt.
| |
Das wird das Problem sein.
|
|
|
|
|
|
|
|
|
|
|
|
... ich lass das jetzt einfach mal stehen
|
|
|
|
|
|
|
|
|
|
|
|
Bei Debian und Ubuntu finde ich es unheimlich nervig, dass die Codenamen äquivalent zur Version verwendet werden, sodass man immer beides wissen muss. Die Paketsuche zeigt z.B. nur den Codenamen an.
|
|
|
|
|
|
|
|
|
|
|
|
Das. Zahl dahin und gut. Bei ubuntu sind die Namen ja wenigstens noch alphabetisch geordnet, bei dem Wirrwarr bei Debian kennt sich ja kein Mensch aus.
|
|
|
|
|
|
|
|
|
|
|
Wenn alle 7 Jahre mal ein neues Debian Release kommt, kann man sich auch einen neuen Namen merken.
*badummtsch*
|
|
|
|
|
|
|
|
|
|
|
na wenn man sich über sonst nichts aufregen kann dann müssen halt die codenamen herhalten... 
ihr werdet alt, wirklich
|
|
|
|
|
|
|
|
|
|
|
Wenn es Codenamen wären, die man sich merken kann. Aber bei Toy Story bin ich irgendwann raus. Fedora hatte Codenamen, die man sich merken konnte Heisenbug oder Schroedinger 
So. Ich habe einen taktischen Fehler gemacht!
Mein LG-4K hat 1xDP, 1xUSB-C (also nochmal DP), 2xHDMI
Den Desktop habe ich gleich per DP angeschlossen, das ThinkPad ueber die Dockingstation auch mit DP durch ein DP2HDMI-Kabel welches HDMI 2.0 kann. In der Hoffnung, so wenigstens 3480x2180@30Hz vom ThinkPad angesteuert zu bekommen. Klapp nicht, aber ist halt nur eine HD3000 mit DisplayPort 1.1 (200() aus 2011 
| |
| Code: |
EDID claims 1 more blocks left
EDID blocks left is wrong.
Your EDID is probably invalid.
Looks like VBE was successful. Have a good day.
Checksum Correct
Section "Monitor"
Identifier "LG Ultra HD"
ModelName "LG Ultra HD"
VendorName "GSM"
# Monitor Manufactured week 10 of 2017
# EDID version 1.3
# Digital Display
DisplaySize 600 340
Gamma 2.20
Option "DPMS" "true"
Horizsync 30-135
VertRefresh 56-61
# Maximum pixel clock is 300MHz
#Not giving standard mode: 1152x864, 60Hz
#Not giving standard mode: 1280x1024, 60Hz
#Not giving standard mode: 1280x720, 60Hz
#Not giving standard mode: 1600x900, 60Hz
#Not giving standard mode: 1920x1080, 60Hz
#Not giving standard mode: 1280x800, 60Hz
|
|
Ich habe schon daran gedacht es mit Modelines zu erzwingen, sowas geht mit Wayland aber nur direkt mit einer INI-Datei von Weston.
Nochmal nachgesehen unter /sys/class/drm/* und das ThinkPad hat den Monitor nicht per DisplayPort angebunden, es sieht das DP2HDMI-Kabel als HDMI-Anschluss. Dabei hat weder das ThinkPad noch die Dockingstation einen physischen HDMI-Anschluss, intern aber 
Wieso muss das so schlau sein? Reines DisplayPort-Kabel genommen, an der Dockingstation vom ThinkPad angeschlossen und sofort die volles Aufloesung erhalten.
Jetzt muss ich immer nur daran denken, ganz oben von einem Bildschirm auf den anderen mit der Maus zu wechseln.
|
|
[Dieser Beitrag wurde 7 mal editiert; zum letzten Mal von hoschi am 14.01.2018 18:40]
|
|
|
|
|
|
|
|
|
Was ist das eigentlich bei dir mit der Groß- und Kleinschreibung? INTEL, QT usw.
Ab der Nehalem-Generation (iX-NNN) ging 4K (@30 Hz) über DP. Eventuell auch schon eine Generation vorher.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 14.01.2018 18:13]
|
|
|
|
|
|
|
|
|
Qt tippe ich in letzter Zeit immer richtig, nur der Hass auf Intel ist gerade größer
| | Zitat von csde_rats
Ab der Nehalem-Generation (iX-NNN) ging 4K (@30 Hz) über DP. Eventuell auch schon eine Generation vorher.
| |
Japp! Zumindest ab SandyBridge! Ich war leider noch am editieren und Kabel umstecken. Dabei habe ich selbst vor kurzem geschrieben, dass der DP technisch immer etwas Vorsprung vor HDMI hat. Dann muss ich wohl den Desktop erstmal per HDMI "2.0b" anschließen, statt DP "1.4" und das X220 eben per DP "1.1".
HiDPI
// edit
So so. Link auf Extra3 unterjubeln?
|
|
[Dieser Beitrag wurde 5 mal editiert; zum letzten Mal von hoschi am 14.01.2018 19:12]
|
|
|
|
|
|
|
|
|
| | Tavis Ormandy discovered a vulnerability in the Transmission BitTorrent
client; insecure RPC handling between the Transmission daemon and the
client interface(s) may result in the execution of arbitrary code if a
user visits a malicious website while Transmission is running. | |
lol
|
|
|
|
|
|
|
|
|
|
|
|
Wenigstens bentuetze ich Bittorent nicht. Irgendwie nie gemocht.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
na wenn man sich über sonst nichts aufregen kann dann müssen halt die codenamen herhalten...
ihr werdet alt, wirklich
| |
Also ich finde das schon seit *nachschlag* Woody nervig. Und da war ich noch jung!
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
| | Tavis Ormandy discovered a vulnerability in the Transmission BitTorrent
client; insecure RPC handling between the Transmission daemon and the
client interface(s) may result in the execution of arbitrary code if a
user visits a malicious website while Transmission is running. | |
lol
| |
Lustig. Den selben Bug hat er vor ein paar Tagen beim Electrum Bictoin-Wallet reported. Scheint sein neues Hobby zu sein
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
| | Tavis Ormandy discovered a vulnerability in the Transmission BitTorrent
client; insecure RPC handling between the Transmission daemon and the
client interface(s) may result in the execution of arbitrary code if a
user visits a malicious website while Transmission is running. | |
lol
| |
sicher nur weil der transmission standardmässig die zwischenablage monitored.
das hat mich eh schon immer gestört, benutz deshalb am liebsten einfach rtorrent und fertig. das ding bekommt dann auch hoffentlich bald ipv6 support :/
|
|
|
|
|
|
|
|
|
|
|
Ich lese das so, dass Transmission halt ein Socket auf 127.0.0.1 aufmacht, und was auch immer da für ein RPC-Protokoll läuft: Es ist durch das Hinschicken eines HTTP-Requests exploitbar. Immer im Hinterkopf behalten, dass http:// nicht bei der Anwendung ankommt. HTTP-Request == IRC-Verbindung, z.B.
Eine Webseite macht dann halt <img src="http://127.0.0.1:transmission/?lol=meinshellcode" width=0 height=0> .
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 14.01.2018 22:12]
|
|
|
|
|
|
|
|
|
|
Gerade auf der Suche nach nem NAS gesehen dass Intel auch die kleinen CPUs nach maximal zwei Jahren wegsterben, die haben ja echt nen Lauf
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
