1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Windows 7: Fehler in Beta zerstört…
  6. Thema

Windows mal wieder

Für Konsolen-Talk gibt es natürlich auch einen Raum ohne nerviges Gedöns oder Flamewar im Freiraum!
  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5

Neues Thema Ansicht wechseln


  1. was hat der kernel mit nem defekten treiber zu tun?

    Autor: xybvyxcb 09.01.09 - 13:14

    versteh ich nicht. :)

  2. Re: Mit Linux wär das nicht passiert

    Autor: blablup 09.01.09 - 13:14

    Das zeigt mal wieder da BetaOS nicht für jeden gedacht sind. Ob Linux oder Windows da ist leider das gejammere von irgend welchen Hobby Admins vorprogrammiert!!

  3. märchen

    Autor: xcxcbvxc 09.01.09 - 13:16

    man kann an der hardware nichts aufrufen, was diese nicht unterstützt. schlimmstenfalls stürzt das aufrufende programm/treiber ab.

  4. Re: was hat der kernel mit nem defekten treiber zu tun?

    Autor: Tantalus 09.01.09 - 13:17

    Das hier:
    http://bugzilla.kernel.org/show_bug.cgi?id=11382

    Gruß
    Tantalus

  5. Re: Linux zerstört dafür Hardware

    Autor: spanther 09.01.09 - 13:19

    asdfxsdfgdfg schrieb:
    -------------------------------------------------------
    > Leider doch :) Waren leider alle Distros betroffen
    > der diesen Kernel nutzte.


    Dieser Kernel wurde aber nicht genutzt von Ubuntu :-P

  6. na klar... ich lese mir jetzt nen bugtracker biblischen ausmasses durch

    Autor: xybvyxcb 09.01.09 - 13:20

    in den ersten 10-20 beiträgen wird nicht klar, was das nun genau mit dem kernel zu tun hat.

  7. Re: märchen

    Autor: Tantalus 09.01.09 - 13:24

    Das widerum hängt davon ab, wie sauber die Firmware programmiert ist, ob hierbei an alle Eventualitäten gedacht wurde (dass z.B. Werte ausserhalb eines bestimmten Bereichs nicht akzeptiert werden etc), und ob es nicht irgendwo eine Lücke gibt, durch die man Werte, die eigentlich nicht änderbar sein sollten, vielleicht doch änderbar sind...

    Gruß
    Tantalus

  8. Re: na klar... ich lese mir jetzt nen bugtracker biblischen ausmasses durch

    Autor: Tantalus 09.01.09 - 13:27

    Die erste Zeile unterhalb des Seitentitels gäbe schon mal einen gewissen Aufsachluss:
    >Kernel Bug Tracker Bug 11382

    Die Kurzversion: Der Treiber war (bzw. ist immer noch, aber eben in korregierter Version) Bestandteil des Kernels.

    Gruß
    Tantalus

  9. Re: märchen

    Autor: .ö..,., 09.01.09 - 13:29

    Eine saubere Firmware reicht nicht aus - denn ein Virus kann die unter Umständen umschreiben. Die Hardware müsste "sicher" sein - bei einem Modularen Aufbau kaum zu realisieren (vor allem, wenn man nicht alle Einstellungen per Jumper vornehmen will).

  10. Re: na klar... ich lese mir jetzt nen bugtracker biblischen ausmasses durch

    Autor: Meisterbräu 09.01.09 - 13:39

    So in the interests of adding some closure to this bug. The issue turns out to have never been the e1000e driver's fault. The fault lies with the CONFIG_DYNAMIC_FTRACE option. So specifically when the FTRACE code was enabled, it was doing a locked cmpxchg instruction on memory that had been previously used as __INIT code from some other module.

    a) some other module loads
    b) that module's init code calls into ftrace which stores the EIP
    c) that module discards its init code
    d) e1000e loads
    e) e1000e asks the kernel for memory to ioremap onto, and gets the memory location of the code at b) and maps the flash/NVM control registers there.
    f) ftraced runs and rewrites onto bytes 4-8 of the memory location from b/e
    g) since the lock/cmpxchg instruction is undefined for memory mapped registers, random junk is written to the b/e location
    h) depending on the contents of the junk in g) the NVM is either byte corrupted or block erased, which is detected the next time the e1000e driver is loaded.

    a short term workaround is in 2.6.27.1 (disable CONFIG_DYNAMIC_FTRACE) and the longer term fix is rewrites of the cmpxchg code (which is already done and will be in 2.6.28-rc1)

  11. Re: märchen

    Autor: spanther 09.01.09 - 13:44

    .ö..,., schrieb:
    -------------------------------------------------------
    > Eine saubere Firmware reicht nicht aus - denn ein
    > Virus kann die unter Umständen umschreiben. Die
    > Hardware müsste "sicher" sein - bei einem
    > Modularen Aufbau kaum zu realisieren (vor allem,
    > wenn man nicht alle Einstellungen per Jumper
    > vornehmen will).


    Die Hardware müsste einfach bis zum erbrechen getestet worden sein mitsamt der darauf enthaltenen Firmware und dann gelockt sein. Das man garnichts mehr an ihr oder der Firmware ändern kann!

  12. Re: märchen

    Autor: Tantalus 09.01.09 - 13:48

    In einer vollkommenen Welt wäre das wohl auch so. Aber 1. kann selbst eine "bis zum erbrechen geteste" Hardware Fehler aufweisen, die in den Tests nun mal nicht gefunden werden (da vermutlich niemals alle überhaupt möglichen Testszenarien nachgebildet werden können), und 2. soll das Teil ja auch noch in diesem Jahrhundert auf den Markt kommen. ;-)
    Wir weichen jetzt aber langsam echt vom Thema ab. :-P

    Gruß
    Tantalus

  13. Re: Windows mal wieder

    Autor: addydaddy 09.01.09 - 13:48

    Bin zwar Linux-Fan - wie Einigen bestimmt schon aufgefallen sein wird - aber das hätte auch mit Linux passieren können.

    Beta ist halt Beta.

  14. Re: märchen

    Autor: spanther 09.01.09 - 13:52

    Tantalus schrieb:
    -------------------------------------------------------
    > In einer vollkommenen Welt wäre das wohl auch so.
    > Aber 1. kann selbst eine "bis zum erbrechen
    > geteste" Hardware Fehler aufweisen, die in den
    > Tests nun mal nicht gefunden werden (da vermutlich
    > niemals alle überhaupt möglichen Testszenarien
    > nachgebildet werden können), und 2. soll das Teil
    > ja auch noch in diesem Jahrhundert auf den Markt
    > kommen. ;-)
    > Wir weichen jetzt aber langsam echt vom Thema ab.
    > :-P
    >
    > Gruß
    > Tantalus


    Dann halt eine Sperre die nur vom Hersteller wieder aufgemacht werden kann bzw. zumindest Hardwareseitig sperrt. Wobei die Hardwarefirmware dann ein Schutz hat welcher das ungewollte Überschreiben verhindert.

  15. Re: märchen

    Autor: Tantalus 09.01.09 - 14:20

    Auch auf die Gefahr, dass wir jetzt ganz ins off Topic rennen...
    Einen Hardwareseitigen Schutz bekommst Du ganz einfach, z.B. über einen Jumper, der (auf Hardwarebasis) bestimmte Speicherbereiche read-only setzt. Soweit so gut. Aber wie bitte soll die Firmware zwischen "gewolltem" und "ungewolltem" überschreiben unterscheiden? Das kann sie ebensowenig, wie das OS beurteilen kann, ob der Befehl zum Löschen oder Überschreiben einer Datei nun gewollt oder ungewollt ist. Auch hast Du damit nicht das Problem vom Tisch, dass die Firmware an sich Schwachstellen wie z.B. nicht abgefangene unzulässige Werte haben kann.

    Ergo:
    - Fehlerfreie Produkte, egal ob Hard- oder Software oder eine Kombination von beidem, kann es nicht geben, und
    - Software kann sehr wohl unter bestimmten Umständen Hardware zerstöre (oder zumindest unbrauchbar machen).

    Gruß
    Tantalus

  16. Re: Windows mal wieder

    Autor: sTein 09.01.09 - 14:25

    absolut korrekt

  17. Re: märchen

    Autor: spanther 09.01.09 - 14:25

    Tantalus schrieb:
    -------------------------------------------------------
    > Auch auf die Gefahr, dass wir jetzt ganz ins off
    > Topic rennen...
    > Einen Hardwareseitigen Schutz bekommst Du ganz
    > einfach, z.B. über einen Jumper, der (auf
    > Hardwarebasis) bestimmte Speicherbereiche
    > read-only setzt. Soweit so gut. Aber wie bitte
    > soll die Firmware zwischen "gewolltem" und
    > "ungewolltem" überschreiben unterscheiden? Das
    > kann sie ebensowenig, wie das OS beurteilen kann,
    > ob der Befehl zum Löschen oder Überschreiben einer
    > Datei nun gewollt oder ungewollt ist. Auch hast Du
    > damit nicht das Problem vom Tisch, dass die
    > Firmware an sich Schwachstellen wie z.B. nicht
    > abgefangene unzulässige Werte haben kann.
    >
    > Ergo:
    > - Fehlerfreie Produkte, egal ob Hard- oder
    > Software oder eine Kombination von beidem, kann es
    > nicht geben, und
    > - Software kann sehr wohl unter bestimmten
    > Umständen Hardware zerstöre (oder zumindest
    > unbrauchbar machen).
    >
    > Gruß
    > Tantalus


    Es kann immer alles trotzdem ist diese Jumper Idee für die Firmware eine ziemlich gute. Sollten die mal umsetzen...

    Nicht immer alles möglichst vereinfachen und immer weiter vereinfachen und damit in Wirklichkeit verschlimmbessern.

    Damits dann jeder DAU "sofort" kann ohne zu lernen dafür die Technik dann aber total viele Schwachstellen und Sicherheitskritische Probleme hat...

  18. Re: Linux zerstört dafür Hardware

    Autor: 42432 09.01.09 - 14:31

    Tja. Linux ist opensource.

    Was hier passiert ist .... ich sags lieber nicht

  19. Re: Linux zerstört dafür Hardware

    Autor: spanther 09.01.09 - 14:32

    42432 schrieb:
    -------------------------------------------------------
    > Tja. Linux ist opensource.
    >
    > Was hier passiert ist .... ich sags lieber nicht


    Doch sags :-)

  20. Re: Windows mal wieder

    Autor: IT-Knilch 09.01.09 - 14:44

    Man sollte natürlich wissen, das Beta-Versionen nunmal Fehler enthalten.
    Daher ist es anzuraten, persönliche Dateien vorher zu sichern.
    Wie auch immer:
    Die haben mal wieder richtig gepennt, bei M$! Nachvollziehbar sind solch gravierende Fehler jedenfalls nicht wirklich.

    Aber mal ehrlich: "Was sollte sich mit Windoof 7 auch signifikant verbessern"???
    Die leeren Versprechungen wie z. B. "DAS BESTE WINDOWS ALLER ZEITEN" ziehen sich von Version zu Version, wie ein roter Faden durch die Windowsgeschichte...

  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Nagel-Group | Kraftverkehr Nagel SE & Co. KG, Berlin, Hamburg, Frankfurt am Main, München
  2. IDS Imaging Development Systems GmbH, Obersulm
  3. Sachsenmilch Leppersdorf GmbH, Leppersdorf
  4. DAVASO GmbH, Leipzig-Mölkau

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Day 1 Edition PS4/Xbox One für 29,99€, Day 1 Edition PC für 49,99€)
  2. 219,99€ (Release 7.05.)
  3. (u. a. WD Blue SN550 1TB PCIe-SSD für 88€, Philips 65OLED855/12 65 Zoll OLED für 1.999€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme