6
Microsoft bestätigt DMA-Policy-Problem in Win10 v1709
https://support.microsoft.com/en-gb/help/4057300/devices-not-working-bef ...
Wer sein Gerät mit der DMA-Policy absichert, bekommt evtl. Hardwareprobleme in v1709 von Win10. Warum? Weil v1709 endlich "richtig" arbeitet und die Policy konsequent ("consistently") anwendet! So ist das nämlich. Und Schuld sind die Hardwarehersteller, also auf, auf und die anzählen, damit was passiert. MS wäscht seine Hände in Unschuld.
Wer sein Gerät mit der DMA-Policy absichert, bekommt evtl. Hardwareprobleme in v1709 von Win10. Warum? Weil v1709 endlich "richtig" arbeitet und die Policy konsequent ("consistently") anwendet! So ist das nämlich. Und Schuld sind die Hardwarehersteller, also auf, auf und die anzählen, damit was passiert. MS wäscht seine Hände in Unschuld.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 358325
Url: https://administrator.de/knowledge/microsoft-bestaetigt-dma-policy-problem-in-win10-v1709-358325.html
Ausgedruckt am: 23.12.2024 um 08:12 Uhr
6 Kommentare
Neuester Kommentar
Also nach kurzem Einlesen auf Wikipedia, um das ganze nachvollziehen zu können, besagt die Richtlinie, dass bei aktiviertem Bitlocker jedes mal die PCI-Slots deaktiviert werden, wenn der Benutzer das System sperrt... Sprich: Benutzer sperrt den Rechner -> Grafikkarte schaltet sich ab -> kein Bild mehr -> blindes Eintippen nötig?
Hi.
Nein, bei aktivierter Richtlinie werden lediglich keine neuen Geräte automatisch angebunden, wenn gesperrt.
Nein, bei aktivierter Richtlinie werden lediglich keine neuen Geräte automatisch angebunden, wenn gesperrt.
Korrekte Überschrift wäre wohl "Weitere Sicherheitslücke gefixt".
Das kommt aber scheinbar auch hier nicht so gut wie eine Überschrift "MS hat ein Problem".
Konsequenz ist, dass ich nicht mehr mit einem externen Gerät Zugriff auf einen gesperrten Rechner bekomme.
Ich würde das nicht als "Problem" bezeichnen.
Dass es eine Menge schlampig programmierter Gerätetreiber und Firmware gibt, kann nicht das Problem eines Betriebssystemherstellers sein (egal welcher).
Das kommt aber scheinbar auch hier nicht so gut wie eine Überschrift "MS hat ein Problem".
Konsequenz ist, dass ich nicht mehr mit einem externen Gerät Zugriff auf einen gesperrten Rechner bekomme.
Ich würde das nicht als "Problem" bezeichnen.
Dass es eine Menge schlampig programmierter Gerätetreiber und Firmware gibt, kann nicht das Problem eines Betriebssystemherstellers sein (egal welcher).
Es ist nicht das erste Mal, dass MS etwas zunächst nachlässig und erst dann konsequent durchsetzt bzw. zuerst Dinge optional und erst später verpflichtend macht. Ich sage nicht, dass MS etwas verkehrt macht. Es ist lediglich ein Beispiel dafür, wie Hardwarehersteller (Tausende), die nicht auf der Höhe sind, sich oft schlagartig vor gewaltigen Problemen sehen. Wie würde wohl ein HW-Hersteller reagieren, wenn Du bei ihm anklopfst, in etwa so: "Leute, wir haben hier Eure Ware gekauft als "kompatibel zu Win10" - nun, wir verwenden Win10 v1709 und sie ist nicht kompatibel, seht zu, dass ihr das in 48 Stunden fixt, sonst Regress, weil 1000 Geräte auf eine alte Windowsversion zurückgerollt werden müssen".
Microsoft hat diese Änderung vermutlich nirgendwo dokumentiert - dennoch wären Sie fein raus (zumindest in Ihren eigenen Augen).
Microsoft hat diese Änderung vermutlich nirgendwo dokumentiert - dennoch wären Sie fein raus (zumindest in Ihren eigenen Augen).
Ja - ist nicht die erste Sicherheitslücke, die von MS geschlossen wird.
Es gibt ein Zertifizierungsprogramm von MS, das jeder Hardwarehersteller in Anspruch nehmen kann.
Nicht billig, aber es soll Unternehmen geben, die diese Liste beachten und nichts anderes kaufen.
Steht das Gerät auf der Liste, dann sind sowohl der Gerätehersteller als auch MS in der Verantwortung, dass das Gerät auch nach dem Update funktioniert.
Klar ist, dass sich viele (Billig-)Gerätehersteller diese Zertifizierung sparen.
Dann, und insbesondere, wenn man mit "kompatibel zu Win10" wirbt, kann es eben peinlich und teuer sein, wenn etwas nicht sauber programmiert ist.
Wäre hier doch interessant zu wissen, welche Geräte sofort, welche irgendwann (nach wieviel Tagen des Wartens auf das Update) und welche nie laufen.
Ich vermute die Hersteller-Statistik wird dabei ähnlich sein wie seit jeher - soll heißen, es gibt Hersteller, die nur "billig" sind (Apple-Mentalität: "geht nicht, kauf den Nachfolger"), einige sind qualitativ durchwachsen und andere legen Wert auf brauchbare Treiber, kosten aber etwas mehr als andere.
Ich vermute nicht, dass das diese Funktionalität nicht dokumentiert ist.
An der BUS-Spezifikation waren einige hundert Unternehmen beteiligt, und MS definiert da mit Sicherheit nichts um, da sonst keine Hardware mehr mit Windows laufen würde.
D.h. die Funktionalität ist vorhanden seit es den BUS gibt, korrekt genutzt wird die von MS erst jetzt.
Da hatten die Gerätehersteller doch jahrelang Zeit ihre Software korrekt zu programmieren ;)
Hatte nicht Intel vor nicht allzu langer Zeit einen Chipsatz, der an einer ähnlichen (wenn nicht sogar derselben) Stelle Probleme hatte?
Das haben nicht viele bemerkt, der betroffene Chipsatz wurde meines Wissens nur auf Anfrage getauscht.
Wer nicht getauscht hat, könnte sich jetzt evt. ärgern?
Es gibt ein Zertifizierungsprogramm von MS, das jeder Hardwarehersteller in Anspruch nehmen kann.
Nicht billig, aber es soll Unternehmen geben, die diese Liste beachten und nichts anderes kaufen.
Steht das Gerät auf der Liste, dann sind sowohl der Gerätehersteller als auch MS in der Verantwortung, dass das Gerät auch nach dem Update funktioniert.
Klar ist, dass sich viele (Billig-)Gerätehersteller diese Zertifizierung sparen.
Dann, und insbesondere, wenn man mit "kompatibel zu Win10" wirbt, kann es eben peinlich und teuer sein, wenn etwas nicht sauber programmiert ist.
Wäre hier doch interessant zu wissen, welche Geräte sofort, welche irgendwann (nach wieviel Tagen des Wartens auf das Update) und welche nie laufen.
Ich vermute die Hersteller-Statistik wird dabei ähnlich sein wie seit jeher - soll heißen, es gibt Hersteller, die nur "billig" sind (Apple-Mentalität: "geht nicht, kauf den Nachfolger"), einige sind qualitativ durchwachsen und andere legen Wert auf brauchbare Treiber, kosten aber etwas mehr als andere.
Ich vermute nicht, dass das diese Funktionalität nicht dokumentiert ist.
An der BUS-Spezifikation waren einige hundert Unternehmen beteiligt, und MS definiert da mit Sicherheit nichts um, da sonst keine Hardware mehr mit Windows laufen würde.
D.h. die Funktionalität ist vorhanden seit es den BUS gibt, korrekt genutzt wird die von MS erst jetzt.
Da hatten die Gerätehersteller doch jahrelang Zeit ihre Software korrekt zu programmieren ;)
Hatte nicht Intel vor nicht allzu langer Zeit einen Chipsatz, der an einer ähnlichen (wenn nicht sogar derselben) Stelle Probleme hatte?
Das haben nicht viele bemerkt, der betroffene Chipsatz wurde meines Wissens nur auf Anfrage getauscht.
Wer nicht getauscht hat, könnte sich jetzt evt. ärgern?
1
Habe mich von dir angeregt mal auf die Suche gemacht: https://docs.microsoft.com/en-us/windows-hardware/design/compatibility/1 ... verlinkt unter "system requirements" Windows Hardware Compatibility Specifications for Windows 10, version 1709 - Systems , welches folgenden Abschnitt enthält:
Nun, so steht es Wort für Wort jedoch auch schon bei den Anforderungen für 1703 , eventuell in der Vorversion ebenfalls - von daher sollten die Hardwarehersteller schon länger wissen, wie sie das zu designen haben, damit sie vollständig kompatibel sind - einverstanden.
Was ich mir dennoch wünschen würde, wäre, dass Microsoft diese Verschärfung der DMA-Policy im Vorfeld ankündigt und einen Weg bietet, die eigenen Treiber/Geräte zu testen, denn deren Kompatibilitätslisten kann man ja getrost vergessen. Nehmen wir mal ein betroffenes Gerät: Dell Latitude 5580. Dieses Gerät ist bei Microsoft als kompatibel zu v1607 gelistet, siehe Suchergebnis auf http://sysdev.microsoft.com/en-US/hardware/lpl/ - was bringt uns das, wir wollen doch wissen, ob es mit neueren Versionen funktioniert - die neueren Listen gibt es jedoch noch gar nicht, sie sind lange überfällig! Und selbst wenn es sie geben würde... MS setzt dort einen Disclaimer hin, der alles erschlägt:
Edit: und noch einmal zu deinem "Konsequenz ist, dass ich nicht mehr mit einem externen Gerät Zugriff auf einen gesperrten Rechner bekomme." - nein, schlimmer. Konsequenz ist, dass die Geräte teilweise auch im entsperrten Betrieb nicht mehr funktionieren und das gilt sogar für interne Komponenten (WLAN-Karte, Onboard-Audiochip...).
System.Fundamentals.Firmware.NoExternalDMAOnBoot All external DMA ports must be off by default until the OS explicitly powers them through related controller(s). Applies to Windows 10 Client x64 Windows 10 Client x86 Windows 10 Mobile ARM Windows 10 Mobile ARM64 Windows 10 Mobile x86
Description The firmware must protect physical memory from unauthorized internal DMA (e.g. GPU accessing memory outside of video-specific memory) and all unauthorized DMA-capable external ports prior to boot, during boot, and until such time as the OS powers up DMA ports via related bridge controllers. When the device enters a low-power state, DMA port device context must be saved, and restored upon returning to active state. If the firmware has an option to enable and disable this protection, the shipping configuration must be with protection enabled, and turning protection off must be protected, for example with platform authentication via BIOS password. Note that this requirement precludes the use of attached storage as boot media if it can only be accessed via an external DMA-capable port.
Description The firmware must protect physical memory from unauthorized internal DMA (e.g. GPU accessing memory outside of video-specific memory) and all unauthorized DMA-capable external ports prior to boot, during boot, and until such time as the OS powers up DMA ports via related bridge controllers. When the device enters a low-power state, DMA port device context must be saved, and restored upon returning to active state. If the firmware has an option to enable and disable this protection, the shipping configuration must be with protection enabled, and turning protection off must be protected, for example with platform authentication via BIOS password. Note that this requirement precludes the use of attached storage as boot media if it can only be accessed via an external DMA-capable port.
Nun, so steht es Wort für Wort jedoch auch schon bei den Anforderungen für 1703 , eventuell in der Vorversion ebenfalls - von daher sollten die Hardwarehersteller schon länger wissen, wie sie das zu designen haben, damit sie vollständig kompatibel sind - einverstanden.
Was ich mir dennoch wünschen würde, wäre, dass Microsoft diese Verschärfung der DMA-Policy im Vorfeld ankündigt und einen Weg bietet, die eigenen Treiber/Geräte zu testen, denn deren Kompatibilitätslisten kann man ja getrost vergessen. Nehmen wir mal ein betroffenes Gerät: Dell Latitude 5580. Dieses Gerät ist bei Microsoft als kompatibel zu v1607 gelistet, siehe Suchergebnis auf http://sysdev.microsoft.com/en-US/hardware/lpl/ - was bringt uns das, wir wollen doch wissen, ob es mit neueren Versionen funktioniert - die neueren Listen gibt es jedoch noch gar nicht, sie sind lange überfällig! Und selbst wenn es sie geben würde... MS setzt dort einen Disclaimer hin, der alles erschlägt:
The Windows Compatible Products List is provided for informational purposes only. Microsoft makes no representations or warranties, expressed, implied or statutory, regarding the items, manufacturers or compatibility of the items depicted or described. Information within the Windows Compatible Products List is subject to change without notice.
Super, dann ist ja alles klar.Edit: und noch einmal zu deinem "Konsequenz ist, dass ich nicht mehr mit einem externen Gerät Zugriff auf einen gesperrten Rechner bekomme." - nein, schlimmer. Konsequenz ist, dass die Geräte teilweise auch im entsperrten Betrieb nicht mehr funktionieren und das gilt sogar für interne Komponenten (WLAN-Karte, Onboard-Audiochip...).
