Secure Boot Backdoor in Windows 10 - was ist da dran?

Seit Windows 8 setzt Microsoft auf Secure Boot, um die Ausführung von Schadcode schon beim Systemstart zu verhindern. Obwohl Secure Boot gar keine Windows-Funktion ist, sondern ein Merkmal der UEFI-Firmware, sah sich Microsoft immer wieder kontroversen Diskussionen ausgesetzt. Ein Kritikpunkt war, dass die Redmonder dies als Waffe benutzen würden, um die Installation alternativer Betriebssysteme wie Linux zu verhindern. Das ist per Definition Unsinn, da sich Secure Boot bis auf wenige Ausnahmen in den UEFI-Einstellungen deaktivieren lässt.

Nun macht aktuell eine Geschichte die Runde, Microsoft habe im Rahmen der Entwicklung des Anniversary Updates eine Backdoor in Secure Boot eingebaut, die es ermögliche, den Schutz auszuhebeln und schon beim Start des Systems zusätzliche Komponenten zu laden. Zwei Versuche, diese Hintertür zu schließen, seien bislang gescheitert.

Die Geschichte kreist im Netz und es wird sich teilweise genüsslich darüber ausgeschüttet. Ich sage an diese Stelle ganz offen: Ich tue mich mit einer Bewertung schwer, soweit ich es aber bislang verstanden habe, scheint hier in der Tat ein grober Fehler gemacht worden zu sein, eine echte Sicherheits-Katastrophe aber kann ich nicht erkennen.

Basis aller News, die Ihr zu dem Thema eventuell schon gelesen habt, ist diese Veröffentlichung. Klickt den Link einfach mal an und dann werdet Ihr eventuell verstehen, warum ich meine Probleme damit habe, das ernst zu nehmen, noch bevor ich mit dem Lesen beginne.

Aber sei’s drum – was ist der Knackpunkt? Während der Entwicklungsphase des Anniversary Updates hat Microsoft eine Policy in Windows 10 integriert, die es grundsätzlich erlaubt, zusätzliche Betriebssystem-Komponenten (die allerdings signiert sein müssen) an Secure Boot vorbei zu laden. Die Dokumentation dieser Policy gelangte ins Netz und könnte nun auch von Hackern benutzt werden, so der Vorwurf.

Die beiden Entdecker der Lücke, die sich MY123 und Slipstream nennen, haben Microsoft nach eigener Aussage über die Schwachstelle informiert und seien zunächst abgeblitzt. Dann habe sich Microsoft aber anders entschieden und im Rahmen des Bug Bounty Programms eine Belohnung bezahlt. Es folgten zwei Sicherheitsupdates, MS16-094 im Juli und MS16-0100 im August. Diese würden, so wird zumindest behauptet, aber nicht das eigentliche Problem beheben, sondern nur dessen Folgen eingrenzen.

Ich habe bisher nirgends einen Bericht gefunden, in dem das Szenario erfolgreich reproduziert wurde. Alles, was wir haben, sind diese zwei Menschen, die erzählen, dass es so sei – und unzählige Medien, die es nacherzählen, so wie ich jetzt hier auch.

Was ich mit meinem Grundwissen über Secure Boot dazu sagen kann, ist:

Nach wie vor lässt sich Secure Boot auf den allermeisten PCs deaktivieren, hier sind also derlei Klimmzüge gar nicht nötig, um eigenen Code einzuschleusen, um z.B. ein anderes Betriebssystem zu installieren.

Die Gefahr, dass hierdurch trotz aktiviertem Secure Boot Schadcode ins System gelangen könnte, scheint nicht gegeben, die wird von den beiden Enthüllern auch gar nicht erst ins Spiel gebracht. DAS wäre für mich ein Grund, von einem Sicherheits-Debakel zu sprechen. Doch dies scheint wie gesagt nicht der Fall zu sein.

