Login
Newsletter
Werbung

Thema: Sicherheitsverbesserungen im Linux-Kernel 5.0

16 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Ghul am Fr, 15. März 2019 um 17:07 #

Die Compiler-Option -Wimplicit fall-through kann alle diese Fälle finden. Um allerdings keine falschen Warnungen zu erhalten, soll der Kernel von allen Stellen gesäubert werden, wo das break bewusst weggelassen wurde.

Und wie genau macht man das?

Baut man die Switchanweisung in if Anweisungen um?
Setzt man ein Kommentar als Codewort hin, mit dem man diese Stellen erkennen und ausfiltern kann?
Gibt es ein spezielles eventuell Compilerspezifisches Schlüsselwort, das eine no_break Anweisung markiert und der Compiler versteht, womit die obige Compiler Option dann nicht meckert?

[
| Versenden | Drucken ]
  • 0
    Von Anonymous am Fr, 15. März 2019 um 18:56 #

    > Setzt man ein Kommentar als Codewort hin, mit dem man diese Stellen erkennen und ausfiltern kann?

    So sieht's wohl aus, hier ein Beispiel:
    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit
    /?h=v5.0&id=fa2549800c84aecb7a9559cdb3978865d1d50513

    [
    | Versenden | Drucken ]
    • 0
      Von Ghul am Fr, 15. März 2019 um 19:27 #

      Besten Dank.

      Ist dieses Codewort in der Kerneldoku irgendwo hinterlegt oder bei den Kernelentwicklern als solches bekannt und definiert oder ist das jetzt nur etwas, was jemand für sich persönlich nutzt und die Stelle nur so kennzeichnet?

      [
      | Versenden | Drucken ]
      • 0
        Von Anonymous am Sa, 16. März 2019 um 09:52 #

        Hier ist noch was dazu, unter "ongoing: implicit fall-through removal":
        https://outflux.net/blog/archives/2019/03/12/security-things-in-linux-v5-0/

        Ich weiß nicht, ob es wirklich nötig ist, alle in Frage kommenden Stellen so zu kennzeichnen oder was das mit "Sicherheit" im engeren Sinn zu tun hat - aber wenn's hilft...

        [
        | Versenden | Drucken ]
        0
        Von Anonymous am So, 17. März 2019 um 11:59 #

        Ist ein Feature von gcc:
        https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/

        [
        | Versenden | Drucken ]
        • 0
          Von Ghul am So, 17. März 2019 um 15:16 #

          Danke für den Link.
          Es ist sogar ein Feature von C++17 und somit Sprachstandard, allerdings ist der Kernel natürlich in C geschrieben, weswegen das für C Code nicht gelten muss.

          Doof finde ich allerdings, dass man das als eckige Klammer realisiert hat:

          [[fallthrough]];

          Warum nicht einfach als Keyword wie break,?

          fallthrough;

          Da kann man sich mit den eckige Klammern jetzt wieder die Finger brechen. IMO völlig unnötig.
          Wer alten Code hat, der das als Funktion nutzt, kann ja dem Compiler sagen, dass er diese fallthrough Check nicht durchführen soll oder besser gleich seinen Code anpassen soll.
          Das Umbenennen sollte mit jedem guten Editor und jeder brauchbaren IDE kein Problem sein.

          [
          | Versenden | Drucken ]
          • 0
            Von Anonymous am So, 17. März 2019 um 16:41 #

            > Da kann man sich mit den eckige Klammern jetzt wieder die Finger brechen. IMO völlig unnötig.

            Tastaturbelegung ändern: Ich habe der linken Win-Taste den Wechsel in die 3. Ebene zugewiesen, das macht {[]} leichter.

            [
            | Versenden | Drucken ]
0
Von Ghul am Fr, 15. März 2019 um 18:11 #

Eine andere Arbeit dient zur Unterstützung der Pointer Authentication (PAC) von ARM64 und ermöglicht es, die entsprechenden Bits künftig auch für andere Zwecke zu nutzen. Bei diesen Bits handelt es sich um die höchsten Bits einer 64-Bit-Adresse, die normalerweise 0 sein müssten, da so viel adressierbares RAM nicht existiert. Sie können daher anderweitig verwendet werden. Diese Arbeit ist noch nicht vollständig.

Wie sieht es denn mit der Zukunftsfähigkeit von Binaries aus, die das benutzen?

Laut verlinktem Artikel werden bei ARM CPUs nur die ersten 40 Bits für reale Adressen benutzt, womit die Signatur 24 Bit breit sein könnte.
Wenn man die Signatur aber einbaut, was macht man dann mit Compilaten auf späteren CPUs, die mehr als die 40 Bits zum Adressieren des RAM nutzen?

2^40-1 Bits sind ca. 1024 GB an Arbeitsspeicher. Das ist für heutige Verhältnisse auch nicht mehr so viel, wenn man bedenkt, dass es auf der x86 Seite schon Rechner mit voll bestückten Speicherbänken mit insgesamt 256 GB gibt.
16 Speicherslots für DDR4 RAM * 16 GB Modulgröße = 256 GB.

[
| Versenden | Drucken ]
  • 0
    Von Ghul am Fr, 15. März 2019 um 18:16 #

    Bei registered ECC RAM, anstatt unbuffered gibt es sogar 32 GB große Module.
    Das mach also, sofern die CPU das beherrscht, schon 512 GB RAM.

    Und für DDR3 gibt es sogar Mainboards mit 32 Speicherslots.
    Womit ein Ausbau auf 32 * 32 GB RAM = 1024 GB RAM möglich wäre.
    Wie viel die XEONs wirklich adressieren könne, weiß ich gerade nicht, aber in Zukunft ist absehbar, dass die Größe des verfügbaren RAMs noch weiter steigt und das irgendwann so günstig wird, dass man auch 1024 GB RAM für jeden Wald und Wiesen PC kaufen kann.

    [
    | Versenden | Drucken ]
2
Von MichaelK am Sa, 16. März 2019 um 10:56 #

Ne echte Sicherheitsverbesserung wäre ja mal, wenn sie endlich die Architektur des Kernels modernisieren. Allen voran den Umbau zu einem echten Microkernel.

Auch mit gewissen Altlasten sollte man mal aufräumen um die Komplexität zu senken.
Wenn ich allein gucke, wieviel Sicherheitsframeworks (SELinux, Secomp usw. usw. usw.) nebeneinander existieren die dann sich oft auch überlappende Funktionalitäten haben, dann ist das einfach ein undurchdringbares Sammelsurium.

Hier gehört ein klares und durchgehendes Konzept her.

[
| Versenden | Drucken ]
  • 0
    Von Seelsorger am Mi, 20. März 2019 um 09:30 #

    Open source heißt nicht entweder oder sondern sowohl als auch.

    [
    | Versenden | Drucken ]
    0
    Von Moinsen am Mi, 20. März 2019 um 10:18 #

    Wenn ich allein gucke, wieviel Sicherheitsframeworks (SELinux, Secomp usw. usw. usw.) nebeneinander existieren die dann sich oft auch überlappende Funktionalitäten haben, dann ist das einfach ein undurchdringbares Sammelsurium.

    Ja, und? Benutzt du etwa alle? DU hast die Freiheit zu wählen!

    [
    | Versenden | Drucken ]
0
Von Andi123 am So, 17. März 2019 um 22:46 #

Leider kein DKMS mit Nnvidia Grafik, und kein DKMS mit Virtualbox Gasterweiterungen.

[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung