somedevdude

• 20.09.21
• 11:51
• Artikel

@nemesis1337: Der Bug ist nur auf Windows-System relevant, sollte AMD bei den Linux-Treibern nicht ein ähnliches Problem unterlaufen sein.

• 07.09.21
• 07:50
• Artikel
• +7

Meiner Meinung nach ist hier nicht TPM das wirklich Problem, sondern Secure Boot. Auf einem Selbstbau-PC wird höchstwahrscheinlich ein (leerer) TPM-Header vorhanden sein, TPMs sind seit der Ankündigung Microsofts extrem im Preis gesunken und stehend aktuell bei rund 20 bis 30€ und sind schnell ausgetauscht.

Das Problem was ich hier sehe ist eher, dass AKTIVES Secure Boot verlangt wird. TPM ansich kann nicht viel verhindern, wenn weiter Treiber, EFI-basierte Rootkits, etc. geladen werden können, aber genau das kann man mit Secure Boot verhindern. Es übergibt praktisch die gesamte Kontrolle über den Bootprozesses des Gerätes an den OS bzw. Softwarehersteller. Und wenn dieser mal meint, nur mehr signierte Programme zuzulassen, dann ist das halt so, Pech gehabt.

Das mutet nicht grad rosig für die Zukunft. Der PC ist praktisch die letzte Plattform, bei der Besitzer, zumindest mit etwas Wissen, noch die volle Kontrolle über das Gerät besitzen. TPM ist deswegen für mich nur eine Scheindebatte, das wirkliche Thema sollte der unsägliche Secure Boot-Zwang sein.

• 07.09.21
• 07:44
• Artikel
• +2

@AlexKeller: Rein theoretisch Ja, aber da jedes TPM ein eindeuitges, vom Hersteller signiertes Zertifikat beinhaltet, wird das ganze wieder nutzlos wenn entweder das OS oder das Programme nur bekannte TPM-Hersteller zulässt.

• 06.09.21
• 21:41
• Artikel
• +2-1

@iCheefy: Inwiefern dass von der Masse boykottiert wird, wenn es auf allen neuen Geräten vorinstalliert kommt, hinterfrage ich jetzt mal.

Bei Android hast du im Grunde Recht, ich hab da in der Eile weniger an Apps als an Kernel(-Treiber), etc. gedacht, welche schon lange bei kaum einen Hersteller einfach installierbar bzw. ersetzbar sind.

• 06.09.21
• 21:22
• Artikel
• +1

@iCheefy: Naja, das Problem ist nur dass man es mit TPM und Secure Boot so weit treiben kann, dass so wie auf iOS und Android nur mehr signierte Treiber bzw. Programme laufen können, dann wirds auch mit Patches nichts mehr.

• 19.08.21
• 19:07
• Artikel
• +1

@JägerMeister: Ich bin kein CPU-Architekt, aber seit dem Samsung Galaxy S6 bin ich bei der AOSP-Szene dabei. Das S6 ist das erste Galaxy-Smartphone mit HMP-Architektur, und was da alles Schiefgegangen ist beim Ausbalancieren zwischen Leistungs und Effizenzkernen (Samsung hat dann im Endeffekt bestimmte bzw. weit verbreitete Apps per Logik manuell geregelt und angepasst).

Ich muss da leider schon sagen dass ich sehr pessimistisch bin, da wie ich bei meiner Antwort zu @floerido Post schon geschrieben habe, sind alle Desktop-System seit Jahrzehnten SMP-Systeme und die Programme dementsprechend programmiert (SMP kurz = Alle Prozessoren/Kerne sind identisch).

Das jetzt auf HMP (HMP kurz = Gegenteil von SMP, unterschiedliche Prozessoren/Kerne möglich) umzustellen ohne dass die Programme das registrieren kann auf kurz oder Lang nur schief gehen.

