"für die Zertifizierung von Windows 8"

[Lord Gamma]

Denn für die Zertifizierung von Windows 8 müssen die Geräte der Hardwarehersteller zwingend Secure-Boot unterstützten.

Nicht nur das. Die x86-basierten Geräte der Hardwarehersteller, müssen für die Zertifizierung von Windows 8 zwingend das Abschalten von Secure-Boot unterstützen. Von daher ist die "durch MS verursachte Unruhe" bis auf Weiteres absolut unberechtigt.

[Felix_Keyway]

Dies gilt nur für volle PCs. Bei x86-Tablets ist es optional.

[Lord Gamma]

Und warum steht dann offiziell bei MS [msdn.microsoft.com] unter der Überschrift "System.Fundamentals.Firmware.UEFISecureBoot" bei Punkt 18 etwas anderes?

Mandatory ... On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv.

[pythoneer]

Ich weiß es, ich weiß es *meld*, weil der Felix unrecht hat?

[SJ]

pythoneer schrieb:
--------------------------------------------------------------------------------
> Ich weiß es, ich weiß es *meld*, weil der Felix unrecht hat?

Ist das nun die Antwort oder eine Frage?

--
Wer all meine Fehler findet und die richtig zusammensetzt, erhält die geheime Formel wie man Eisen in Gold umwandeln kann.

[Zwangsangemeldet]

Lord Gamma schrieb:
--------------------------------------------------------------------------------
> Und warum steht dann offiziell bei MS msdn.microsoft.com unter der
> Überschrift "System.Fundamentals.Firmware.UEFISecureBoot" bei Punkt 18
> etwas anderes?
> Mandatory ... On non-ARM systems, it is required to implement the ability
> to disable Secure Boot via firmware setup. A physically present user must
> be allowed to disable Secure Boot via firmware setup without possession of
> PKpriv.

Wieso, da steht doch genau das: "On non-ARM systems, ..." - also auf ARM-Geräten ist es den Herstellern freigestellt, ob sie ihre Geräte auf Windows einlocken oder ob man damit auch was brauchbares machen kann.

Und dann noch ein schönes Zitat aus dem Link:
"Compatibility Support Modules are always prohibited on Connected Standby systems."
Das heißt, auf allen mobilen Geräten (auch Laptops), die "Connected Standby" unterstützen, darf RestrictedBoot auch nicht abschaltbar sein.

Folglich hat es M$ doch schon geschafft, ne ganze Menge Hardware von vornherein grundlegend unbrauchbar zu machen, weil nichts außer Windows drauf läuft. Bleibt zu hoffen, dass die Hersteller, die sich darauf eingelassen haben, darauf sitzenbleiben werden.

[Thaodan]

Dürfte die EU nicht was gehen tun können? (Eines der Dinge wo ich die EU gut finde).

Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
-- Georg Schramm

[Lala Satalin Deviluke]

So ist es.

Grüße vom Planeten Deviluke!

[Lala Satalin Deviluke]

Zwangsangemeldet schrieb:
--------------------------------------------------------------------------------
> Lord Gamma schrieb:
> ---------------------------------------------------------------------------
> -----
> > Und warum steht dann offiziell bei MS msdn.microsoft.com unter der
> > Überschrift "System.Fundamentals.Firmware.UEFISecureBoot" bei Punkt 18
> > etwas anderes?
> > Mandatory ... On non-ARM systems, it is required to implement the
> ability
> > to disable Secure Boot via firmware setup. A physically present user
> must
> > be allowed to disable Secure Boot via firmware setup without possession
> of
> > PKpriv.
>
> Wieso, da steht doch genau das: "On non-ARM systems, ..." - also auf
> ARM-Geräten ist es den Herstellern freigestellt, ob sie ihre Geräte auf
> Windows einlocken oder ob man damit auch was brauchbares machen kann.

Was will man schon mit ARM-Schnecken...

Grüße vom Planeten Deviluke!

[Lala Satalin Deviluke]

Ja es gibt sehr wenig Gründe FÜR die EU...

Grüße vom Planeten Deviluke!

[Lord Gamma]

Zwangsangemeldet schrieb:
--------------------------------------------------------------------------------
>
> Und dann noch ein schönes Zitat aus dem Link:
> "Compatibility Support Modules are always prohibited on Connected Standby
> systems."
> Das heißt, auf allen mobilen Geräten (auch Laptops), die "Connected
> Standby" unterstützen, darf RestrictedBoot auch nicht abschaltbar sein.
>

Da verwechselst du etwas. Es geht bei dem von dir erwähnten unter der Überschrift "System.Fundamentals.Firmware.UEFILegacyFallback" stehenden Punkt um das Legacy BIOS. UEFI kann man aber auch ohne "Secure Boot" haben. Also widerspricht das nicht der Anforderung, dass auf allen Non-ARM Geräten "Secure Boot" abschaltbar sein muss, denn das bedeutet ja nicht den Fallback ins Legacy BIOS und somit auch nicht die Erfordernis der "Compatibility Support Modules".

[Zwangsangemeldet]

Lord Gamma schrieb:
--------------------------------------------------------------------------------
> Da verwechselst du etwas. Es geht bei dem von dir erwähnten unter der
> Überschrift "System.Fundamentals.Firmware.UEFILegacyFallback" stehenden
> Punkt um das Legacy BIOS. UEFI kann man aber auch ohne "Secure Boot" haben.
> Also widerspricht das nicht der Anforderung, dass auf allen Non-ARM Geräten
> "Secure Boot" abschaltbar sein muss, denn das bedeutet ja nicht den
> Fallback ins Legacy BIOS und somit auch nicht die Erfordernis der
> "Compatibility Support Modules".

Umständlich ausgedrückt, aber meinetwegen. Damit bleiben die Geräte, die für vernünftige Betriebssysteme am interessantesten sind, nämlich die mit ARM-CPU (weil: Sparsam, schnell), aber trotzdem auf den Windows-Mist verdongelt.

[Lord Gamma]

Linux auf einem iPad zu installieren, ist allerdings auch nicht wirklich praktikabel.

[Zwangsangemeldet]

Genau das ist das Problem mit diesen relativ neuen Gerätekategorien (Smartphone/Tablet): Dadurch, dass diese zwar von der Hardware her Universalcomputer sind, aber die Trennung von Hard- und Software nicht mehr so strikt ausfällt, wie bei den PCs, ist die große Gefahr gegeben, dass diese Universalcomputer zu reinen "Appliances" reduziert werden - und dass man als Nutzer auch nicht mal mehr die Kontrolle hat, was darauf gerade läuft, weil man nicht die freiheit hat, zu entscheiden, was darauf laufen soll. Und genau das ist auch das Problem mit RestrictedBoot - es ist der erste Schritt einer längerfristigen Strategie von Microsoft, genau diesen eklatanten Nachteil auch auf den PC-Sektor auszuweiten.