ZFX + Developia

Microsoft, AMD, Intel, u.a. haben angekündigt, dass sich ihre neuen CPUs nur noch mit Windows 10 betreiben lassen werden.

Going forward, as new silicon generations are introduced, they will require the latest Windows platform at that time for support. […] For example, Windows 10 will be the only supported Windows platform on Intel's upcoming "Kaby Lake" silicon, Qualcomm's upcoming "8996" silicon, and AMD's upcoming "Bristol Ridge" silicon.

Das war letzten Monat, und man hat versucht, mehr zu erfahren, aber alle schweigen sich aus.

Ich hoffe ja immernoch, dass sie bloß AVX9 einführen und das ganze Trara sehr überzogenes Marketing-Neusprech ist für „wer AVX9 nutzen will, muss dann aber auch Windows 10 installieren“.

Nun aber mal zur Grundsatzfrage – zur Realisierbarkeit: Die CPUs, die man sich bisher gekauft hat, lassen sich alle noch mit DOS betreiben. Der ganze Quatsch mit Real Mode und Virtual Mode ist da drin verbaut (sogar eine komplette 8086er-Kopie), so dass jedes 30 Jahre alte OS mit dieser CPU arbeiten kann (wenn auch nur mit einem Kern und ohne Power Management und so). Und x86 ist ja legendär für seine Abwärtskompatibilität. Wie soll der Chip also alles außer Windows 10 verweigern können? Was soll das technisch sein? Eine DRM-Schranke vor der Stromzufuhr? Kontrolliert das Board den OS-Eintrag im UEFI?

Das hier aus dem Original-Blogeintrag deutet auf DRM hin:

Compared to Windows 7 PC’s, Skylake when combined with Windows 10, enables up to 30x better graphics and 3x the battery life – with the unmatched security of Credential Guard utilizing silicon supported virtualization.

Der Credential Guard setzt aktuelles UEFI, Secure Start, und den ganzen anderen Trusted-Computing-Scheiß voraus; also könnte das der Weg sein, über den sie die Ausführungsumgebung limitieren.

Das klingt ja ekelhaft.

Was genau wäre denn AVX9? Google schweigt sich bei mir dazu aus.

Was ich mir auch vorstellen könnte, wäre eben, dass die komplette Rückwärtskompat rausfliegt und die CPUs dann direkt mit dem Long Mode (64 bit) starten. Was natürlich auch dazu führen würde, dass alle älteren Systeme und Bootloader kaputt gehen.

Wenn es aber wirklich nur Windows 10 und folgendes wäre, würde ich mich fragen, was mit dem Linux-Server-Segment ist...

Entschuldige; AVX sind Befehlserweiterungen, die Intel in seine CPUs eingeführt hat und die vom Betriebssystem unterstützt werden müssen wenn man sie nutzen möchte. Danach kamen AVX2 und AVX-512; weil ich keine Ahnung habe, wie das nächste heißen soll, habe ich einfach AVX9 geschrieben.

Was Linux angeht … die Sicherheitsmaßnahmen sind ja zu großem Teil schon in aktuellen Systemen verbaut (alles mit UEFI statt BIOS), da wird sich für Linux nicht viel ändern:

http://www.heise.de/ct/hotline/FAQ-UEFI-Secure-Boot-und-Linux-2056294.html hat geschrieben:Bei aktivem und korrekt implementiertem Secure Boot können Sie nur Linux-Distributionen installieren, die per UEFI starten und dazu einen Bootloader nutzen, der mit einem Schlüssel signiert wurde, den die UEFI-Firmware Ihres Systems als vertrauenswürdig einstuft. Von den bekannteren Distributionen erfüllen derzeit nur Ubuntu 12.10 und das parallel zu dieser c’t erwartete Fedora 18 (siehe S. 67) diese Voraussetzung.

Sie müssen also mitziehen, wie bisher auch. (Mit Windows 8-zertifizierter Hardware ließ sich Secure Boot noch abschalten und beliebiges Linux installieren; seit Windows 10 nicht mehr.)