Nachtrag: ARM war auch erfahren, und die Lösung war auch nicht schlecht. Aber Smartphones waren noch nie wirklich Leistungspferde, da hat man dass nicht so stark mitbekommen. Aber aus oben genannten Gründen denke ich dass sowas am Desktop einfach ein Fehlgriff ist.

• 19.08.21
• 18:59
• Artikel

@floerido: Das Problem ist aber, wer teilt das wie auf, wer entscheidet was auf Leistungskernen läuft und was auf Effizienzkernen? In der Praxis müsste das fast das Programm selber machen, weil es selbst am besten Einschätzen kann wie viel Leistung es normalerweise braucht.

Browser, Office, etc. werden das wenn nötig einbauen, wie siehts aber mit älteren Spielen aus, die keine Updates mehr bekommen; was wenn die vom OS Effizenzkerne zugewiesen bekommen? Die meisten hier werden wahrscheinlich wissen wie man das behebt, aber der Großteil der Leute wird einfach nur merken dass alles generell etwas langsamer und unflüssiger läuft, ohne wirklich zu wissen was dahinter steckt und das man dagegen tun kann.

Windows/Linux/Mac sind nun mal seit Anbeginn der Zeit SMP-System und alle Programm dementsprechend programmiert. Jetzt auf einmal alles auf HMP umzustellen wird einfach nicht hinhauen, außer Intel und oben genannte OS-Entwickler kommen mit einer Wahnsinnserfindung daher.

Aber Spoiler: Android-Herstellen habens versucht, und die ersten Jahre waren die meistem Ideen rein Leistungstechnisch ein Griff ins Klo.

Edit: Typo

• 19.08.21
• 18:25
• Artikel

Na das mit den Effizenzkernen schau ich mir mal an. Ich hoffe mal dass Spiele, etc. sich nicht einen dieser Kerne aussuchen, ansonsten schaut's düster mit der Kundenzufriedenheit aus. Ohne ordentliche Optimierung von seiten Windows (sprich automatische Verteilung der Prozesse auf Leistungs bzw. Effizienzkerne) wird das von Haus aus ein kompletter Reinfall.

Aber mal ehrlich, wer kommt bitte auf die Idee sowas für Desktop-CPUs zu machen? Laptop, Tablets und Smartphones ist es ne sehr gute Idee, aber auf Desktops? Und dann noch immer mit ner TDP von 125W. Mir persöhnlich wäre es lieber nur 8 Leistungskerne und ne TDP von, ca. 95W zu haben statt 125W und 8 bzw. 16 praktisch unnötiger Kerne.

• 19.08.21
• 13:31
• Artikel
• +3

@dpazra: Leider bin ich ein Pedant, das mit der Prüfsumme ist nicht ganz richtig.

Jeder Endpunkt in der Verbindung (Server und Client) generieren bei Verbindungsaufbau eine zufällige, 32-bit lange Zahl den Sie als Zähler benutzen, keine Prüfsumme. Dieser Zähler erhöht sich beim Senden bzw. beim Empfangen damit jeder Endpunkt weiß, dass noch keine Daten verloren gegangen sind, welche dann vom gegenüber erneut angefordert werden können.

Ansonst recht gut erklärt, dein ersten Beispiel ist praktisch SYN-Flooding ähnlich (Alice kontaktiert Carol als "Bob", Carol schickt Bob dann eine Antwort; wenn genug Server Carol als Bob kontaktieren, hat man ein recht einfaches, aber gut DDoS)

• 19.08.21
• 13:26
• Artikel
• +2

Nur als Info, SYN-Flooding gibts schon länger, aber das hier ist auch sehr interessant.

@dpazra hat das schon ganz gut erklärt woran es hier scheitert. Kurz gesagt: Fehlerhafte Implementierung des TCP-Stacks. Und wenn ich mir anschaue welche Netzwerkausrüster kontaktiert wurden, dann stimmt das schon ein wenig ängstlich was da in Zukunft noch kommen könnte.