Login
Newsletter
Werbung

Thema: Linux 2.6.12 freigegeben

14 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Jörg am So, 19. Juni 2005 um 20:22 #
Das was da angesteuert wird, sind keine "richtigen" TPM-Funktionen, sondern soll nur als Alibi herhalten. Es wird nur eine Möglichkeit zur Hardware-Speicherung, Generierung und Verifizierung von Keys sowie der schnellen Ver- und Entschlüsselung geboten. Mit dem eigentlichen TPM, der Kontrolle von Code, der in die Pipelines kommen kann, hat das nichts zu tun.
[
| Versenden | Drucken ]
  • 0
    Von Sebalin am So, 19. Juni 2005 um 20:38 #
    Das was da angesteuert wird, sind keine "richtigen" TPM-Funktionen, sondern soll nur als Alibi
    herhalten.... Mit dem eigentlichen TPM, ... hat das nichts zu tun.

    Aber es hört sich doch wenigstens erstmal gut an.... ;)

    Sebastian.

    [
    | Versenden | Drucken ]
    0
    Von thomas001 am So, 19. Juni 2005 um 21:21 #
    mehr als das was du schreibst kann der chip doch eh nicht ;-)
    [
    | Versenden | Drucken ]
    0
    Von mr.peavey am So, 19. Juni 2005 um 21:42 #
    [...] und Verifizierung von Keys sowie der schnellen Ver- und Entschlüsselung geboten.

    bist du dir da sicher, dass der TPM eine schnellere ver- und entschlüsselung liefert?
    .. ich bin mir da seit heute nicht mehr sicher, hab das bis vorhin auch gedacht, aber auf der projekt seite von TrouSerS http://trousers.sourceforge.net/faq.html steht:

    3.3 - Is the TPM a cryptographic accelerator?
    No. The TPM was not intended to be a cryptographic accelerator and in fact software is many times faster than a TPM. [...]

    würd mich sehr interessieren ob es tatsächlich soviel langsamer ist, oder ob du recht hast und es schnelle ver- und entschlüsselung bietet.

    schönen sonntag abend :)

    [
    | Versenden | Drucken ]
    • 0
      Von Kai F. Lahmann am So, 19. Juni 2005 um 21:49 #
      btw. die Hardware der TPMs müsste durchaus interessant sein - eine Integer-Engine, die auf sehr sehr große Zahlen optimiert ist...
      [
      | Versenden | Drucken ]
    0
    Von Kai F. Lahmann am So, 19. Juni 2005 um 21:49 #
    [x] du hast keine Ahnung vom TPM.
    [
    | Versenden | Drucken ]
    0
    Von allo am So, 19. Juni 2005 um 21:55 #
    tpm!= tcpa

    Es wiord das tpm voll unterstützt.

    [
    | Versenden | Drucken ]
    • 0
      Von L00NIX am Di, 21. Juni 2005 um 09:59 #
      ...und ich dachte TCPA ist out, TPM ist in.

      Die Hersteller haben den Namen der Spezifikation nach der
      schlechten Presse geändert. Oder ist TPM ein eingeschränktes
      TCPA?

      Vgl.: http://www.heise.de/newsticker/meldung/41897


      Gruß
      L00NIX

      [
      | Versenden | Drucken ]
      • 0
        Von fuffy am Di, 21. Juni 2005 um 14:08 #
        > ...und ich dachte TCPA ist out, TPM ist in.
        TCPA ist out. Die Nachfolgeorganisation heißt aber TCG (Trusted Computing Group).

        TPM (Trusted Platform Module) ist der Chip, der sich um die Signierung und Verschlüsselung kümmert.

        [
        | Versenden | Drucken ]
0
Von Jörg W Mittag am So, 19. Juni 2005 um 22:16 #
> Offensichtlich ist man sich aber auch jetzt noch nicht über den Treiber einig, denn kurz vor der Freigabe des Kernels entfernte der Kernel-Hacker Alan Cox wieder einige Teile des Treibers, welche die PWC-Treiber-Kompression betrafen.

Das Problem liegt nicht in irgendeiner Uneinigkeit. Es besteht die Möglichkeit, dass der Open-Source-Dekomprimierungscode durch illegale Methoden, sprich simples Dekompilieren statt sauberem Reverse-Engineering gewonnen wurde. Solange darüber keine Klarheit besteht, sind die Kernelentwickler verständlicherweise vorsichtig.

jwm

[
| Versenden | Drucken ]
  • 0
    Von Jochen Römling am Mo, 20. Juni 2005 um 09:23 #
    Dank "git" ist das aber kein Problem mehr.

    Der Commit von Alan Cox, der die Routinen entfernte, ist dieser hier.

    Darin einfach auf "commitdiff" und dann auf "plain" clicken und man erhält diesen Patch, der (wenn man sich im Kernel-Hauptverzeichnis z.B. /usr/src/linux befindet) mit
    cat patch.txt | patch -p1 -R
    reverted werden kann und schon ist die Funktionalität wieder da :-)

    [
    | Versenden | Drucken ]
0
Von Peter am So, 19. Juni 2005 um 23:52 #
>So ist es möglich Journaling-Dateisysteme nun auch über SATA angebundenen Festplatten zu benutzen.
Dieser Satz hat mich ja schon erschrocken, habe hier seit einiger Zeit ein system mit ext3 auf einer 200gb sATA platte installiert, habe ich etwas verpasst? Vielleicht hat ja jemand ein link zur Problematik damit ich mich schlau machen kann, habe schon eben gegoogled, aber nichts gefunden.
[
| Versenden | Drucken ]
  • 0
    Von wer am Mo, 20. Juni 2005 um 01:35 #
    Soweit ich das verstanden wir beim Journaling erst das Journal mit den vorgesehenen Änderungen geschrieben und dann die Daten selber, danach wird die erfolgreiche Aktion im Journal quittiert. So ist sichergestellt, daß, wenn es zu einem Absturz wärend Plattenaktionen kommt, kein inkonsistenter Zustand herrschten kann. Ohne "Write-Barriers" kann nicht festgelegt werden, ob die Daten, das Journal oder die Quittierung zuerst geschrieben wird, das kann zu defekten Dateien führen, wenn die Speicherung nicht korrekt verlief. Wenn alles gut geht, merkt man keinen Unterschied. Nur ist das Journaling nicht 100% sicher.
    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung