Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Linux 4.1: Ext4 verschlüsselt sich…

KDBUS

  1. Thema

Neues Thema Ansicht wechseln


  1. KDBUS

    Autor: mnementh 27.04.15 - 13:53

    "Zudem sei D-Bus aktuell zu langsam, könne erst viel zu spät in der Startphase des Systems initialisiert werden, biete eine nur unzureichende Einbindung in das Sicherheitsframework SELinux und sei ohnehin äußerst fehleranfällig."
    Das ist das Argument FÜR die Einbindung von DBUS in den Kernel? Fehleranfällig und langsam wären ja eher Argumente gegen die Einbindung. KDBUS hat mit Sicherheit viele Vorteile, ich finde hier nur die Argumentation strange.

    Umgekehrt genauso: Linus lehnt das wegen der Metadaten ab? Wo ist da das tiefere Problem? Wenn jemand Debug-Optionen für den Kernel anstellt gibt es Informationen? Wenn jemand Debug für den Kernel anstellen kann, dann hat er wohl tiefgreifende Rechte, es sollten diese Infos dann wohl auch kaum ein Problem sein, oder?

  2. Re: KDBUS

    Autor: janoP 27.04.15 - 16:09

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > "Zudem sei D-Bus aktuell zu langsam, könne erst viel zu spät in der
    > Startphase des Systems initialisiert werden, biete eine nur unzureichende
    > Einbindung in das Sicherheitsframework SELinux und sei ohnehin äußerst
    > fehleranfällig."
    > Das ist das Argument FÜR die Einbindung von DBUS in den Kernel?
    > Fehleranfällig und langsam wären ja eher Argumente gegen die Einbindung.
    > KDBUS hat mit Sicherheit viele Vorteile, ich finde hier nur die
    > Argumentation strange.
    Wieso, wenn DBUS fehleranfällig ist, macht es doch Sinn, es durch KDBUS zu ersetzen.
    > Umgekehrt genauso: Linus lehnt das wegen der Metadaten ab? Wo ist da das
    > tiefere Problem? Wenn jemand Debug-Optionen für den Kernel anstellt gibt es
    > Informationen? Wenn jemand Debug für den Kernel anstellen kann, dann hat er
    > wohl tiefgreifende Rechte, es sollten diese Infos dann wohl auch kaum ein
    > Problem sein, oder?
    Ich glaube, du hast das nicht ganz richtig verstanden. Dbus hat nichts mit Debugging zu tun. DBus ist so eine Art Schnittstelle zur Kommunikation von Anwendungen. Das funktioniert zurzeit über einen Daemon, und der läuft Permanent ab Systemstart, da muss man keinen Debug-Modus für aktivieren. Mit KDBus soll es aber so implementiert werden, dass es direkt über den Kernel läuft.

    Du kannst, wenn du unter Linux arbeitest, auch mal in deinem Systemmonitor nach der Liste der Prozesse schauen, bzw mit "top" in der Kommandozeile. Da findet sich bestimmt ein Prozess, der DBus heißt.

  3. Re: KDBUS

    Autor: mnementh 27.04.15 - 17:28

    janoP schrieb:
    --------------------------------------------------------------------------------
    > mnementh schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > "Zudem sei D-Bus aktuell zu langsam, könne erst viel zu spät in der
    > > Startphase des Systems initialisiert werden, biete eine nur
    > unzureichende
    > > Einbindung in das Sicherheitsframework SELinux und sei ohnehin äußerst
    > > fehleranfällig."
    > > Das ist das Argument FÜR die Einbindung von DBUS in den Kernel?
    > > Fehleranfällig und langsam wären ja eher Argumente gegen die Einbindung.
    > > KDBUS hat mit Sicherheit viele Vorteile, ich finde hier nur die
    > > Argumentation strange.
    > Wieso, wenn DBUS fehleranfällig ist, macht es doch Sinn, es durch KDBUS zu
    > ersetzen.
    KDBUS ist ja IMHO die Entwicklung von DBUS-Funktionalitäten für den Kernelspace. Wenn also das Prinzip von DBUS fehleranfällig ist, dann ändert sich das auch nicht unbedingt wenn man das nun im Kernel macht.

    > > Umgekehrt genauso: Linus lehnt das wegen der Metadaten ab? Wo ist da das
    > > tiefere Problem? Wenn jemand Debug-Optionen für den Kernel anstellt gibt
    > es
    > > Informationen? Wenn jemand Debug für den Kernel anstellen kann, dann hat
    > er
    > > wohl tiefgreifende Rechte, es sollten diese Infos dann wohl auch kaum
    > ein
    > > Problem sein, oder?
    > Ich glaube, du hast das nicht ganz richtig verstanden. Dbus hat nichts mit
    > Debugging zu tun. DBus ist so eine Art Schnittstelle zur Kommunikation von
    > Anwendungen. Das funktioniert zurzeit über einen Daemon, und der läuft
    > Permanent ab Systemstart, da muss man keinen Debug-Modus für aktivieren.
    > Mit KDBus soll es aber so implementiert werden, dass es direkt über den
    > Kernel läuft.
    >
    Nö, das ist mir schon klar was DBUS/KDBUS tun. Aber die Kritik von Linus bezieht sich darauf, dass die Informationen kritisch sind und beim Anstellen von Debug leaken könnten: "In contrast, with the information in the kdbus message, it's almost
    certain that any random "enable debugging for dbus" patch will start
    logging it, because "it's just there"."
    http://lkml.iu.edu/hypermail/linux/kernel/1504.2/04913.html

  4. Re: KDBUS

    Autor: janoP 27.04.15 - 21:46

    mnementh schrieb:
    --------------------------------------------------------------------------------
    > janoP schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > mnementh schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > "Zudem sei D-Bus aktuell zu langsam, könne erst viel zu spät in der
    > > > Startphase des Systems initialisiert werden, biete eine nur
    > > unzureichende
    > > > Einbindung in das Sicherheitsframework SELinux und sei ohnehin äußerst
    > > > fehleranfällig."
    > > > Das ist das Argument FÜR die Einbindung von DBUS in den Kernel?
    > > > Fehleranfällig und langsam wären ja eher Argumente gegen die
    > Einbindung.
    > > > KDBUS hat mit Sicherheit viele Vorteile, ich finde hier nur die
    > > > Argumentation strange.
    > > Wieso, wenn DBUS fehleranfällig ist, macht es doch Sinn, es durch KDBUS
    > zu
    > > ersetzen.
    > KDBUS ist ja IMHO die Entwicklung von DBUS-Funktionalitäten für den
    > Kernelspace. Wenn also das Prinzip von DBUS fehleranfällig ist, dann ändert
    > sich das auch nicht unbedingt wenn man das nun im Kernel macht.
    Ja doch, weil es dann ja nicht mehr als Daemon laufen muss, und laut dem Artikel verursacht das ja die Schwierigkeiten.
    > > > Umgekehrt genauso: Linus lehnt das wegen der Metadaten ab? Wo ist da
    > das
    > > > tiefere Problem? Wenn jemand Debug-Optionen für den Kernel anstellt
    > gibt
    > > es
    > > > Informationen? Wenn jemand Debug für den Kernel anstellen kann, dann
    > hat
    > > er
    > > > wohl tiefgreifende Rechte, es sollten diese Infos dann wohl auch kaum
    > > ein
    > > > Problem sein, oder?
    > > Ich glaube, du hast das nicht ganz richtig verstanden. Dbus hat nichts
    > mit
    > > Debugging zu tun. DBus ist so eine Art Schnittstelle zur Kommunikation
    > von
    > > Anwendungen. Das funktioniert zurzeit über einen Daemon, und der läuft
    > > Permanent ab Systemstart, da muss man keinen Debug-Modus für aktivieren.
    > > Mit KDBus soll es aber so implementiert werden, dass es direkt über den
    > > Kernel läuft.
    > >
    > Nö, das ist mir schon klar was DBUS/KDBUS tun. Aber die Kritik von Linus
    > bezieht sich darauf, dass die Informationen kritisch sind und beim
    > Anstellen von Debug leaken könnten: "In contrast, with the information in
    > the kdbus message, it's almost
    > certain that any random "enable debugging for dbus" patch will start
    > logging it, because "it's just there"."
    > lkml.iu.edu

    Ok, sorry, habe nur den Artikel gelesen und mich nicht weiter um tiefergehende Informationen gekümmert bzw. Originalzitate bemüht.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. MVZ Labor Ludwigsburg GbR, Ludwigsburg
  2. SIZ Informatikzentrum der Sparkassenorganisation GmbH, Bonn
  3. Zweckverband Bodensee-Wasserversorgung, Stuttgart-Vaihingen
  4. BWI GmbH, Germersheim

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)
  2. 229€ (Bestpreis!)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Atari Portfolio im Retrotest: Endlich können wir unterwegs arbeiten!