Soweit ich das verstanden habe, geht es darum offiziell keine Unterstützung seitens Microsoft /Intel / AMD geben zu müssen. Wen eine ältere Windows Installation dann einfach Spinnt ist Pech. Das gleiche gilt übrigens auch für diverse alte CPU`s in Bezug auf Windows 10, wo man Windows 10 zwar installieren kann, aber ausser Bluescreens nichts vom OS hat.

Also so wie ich Microsoft (und die ganze Welt) kenne, basieren die älteren Windows-Versionen einfach auf undefiniertem Verhalten, was aber in den aktuellen CPUs "irgendwie" funktioniert.
Vermutlich mussten die Hersteller deswegen immer Workarounds auch in neue Chips bauen, um die Kunden nicht zu verärgern; nichts wäre schlimmer als zu sagen, dass auf dem neuen Chip Windows nicht mehr läuft.
(Das ruiniert den Ruf, und dabei ist es egal, dass eigentlich Windows "schuld" ist. Genauso wie Windows bei vielen "scheiße" oder "instabil" ist, nur weil viele Software-Hersteller nicht die offiziellen APIs verweden, die Treiber einfach Müll sind, etc.)

Und da haben die Chip-Hersteller jetzt kein Bock mehr drauf, das korrekt zu simulieren und MS kann/will das nicht in alten Windows-Versionen fixen; und da haben jetzt alle zusammen beschlossen den alten Quatsch endlich mal wegzuschmeißen: WIN für Microsoft, WIN für die Chip-Hersteller, WIN für die Standards... leider FAIL für die User :mrgreen: aber aus meiner Sicht trotzdem die richtige Entscheidung.
Ich gehe mal davon aus, dass Linux meistens nicht auf undefiniertem Verhalten basiert und es daher eher nicht/weniger zu Problemen kommt (oder die müssen dann halt auch korrigieren/patchen).

NytroX hat geschrieben:Also so wie ich Microsoft (und die ganze Welt) kenne, basieren die älteren Windows-Versionen einfach auf undefiniertem Verhalten, was aber in den aktuellen CPUs "irgendwie" funktioniert.

Weißt du, mit dieser Erklärung wird mir das ganze sogar irgendwie sympathisch. Ich wünschte nur, derartige Dinge würden einfach mal offen und klar kommuniziert. Ich bin ein Mensch, der gerne wohlbegründete Entscheidungen trifft, aber lebe in einer Welt in der man viel zu oft an die relevanten Informationen einfach nicht dran kommt. Man denke nur mal an die Beschreibungen von Windows-Updates, bei denen ich mich frage, ob es überhaupt irgendeine relevante Zielgruppe gibt, für die sie nützlich ist. Genauso wie mich diese angeblich für Spiel XY optimierten Grafiktreiber mittlerweile tierisch aufregen, weil es de facto einfach ein kaputtes Spiel auf eine kaum minder kaputte Art zurechtbiegt und die Beschreibung somit eigentlich eine recht dreiste Lüge ist, mit der aber Grafikkarten- und Spielhersteller besser dastehen.

Aber zurück zu dem, warum ich diese Begründung sympathisch finde: Ich war gestern noch auf einer Webseite, die statt einem ü ein ü dargestellt hat. Was sagt dass denn bitte über den Entwicklungsstand unsere ach so fortschrittlichen Zivilisation aus, wenn es nach mindestens 30 Jahren Heimcomputer immer noch ein ungelöstes Problem ist, ein Schriftzeichen zu kodieren? Lasst die alten 'Standards' endlich sterben!

NytroX hat geschrieben:Also so wie ich Microsoft (und die ganze Welt) kenne, basieren die älteren Windows-Versionen einfach auf undefiniertem Verhalten, was aber in den aktuellen CPUs "irgendwie" funktioniert.
Vermutlich mussten die Hersteller deswegen immer Workarounds auch in neue Chips bauen, um die Kunden nicht zu verärgern; nichts wäre schlimmer als zu sagen, dass auf dem neuen Chip Windows nicht mehr läuft.

Irgendein Beispiel? Wo wurde denn bitteschön jemals ein Workaround in eine CPU eingebaut, damit eine existierende Kernel-Komponente weiter funktioniert (war das nicht immer eher umgekehrt)? Und was soll bei einer CPU undefiniertes Verhalten sein?

Vielleicht am Rande interessant, ich werfe es nur ein weil ich die Tage drübergescrollt bin:

https://media.ccc.de/v/32c3-7171-when_h ... _just_work

Also ein (zugegebenermaßen eher weit her geholtes) Beispiel wo mMn. eine Art undefiniertes Verhalten auftreten könnte, wäre z.B. die LongMode activation.
Die Manual sagt ganz klar: "Protected mode must be entered before activating long mode"
Das scheint aber wohl nicht ganz der Fall zu sein:
http://wiki.osdev.org/Entering_Long_Mode_Directly
In wie weit der Prozessor bei solchen Spielchen tatsächlich mitmachen muss, und wie portabel sowas zwischen AMD und Intel ist, ist glaube ich im Ermessen des jeweiligen Hardware-Designers/Herstellers.

Wenn man nun an Virtual8086 Mode switches, power management, exception/interrupt handling etc. denkt, will ich garnicht erst wissen in welche Fallstricke man da laufen kann (z.B. muss man an den richtigen Stellen die Interrupts deaktivieren/reaktivieren usw - wenn man das aber nicht tut, führt das evtl. nicht gleich zu einem Triple-Fault/"Crash" - erinnert mich irgendwie ein wenig an C/C++).

war das nicht immer eher umgekehrt

Du hast natürlich recht, meistens ist es eher andersrum.

Wo wurde denn bitteschön jemals ein Workaround in eine CPU eingebaut, damit eine existierende Kernel-Komponente weiter funktioniert

Bin mir nicht sicher, ob du das gelten lässt, aber ich würde jetzt einfach mal "RealMode" und "A20 Line" aufführen :-P
IMHO gibt es keinen vernünftigen Grund, einen nagelneuen x86-64 Prozessor mit 16 Bits und 1 MB RAM starten zu lassen, außer der Kompatibilität mit exisitierender Software (BIOS/UEFI/Bootloader).
Jetzt könnte man anbringen, dass das auch wegen anderer Hardware-Komponenten so sein muss - aber die haben erst UEFI neu eingeführt, und jedes neue Modell hat einen anderen/neuen Socket, MemoryManger (DDR3->DDR4) und vieles mehr... man tauscht ja schon fast den ganzen PC jedesmal - daher könnte es aus meiner Sicht gut möglich sein, dass die angrenzende Hardware vielleicht nicht der ausschlaggebende Grund ist.

Wirklich explizit installierte technische Maßnahmen, dass Win7/Win8(\.1)? nicht mehr auf Prozessor XYZ läuft, halte ich eher für unwahrscheinlich, aber man weiß ja nie was die sich so einfallen lassen :D .
Solange die nicht mit dem wahren Grund rausrücken, bleibt wohl alles was wir hier sagen eh Spekulation :-)

PS: Außerdem kamen bei meiner Begründung alle gut weg, lass mich doch einfach Mal an das Positive in der Welt glauben... :lol:

Naja … die Vendors arbeiten eng mit Microsoft zusammen (hier ein gutes Beispiel kreativer Programmierung um 1990, das aber nicht undefiniertes Verhalten enthält) um die Fallstricke ausreichend abzustecken bevor was Kaputtes ausgeliefert wird. Der NT-Kernel ist auch nicht neu, läuft auf zig Architekturen, und gehört zu den am besten getesteten Codebases überhaupt – da ist „Windows basiert auf undefiniertem Verhalten und Linux weniger“ schon drastisch bei den Haaren herbeigezogen ;)

Und natürlich lasse ich das *nicht* gelten, denn es gibt einen starken Unterschied zwischen „wir müssen abwärtskompatibel zur Schnittstelle bleiben, die die letzten 5 Jahre den CPU-Markt dominiert hat“ und „die haben was verbockt und jetzt müssen wir den Bug in die CPU pflanzen“ ;)

NytroX hat geschrieben:Solange die nicht mit dem wahren Grund rausrücken, bleibt wohl alles was wir hier sagen eh Spekulation :-)

Ja stimmt. Der Eintrag ist wohl überarbeitet worden; neben einer Liste weiter unterstützter CPUs steht da jetzt auch

For Windows 7 to run on any modern silicon, device drivers and firmware need to emulate Windows 7’s expectations for interrupt processing, bus support, and power states- which is challenging for WiFi, graphics, security, and more. As partners make customizations to legacy device drivers, services, and firmware settings, customers are likely to see regressions with Windows 7 ongoing servicing.

Damit wird das Szenario klarer: Es wird einfach keine Windows-7-Treiber mehr geben und jede neue CPU läuft dann … im letzten kompatiblen Modus. Was schlimmstenfalls 32-Bit ist.

PS: Außerdem kamen bei meiner Begründung alle gut weg, lass mich doch einfach Mal an das Positive in der Welt glauben... :lol:

Tu ich doch! Ich hindere dich ja nicht daran, dir einfach die Augen zuzuhalten und LALALALALA weiterzusurfen ;)

Ja gut, "undefiniert" war vielleicht etwas zu extrem. Die Idee ging eher in die Richtung "ich kann einen schnelleren dispatch-mechanismus schreiben als 'switch-case', wenn ich nicht bei ANSI-C bleiben muss". Das heißt ja nicht, dass die JVM nicht funktioniert, aber ANSI-C ist das halt auch nicht mehr (nach ANSI-C also undefiniert, aber undefiniert != Bug). Und vielleicht muss ich bei neuen Platformen die "kreativen Programmierungen" nochmal genau prüfen; oder sie sind ggf. nicht mehr möglich - was genau dann sehr nachteilig sein kann, wenn man die Binary schon auf DVD gebrannt und millionenfach verkauft hatte ;)

"Augen zu" war damit jetzt nicht gemeint :lol: eher "Augen auf":
Solche Inkompatibilitäten sehen für die User immer schlimm aus, aber meistens geht es halt einfach darum, Altlasten abzubauen.
Jeder wird mit der Zeit besser, man macht ja selbst auch vieles anders als noch vor ein paar Jahren. Da häuft sich dann so allerhand an, was man nur so "mitschleppt"; das ist bei großen Firmen nicht anders.
Das ist eben einfach so, daran ist auch niemand "schuld", nur irgendwann muss man dann halt einen Strich ziehen und den alten Quatsch endlich loswerden.

(...ja..., ich hatte auch mal wieder ganz vergessen, dass da ja mittlerweile auch ne GPU usw. drin werkelt... und "supported" heißt ja, dass das alles unter Win7 laufen muss, inklusive der Treiber...)

Alexander Kornrumpf hat geschrieben:Vielleicht am Rande interessant, ich werfe es nur ein weil ich die Tage drübergescrollt bin:

https://media.ccc.de/v/32c3-7171-when_h ... _just_work

War wirklich interessant. Wenn der Typ nur nicht so eine Schlaftablette wäre :(

Für’s Thema wichtig ist nur Minute 46, in der er sich freut, dass endlich ein paar Altlasten rausfliegen (wohl auch A20).

Hi !

@krishty:

also so weit ich das verstanden habe ist das eigentliche Problem, dass die Software die Hardware ggf. nicht unterstützt und nicht umgekehrt.

Dies bedeutet, dass der Chip mit Windows 7 durchaus kompatibel wäre, allerdings seitens Windows scheinbar kein Support mehr herrscht.
Keine Ahnung allerdings aus welchem Grund letzteres der Fall sein könnte. Vielleicht sind Registeradressen anders und die neue CPU wird deshalb vom alten Betriebsystem nicht mehr unterstützt.


Kurzum: der Chip blockt da gar nichts

Gruss

RedGuy

Krishty hat geschrieben:Microsoft, AMD, Intel, u.a. haben angekündigt, dass sich ihre neuen CPUs nur noch mit Windows 10 betreiben lassen werden.

Das Ende von Linux? Unwahrscheinlich. Dann ist das eher das Ende von Microsoft, AMD und Intel. (seit wann stellt Microsoft CPUs her?)