linux-kernel - Re: [PATCH 00/45] C++: Convert the kernel to C++

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b931d02e-a414-4f5c-acc8-160d7b5e016a@gmail.com>
Date: Wed, 10 Jan 2024 16:01:52 +0100
From: Michael de Lang <kingoipo@...il.com>
To: "H. Peter Anvin" <hpa@...or.com>, David Howells <dhowells@...hat.com>,
 linux-kernel@...r.kernel.org, pinskia@...il.com
Subject: Re: [PATCH 00/45] C++: Convert the kernel to C++

Hey,

While I have done no work on the linux kernel, I hope to add to this 
discussion anyway. Forgive me if I'm intruding.

The arguments in favour of C++ so far focus on the technical and current 
kernel developers aspects. An extra argument in favour of C++ is the 
same one that Linus Torvalds recently mentioned in the keynote "Linus 
Torvalds in Conversation With Dirk Hohndel" w.r.t. Rust's impact on the 
Linux Kernel. Namely, to prevent stagnation for the Kernel as well as 
continue to be interesting to new developers.

One of the things holding me back from developping things in the Kernel 
is that C is, to put it bluntly, old and not interesting for my resume. 
Now there is certainly an argument to be made for "don't fix what ain't 
broken", as evidenced by the Kernel being in widespread use. But most of 
the interesting programming language progress has happened in C++ and 
other languages, unlike C. The aforementioned metaprogramming is one 
such example, but things like RAII, smart pointers and things like 
gsl::not_null would reduce the changes on kernel bugs, especially memory 
safety related bugs that are known to be vulnerable to security issues.

On the other hand, the benefits I mention can also turn into downsides: 
if constructs like gsl::not_null are desired, does that mean that there 
will be a kernel-specific template library? A KTL instead of STL? That 
might be yet another thing that increases the steepness of the kernel 
development learning curve.

I also have a note on the following:

> However, Linux also does conversion of polymorphic objects from one 
> type to another -- that is for example how device nodes are 
> implemented. Using this with C++ polymorphism without RTTI does 
> require some compiler-specific hacks, unfortunately. 

Although compiler-specific, C++20 has enabled implementing RTTI without 
RTTI as well as (partial) reflection. Examples include the JSON library 
Glaze as well as my own Dependency Injection framework Ichor. See 
https://godbolt.org/z/vaWszr9WG. On top of increasing the binary size, 
this then becomes a discussion on what requirements the kernel puts on 
compilers, as I'm sure that the kernel needs to be compiled for 
architectures which have a less than stellar conformance to the C++ 
specification. Regardless, this is IMO good food for thought.

Cheers,
Michael de Lang