Sofern die Lücke durch die beiden Patches tatsächlich noch nicht beseitigt wurde, könnte sie dazu benutzt werden, auf den Geräten, bei denen Secure Boot nicht abschaltbar ist, ein anderes System als Windows zu installieren. Linux auf dem Surface, Android auf dem Lumia? Ohne genauere Details zu können, scheint das zumindest denkbar – ob das dann überhaupt vernünftig liefe, steht natürlich auf einem anderen Blatt.

Zusammenfassend kann man sagen, dass Microsoft offenbar einen Fehler gemacht hat, der zu einer grundsätzlichen Verwundbarkeit von Secure Boot in Windows 10 geführt hat. Durch die Auszahlung der Belohnung und die Veröffentlichung der beiden Patches haben sie das öffentlich eingestanden. Ob es dadurch aber wirklich zu unerwünschten und unbemerkten Effekten kommen kann, die den Anwender gefährden, kann derzeit offenbar nicht endgültig geklärt werden. Ich hoffe sehr, dass sich Microsoft zu dem Thema offiziell äußert und/oder jemand mit der entsprechenden Kompetenz das Szenario nachstellt.

Abschließend noch zwei unsachliche Links, wie sie unterschiedlicher nicht sein könnten: heise haut ordentlich drauf und versucht sich gar nicht erst an einer nüchternen Darstellung, während man bei Petri die ganze Sache offenbar für derart hanebüchen hält, dass man seine ganz eigene Form der Darstellung gewählt hat.

Über den Autor
Martin Geuß
  • Martin Geuß auf Facebook
  • Martin Geuß auf Twitter
Ich bin Martin Geuß, und wie unschwer zu erkennen ist, fühle ich mich in der Windows-Welt zu Hause. Seit mehr als elf Jahren lasse ich die Welt an dem teilhaben, was mir zu Windows und anderen Microsoft-Produkten durch den Kopf geht, und manchmal ist das sogar interessant. Das wichtigste Motto meiner Arbeit lautet: Von mir - für Euch!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.



