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?
> 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
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?
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...
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.
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.
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.
Wir haben an in unserer Arbeitsgruppe zwei Server mit jeweils 2TB RAM im Einsatz. Sind 64x32GB verbaut. Soviel RAM zur Verfügung zu haben, ist schon purer Luxus.
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.
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!
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?
> 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
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?
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...
Ist ein Feature von gcc:
https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/
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:
Warum nicht einfach als Keyword wie break,?
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.
> 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.
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.
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.
Ein HP BL460c Gen9 Blade kann man z.B. auf bis zu 2TB aufrüsten mit 16 * 128GB Modulen.
Eine z14 (s390x-Architektur) wird immer mit 3TB RAM ausgeliefert. Ob man die voll nutzen kann, hängt nur davon ab, wieviel man dafür zahlt.
Wir haben an in unserer Arbeitsgruppe zwei Server mit jeweils 2TB RAM im Einsatz. Sind 64x32GB verbaut. Soviel RAM zur Verfügung zu haben, ist schon purer Luxus.
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.
Open source heißt nicht entweder oder sondern sowohl als auch.
Ja, und? Benutzt du etwa alle? DU hast die Freiheit zu wählen!
Leider kein DKMS mit Nnvidia Grafik, und kein DKMS mit Virtualbox Gasterweiterungen.