Atari Portfolio im Retrotest
Endlich können wir unterwegs arbeiten!

Ende der 1980er Jahre waren tragbare PCs nicht gerade handlich, der Portfolio von Atari war eine willkommene Ausnahme: Der erste Palmtop-Computer der Welt war klein, leicht und weitestgehend DOS-kompatibel - ideal für Geschäftsreisende aus dem Jahr 1989 und Nerds aus dem Jahr 2019.
Ein Test von Tobias Költzsch

  1. Retrokonsole Hauptverantwortlicher des Atari VCS schmeißt hin

Rohstoffe: Lithium aus dem heißen Untergrund
Rohstoffe
Lithium aus dem heißen Untergrund

Liefern Geothermiekraftwerke in Südwestdeutschland bald nicht nur Strom und Wärme, sondern auch einen wichtigen Rohstoff für die Akkus von Smartphones, Tablets und Elektroautos? Das Thermalwasser hat einen so hohen Gehalt an Lithium, dass sich ein Abbau lohnen könnte. Doch es gibt auch Gegner.
Ein Bericht von Werner Pluta

  1. Wasserkraft Strom aus dem Strom
  2. Energie Wie Mikroben Methan mit Windstrom produzieren
  3. Erneuerbare Energien Die Energiewende braucht Wasserstoff