Kommentare
  1. Hi Martin!
    Fein dass Du so sachlich berichtest, ich lese diese Seite immer wieder gern, obwohl ich
    inzwischen kein Windows Phone mehr habe, aber immer noch an den Themen interessiert bin.
    Hier ist auch eine differenziertere Darstellung zum Thema:
    'Hintertür' in Secure Boot: Wichtigster Windows-Schutz ausgehebelt - WinFuture.de
    Microsoft steckt halt in dem Dilemma, dass sie die Keys nicht so einfach ändern
    können, weil dann alle Backup Medien fehlschlagen werden.
    Andererseits müssen sie sich dann halt vorwerfen lassen, die Lücke nur halbherzig
    zu stopfen, was natürlich wieder den Verschwörungstheorethikern Vorschub liefert.
    Und die Entdecker sind natürlich auch nicht erfreut, wenn eine so lange reportete Lücke
    dann einfach nicht behandelt wird.
    Und die UEFI Software ist halt das Produkt von einem Firmenkonsortium, da mahlen die
    Mühlen wahrscheinlich noch langsamer (und es gibt wahrscheinlich viele differierende Interessen).
    Ich persönlich bin nicht mal überzeugt ob so was wie UEFI sinnvoll ist, die alten BIOSe
    waren inzwischen recht ausgereift und hatten eigentlich weniger Angriffsmöglichkeiten, wie
    das heute mit UEFI der Fall ist.....
    Heise war früher mal ein wirkich gutes Fachblatt.Leider hat sich dieses Blatt gewendet und dies schon seit einiger Zeit.Es ist kein grosser Unterschied zu Chip & Co. mehr zu erkennen.
    Plattform für Hobbyjournalisten !
    Heise war früher mal ein wirkich gutes Fachblatt.Leider hat sich dieses Blatt gewendet und dies schon seit einiger Zeit.Es ist kein grosser Unterschied zu Chip & Co. mehr zu erkennen.
    Plattform für Hobbyjournalisten !

    Da ist was dran. Heise hat in den letzten Jahren qualitativ extrem abgebaut und setzt zunehmend auf Effekthascherei. Mit einer seriösen und auch kritischen Haltung hat das alles nicht mehr viel zu tun, die man ja durchaus mal hier und dort anbringen könnte. Die Kommentare allerdings, die waren dort schon immer unterirdisch. Ich habe mich schon oft gefragt, ob es dort gar keine Moderatoren gibt, so wie die sich teilweise gegenseitig mit plumpen Beleidigungen angehen.
    Vor allem stört mich an den Artikeln dort immer öfter, daß sie kaum noch Meldungen überprüfen, oder wenigstens versuchen sie nachzustellen. Es wird einfach geschrieben, teilweise abgeschrieben und sehr viel ohne Belege behauptet.
    Die Ct war früher mal mein Lieblingsmagazin. Kompetent, sachlich, seriös, kritisch. Davon ist nicht mehr viel übrig. Unglaublich...
    Microsoft hat eine Anleitung geliefert, die eigene Schutzfunktion aus der Ferne (!) auszuhebeln, d.h. quasi den "Masterschlüssel" ins Netz gestellt. Damit können nun auch Rechner ausgehebelt werden, deren Secureboot eigentlich nicht auszuschalten war (MS-Eigene sowie OEM).
    (Man stelle sich vor, Volkswagen stellt den Mastercode für das öffnen aller Fahrzeuge aus der Ferne ins Netz.)
    Dieses "Draufhauen" kommt, weil Microsoft vorher alle Bedenken und Warnungen über Auswirkung bei potentieller Hardware-Stilllegung, Update-Szenarien, verantwortungsvollen Umgang etc. bezogen auf UEFI und Secureboot ignoriert hat und nun mit Vollgas vor die Wand gefahren ist.
    Nicht die Überbringer der schlechten Nachricht sind die Doofen.
    Der Auto-Vergleich hinkt gewaltig. Dennoch brauchen die bösen Buben immer noch den physischen Zugriff auf das Auto, also den Autoschlüssel. Nur dann können sie sich in das Auto reinsetzen und ihr eigenes Bootimage aufspielen.
    @Martin
    Linux auf dem Surface, Android auf dem Lumia? Ohne genauere Details zu können, scheint das zumindest denkbar - ob das dann überhaupt vernünftig liefe, steht natürlich auf einem anderen Blatt.

    ich weiß nicht genau, ob ich dich da jetzt richtig verstehe, aber zumindest Linux auf dem Surface ist überhaupt kein Problem
    Linux Ubuntu 15.04/10 auf Surface Pro 3 ? Holger Trampe
    und ich spreche aus Erfahrung, habe Linux auf meinem S3pro laufen
    Also ich fasse jetzt mal das Verstandene zusammen, jemand könnte heimlich, ohne dass ich was merke, auf meinem Rechner Linux installieren.
    Das wäre ja dann so, als würde ich in meinem original Laserschwert nur die Batterien einsetzen müssen um Kaffee zu kochen und es interessiert niemanden. ?
    @Rivn: Der Artikel von heise ist der Einzige, in dem ich lesen konnte, dass das Remote funktioniert. In der Veröffentlichung der beiden Entdecker steht davon nichts, oder ich habe es überlesen. Auch Microsoft schreibt in den Security Bulletins, dass man physischen Zugang zu dem PC braucht.
    Vielleicht es möglich, die entsprechende Policy Remote zu installieren. Um dann aber aktiv den eigenen Code einzubringen, muss man direkt an der Maschine sitzen. So habe ich das verstanden.
    Bedauerlicherweise hinkt der Vergleich nicht. Z.B. spielt BMW ihre Software-Updates aus der Ferne ein. Einige Hacker konnten sich Zugang auf Fahrzeuge mehrerer Hersteller verschaffen, um diese sogar zu steuern. Da ist kein physischer Zugriff erforderlich.
    Also ist bei Microsoft Geräten, jetzt das möglich, was bei Android schon immer ging? WOW ,ich bin begeistert (Sarkasmus aus)
    Martin
    @Rivn: Der Artikel von heise ist der Einzige, in dem ich lesen konnte, dass das Remote funktioniert. In der Veröffentlichung der beiden Entdecker steht davon nichts, oder ich habe es überlesen. Auch Microsoft schreibt in den Security Bulletins, dass man physischen Zugang zu dem PC braucht.
    Vielleicht es möglich, die entsprechende Policy Remote zu installieren. Um dann aber aktiv den eigenen Code einzubringen, muss man direkt an der Maschine sitzen. So habe ich das verstanden.

    Aber auch bei Heise steht, ich brauch Adminrechte... nun mit dem neuen Fernwartungstool / ala Teamviewer kann ich mit Adminrechten viel auf einem PC machen ^^
    <- Heise ist einfach LÄCHERLICH...
    Lustig ist der Kommentar: "Microsoft entwickelt sich immer mehr zu einem Unseriösen Entwickler... wie kann man so 'fatale' Fehler machen > ich bleib bei Windows 7" :P
    => da musste ich dann erstmal die Tränen aus den Augen wischen :'D
    @Martin: Wie kannst Du nur so ein Revolverblatt lesen?
    Aber ernsthaft, in der "Unterüberschrift" steht: Durch eine vergessene Debug-Funktion hat Microsoft jedem Administrator die Möglichkeit gegeben, Secure Boot auch aus der Ferne abzuschalten.
    Wenn Secureboot (unwissentlich) abgeschaltet werden kann und zudem Booten über Netzwerk aktiviert wird, hätten wir doch den Salat, oder?
    Also ich fasse jetzt mal das Verstandene zusammen, jemand könnte heimlich, ohne dass ich was merke, auf meinem Rechner Linux installieren.

    Ähm, nein. Ich denke nicht. So wie ich das verstehe, kann man Secure Boot durch diesen "Trick" überhaupt erst dazu bringen andere Systeme als Windows zuzulassen. Das bedeutet noch lange nicht, daß man aus der Ferne und heimlich dann auch etwas installieren kann. Dazu gehört dann schon mehr, außer dem ausgeschalteten Secure Boot. Im Prinzip kann man festhalten: Wenn Secure Boot aus = normales Gerät ohne Secure Boot = wo ist das große Sicherheitsproblem? Ein böser Schnitzer? Ja. Ein Sicherheitsdebakel? Nein, eher nicht.
    Und ob Secure Boot überhaupt aus der Ferne (ohne Zusatzsoftware, oder/und Remotezugriff) auszuhebeln ist, steht ja auch noch in den Sternen. Das konnte ich bisher nur bei Heise lesen, ohne großartige Erklärung dazu.
    @Rivn: Wenn es so wäre, wie es bei heise steht, dann wäre es fatal. Aber nicht mal an der Quelle der Enthüllung findet sich darauf ein Hinweis. Und wenn die Wurzel des Übels nur eine "vergessene Debug-Funktion" wäre, dann müsste man sich ja keine Mühe geben, diese zu patchen, sondern man könnte sie per Update einfach wieder entfernen.
    Mit der Sache selbst habe ich mich nicht genug beschäftigt, um das wirklich sachkundig beurteilen zu können. Aber nochmal mal ein grundsätzliches Wort zu Heise online. Es geht denen wahrscheinlich gar nicht in erster Linie um Clickbaiting, sondern darum, dass sie von ihren Lesern auch gelesen werden wollen, ja sogar müssen. Und die sind nun in der Mehrheit offenbar alles andere als MS-freundlich gesinnt. Es erwartet ja auch keiner, dass die junge welt kapitalismusfreundlich ist oder die National-Zeitung die Antifa lobt ;-)
    (Wobei Heise schon ein breit aufgestellter Verlag ist und z.B. die iX deutlich seriöser und neutraler informiert.)
    Rivn
    Microsoft hat eine Anleitung geliefert, die eigene Schutzfunktion aus der Ferne (!) auszuhebeln, d.h. quasi den "Masterschlüssel" ins Netz gestellt. Damit können nun auch Rechner ausgehebelt werden, deren Secureboot eigentlich nicht auszuschalten war (MS-Eigene sowie OEM).
    (Man stelle sich vor, Volkswagen stellt den Mastercode für das öffnen aller Fahrzeuge aus der Ferne ins Netz.)
    Dieses "Draufhauen" kommt, weil Microsoft vorher alle Bedenken und Warnungen über Auswirkung bei potentieller Hardware-Stilllegung, Update-Szenarien, verantwortungsvollen Umgang etc. bezogen auf UEFI und Secureboot ignoriert hat und nun mit Vollgas vor die Wand gefahren ist.
    Nicht die Überbringer der schlechten Nachricht sind die Doofen.

    Ein Autovergleich. Sehr orginell.
    Dieser Fehler betrifft Windows 10, 1607. Also nicht alle Windowsrechern.
    Bei den wenigsten Rechner ist das SecureBoot nicht ausschaltbar.
    Ansonsten braucht man physischen Zugang zum Rechner, Adminrechte und das Fehlen des Juni-Patches.
    Allein mit Zugang und Adminrechten kann man alles machen, wo nach einem der Sinn steht.
    Da braucht man dann den "goldenen Schlüssel" nicht.
    Rivn

    Wenn Secureboot (unwissentlich) abgeschaltet werden kann und zudem Booten über Netzwerk aktiviert wird, hätten wir doch den Salat, oder?

    Wie schaltet man SecureBoot unwissentlich ab?
    Vorallem wenn man den "Golden Schlüsseln" nutzt, um Übles zutun?
    Es geht bei dieser Lücke doch vor allem darum, daß man, entweder weil man einen direkten physikalischen Zugriff mit Adminrechten hat (dann ist sowieso Hopfen und Malz verloren), oder einen Remotezugriff mit Adminrechten (auch dann ist eigentlich Hopfen und Malz verloren), dadurch den Secure Boot bei Geräten ausschalten kann, bei denen es normalerweise nicht geht. Das war es auch schon. Vielleicht unschön, aber doch alles kein riesengroßes Drama. Vielleicht verstehe ich das Problem auch einfach nur nicht... Das ist ein Fehler, aber doch kein wirkliches Sicherheitsproblem.
    Ich denke, der Artikel bei El Reg bringt besser auf den Punkt, worum es bei der Geschichte geht:
    The Register: Bungling Microsoft singlehandedly proves that golden backdoor keys are a terrible idea
    Um es kurz zu machen: die konkreten Auswirkungen für die Sicherheit von PC-Nutzern sind im Moment vernachlässigbar. Secure Boot ist nur ein Sicherheitsmechanismus unter vielen, der vor falschen Treibern und Bootloadern schützen soll. Der worst case ist, daß dieser Sicherheitsmechanismus jetzt eben umgangen werden kann, was auch nicht schlimmer ist, als wenn man Secure Boot ganz ausschaltet. Es ist nur sehr peinlich für Microsoft.
    Jedoch ist die Geschichte ein glänzendes Beispiel dafür, warum kryptographische Backdoors eine schlechte Idee sind. Das FBI und andere Behörden fordern ja schon länger von den IT-Unternehmen, deren Schutzfunktionen mit Hintertüren auszustatten und den Generalschlüssel den Behörden zu überlassen. Fachleute halten dem entgegen, daß Kryptographie nur dann etwas taugt, wenn ein Generalschlüssel gar nicht vorgesehen ist. Gibt es nämlich einen, dann ist es nur eine Frage der Zeit, bis er in die falschen Hände gerät.
    Apropos Linux: Das überaus populäre Ubuntu hat lange selbst den Schutz ausgehebelt und trotz aktiviertem Secure Boot und signiertem Grub unsignierte Kernelmodule, etc. geladen. Selbst jetzt läßt sich der Schutz noch über ins System integrierte Funktionen umgehen. "Alarm, Alarm, Sicherheitsproblem, große Katastrophe"? Nein bei der c't nur ein Tip wie man Secure Boot umgehen kann: Secure-Boot-Einschränkungen bei Fedora und Ubuntu loswerden | c't Magazin
    Die Story, daß Microsoft mit Secure Boot lediglich andere Betriebssysteme blockieren wollte, hält sich auch immer noch im Netz und wird auch in den aktuellen Artikeln wieder aufgewärmt, obwohl fast alle Linux-Distributionen in der Lage sind, mit Secure Boot umzugehen. Mal davon abgesehen, daß Microsoft auf dem Desktop-Markt sowieso keine Konkurrenz hat und schon deswegen der Vorwurf hanebüchen ist. Um an die 2% Marktanteil von Linux zu kommen, führt man nicht Secure Boot ein.
    @Martin: Ich hoffe, dass dem nicht so ist. Die mit UEFI "gerufenen Geister" sollen die Integrität ein Systems sichern. In falschen Händen hilft es jedoch leider genauso, ein System unbemerkt zu kompromitieren.
    Wikipedia dazu: "..... ein mögliches Sicherheitsrisiko, da etwa mit dem implementierten Netzwerkstack die theoretische Möglichkeit bestünde, Daten unbemerkt vom Betriebssystem an eine beliebige Adresse zu senden. Der eigene Netzwerkstack für TCP/IP, der „unterhalb“ vom Betriebssystem direkt und unabhängig auf der Hauptplatine läuft, ermöglicht es, das System zu manipulieren, zu infizieren oder zu überwachen, ohne dass man es betriebssystemseitig kontrollieren oder einschränken könnte.". Es gibt eine Reihe von Talks auf verschiedenen Konferenzen zu dem Thema, z.B. CCC oder Black Hat.
    Unabhängig davon, wie akut die Bedrohungslage für aktuelle Rechner ist; Alle, die sich auf UEFI/Secureboot als eine Säule ihrer Sicherheitsstrategie verlassen, haben bis auf weiteres eine offene Flanke.
    @wori: Wie reflexartig & trivial am Kern der Aussage vorbei argumentiert. Schach ist wohl kein Hobby.
    @Martin: Ich hoffe nicht, dass du die Veröffentlichungsseite nur deshalb nicht ernst nimmst, weil sie ein anderes Design hat? Klar, ASCII macht immer ein bisschen den Eindruck, man hätte ein sehr altes Computerspiel vor sich. Über den Inhalt sagt letztlich das Design aber nichts aus. Der reiner Text ist dort mMn sehr gut zu lesen.
    Und zum Beweis, das ASCII eine zu unrecht verachtete Darstellungskunst ist: http://www.asciimation.co.nz/
    PexWeg
    Ich persönlich bin nicht mal überzeugt ob so was wie UEFI sinnvoll ist, die alten BIOSe
    waren inzwischen recht ausgereift und hatten eigentlich weniger Angriffsmöglichkeiten, wie
    das heute mit UEFI der Fall ist.....

    BIOS ist unzumutbar... Null portabel, null erweiterbar, 16-bit Adressierung, MBR und langsam, da auf Interrupts statt normale Funktionsaufrufe gesetzt wird.
    build10240
    Apropos Linux: Das überaus populäre Ubuntu hat lange selbst den Schutz ausgehebelt und trotz aktiviertem Secure Boot und signiertem Grub unsignierte Kernelmodule, etc. geladen. Selbst jetzt läßt sich der Schutz noch über ins System integrierte Funktionen umgehen.

    Nein... Secure Boot benutzt die EFI Authentification-Protokolle, um die von UEFI geladenen Komponenten zu überprüfen - also, seine Treiber, was auch immer der Boardhersteller noch so lädt und den OS Loader. Microsoft hat sich dazu entschieden, diese Protokolle ebenfalls zu verwenden, um Treiber zu verifizieren. Da wird also kein Schutz umgangen, sondern einfach nicht genutzt. Sobald ein OS Loader geladen ist, kann er laden, was er will, ob signiert oder nicht.
    Diese Lücke wird genutzt, um auf Maschinen, bei denen Secure Boot nicht abschaltbar ist, nicht von Microsoft signierte Treiber zu laden. Die Regelung zu Zeiten von Windows 8 war, dass alle x86-basierte Maschinen eine Möglichkeit zum Abschalten haben müssen und ARM-Geräte nicht dürfen. Das hat sich mit Windows 10 zwar wieder geändert, aber ich glaube nicht, dass die OEMs jetzt alle schnell den Schalter rausnehmen.
    Bedauerlicherweise hinkt der Vergleich nicht. Z.B. spielt BMW ihre Software-Updates aus der Ferne ein.

    Es ist dadurch schon zu fast Unfällen gekommen. Weiterhin ist es Teams gelungen, sogar die Lenkung während der Fahrt (!) zu manipulieren!
    Bei dem Linux auf Surface geht es nicht um die Pro oder Intel-Geräte sondern um das Surface RT oder das Surface 2 wo das abschalten von SecureBoot eigentlich nicht möglich ist und durch diesen Hack endlich ermöglicht wurde. Jetzt kann man auf Android oder Windows 10 Mobile auf den Geräten hoffen... :)
    Das beste sind die Kommentare unter der heise news :)

    Nee, lieber nicht. Das tue ich mir nur noch an, wenn ich wirklich richtig gute Laune habe und sie ohne Probleme deutlich schlechter sein könnte, ohne gleich in einen gefährlichen Bereich zu kommen. :lol
    Linux kann man so oder so bei aktiviertem Secureboot installieren. Ubuntu und Fedora unterstützen es nativ, bei anderen Distros muss man PreLoader oder Shim installieren oder seinen Bootloader und Kernel selbst signieren.
    Da müßte ersma der Sourcecode von W10m frei verfügbar sein, inkl Treiber für die Hardware der RT - Tablets, es sei denn W10m und RT sind so eng verwandt, daß man die Alten irgendwie einbauen kann, durch Anpassen der Kernel-Sourcen, denn vom RT-Treiber gibts ja keinen Quellcode. So lassen sich unter Android manchmal Komponenten mit alten StockRom-Treibern über mehrere Android-Generationen ansteuern, oft aber auch nicht.
    zlot555
    Bei dem Linux auf Surface geht es nicht um die Pro oder Intel-Geräte sondern um das Surface RT oder das Surface 2 wo das abschalten von SecureBoot eigentlich nicht möglich ist und durch diesen Hack endlich ermöglicht wurde. Jetzt kann man auf Android oder Windows 10 Mobile auf den Geräten hoffen... :)
    Wie soll das möglich sein? Auf den ARM-Surface läuft kein Windows 10 sondern nur Windows RT, die aktuelle Lücke wurde meines Wissens per Update aber nur an Geräte mit Windows-10-Desktop ausgeliefert. Über eine angebliche Lücke in Secure Boot des Surface RT konnte man vor einigen Monaten lesen, scheint aber keine weiteren Nachrichten zu dem Thema zu geben.
    Anders als bei Android dürfte die Verteilung eines angepaßten Windows 10 Mobile lizenzrechtlich kritisch sein. Microsoft dürfte etwas dagegen haben und dementsprechend dürfte es das nur aus wenig vertrauensvoller Quelle geben.
Nach oben