Minecraft Earth angespielt: Die Invasion der Klötzchen
Minecraft Earth angespielt
Die Invasion der Klötzchen

Kämpfe mit Skeletten im Stadtpark, Begegnungen mit Schweinchen im Einkaufszentrum: Golem.de hat Minecraft Earth ausprobiert. Trotz Sammelaspekten hat das AR-Spiel ein ganz anderes Konzept als Pokémon Go - aber spannend ist es ebenfalls.
Von Peter Steinlechner

  1. Microsoft Minecraft hat 112 Millionen Spieler im Monat
  2. Machine Learning Facebooks KI-Assistent hilft beim Bau von Minecraft-Werken
  3. Nvidia Minecraft bekommt Raytracing statt Super-Duper-Grafik

  1. FWA: Huawei verspricht schnellen Glasfaserausbau ohne Spleißen
    FWA
    Huawei verspricht schnellen Glasfaserausbau ohne Spleißen

    Huawei hat Komponenten für den Glasfaserausbau entwickelt, die das Spleißen überflüssig machen sollen. Statt in 360 Minuten könne mit End-to-End-Plug-and-Play der Prozess in nur 36 Minuten erfolgen.

  2. Live Captions: Pixel 4 blendet auf dem Gerät erzeugte Untertitel ein
    Live Captions
    Pixel 4 blendet auf dem Gerät erzeugte Untertitel ein

    Mit dem Pixel 4 führt Google seine neue Funktion Live Captions ein: Sobald ein Video oder eine Audiodatei auf dem Smartphone startet, können automatisch erzeugte Untertitel angezeigt werden. Transkribiert wird komplett auf dem Gerät selbst - bisher aber nur auf Englisch.

  3. VPN: Wireguard fliegt wegen Spendenaufruf aus Play Store
    VPN
    Wireguard fliegt wegen Spendenaufruf aus Play Store

    Die Android-App des freien Wireguard-VPN ist von Google aus dem Play Store entfernt worden. Der Grund dafür ist offenbar ein Spendenaufruf der Entwickler in ihrer eigenen App.


  1. 16:29

  2. 16:09

  3. 15:42

  4. 15:17

  5. 14:58

  6. 14:43

  7. 14:18

  8. 13:53