Rust code in Linux kernel looks more likely as language team lead promises support Rust language team lead Josh Triplett has promised to support its use in the Linux kernel, saying: "I'd be happy to have the Linux kernel feeding into Rust language development priorities. If building Rustic interfaces within the kernel requires some additional language features, we should see what enhancements to the language …
Yes, it's got some very appealing ideas in it. Someone described Rust as making all those difficult things programmers were supposed to know about memory (lifetimes, sharing, mutability, etc.) compulsory, and it turns out that an awfully large number of us simply cheat all the time in C/C++.
It's certainly feels like a radical idea, bring some high level language safety to a systems language. Ada had a runtime (of varying size, depending on platform), Java had a bigger one, and almost everything since has had a runtime or interpreter of some sort. And then up pops Rust with many of the same features (plus more), compiled to native code.
I've been hoping that Linux would start considering embracing Rust. That it seems to be happening quite sensibly is very encouraging for the long term relevance of Linux. I had been getting worried that with MS (Windows), Google (Fuchsia) and Redox considering becoming, or already being, Rusty that there was a danger that Linux would become the last of the breed of ancient C dinosaurs with endless scope for memory faults. Seems not, and that's good news for us all.
Once all the nasty stuff is encapsulated in libraries C is no more dangerous to use than any language. There's almost no reason for raw malloc() or free() or raw arrays to be used in any application of any significant size once in house libraries are deveoped for it.
> Once all the nasty stuff is encapsulated in libraries C is no more dangerous to use than any language.
Disagree. C (and also C++ for that matter) is always just one small slip-up away from a hard crash, no matter how much you try to encapsulate. The problem is these languages cannot protect any abstractions you create. C++ looks like it does, which makes it even more treacherous than C.
A true high-level language is one where you never get only a core dump or an exception dialog box with hex in it. Instead you get an error message that tells what was violated, in terms of the source code. (Unless you are explicitly doing something hairy, like calling a module written in a low-level language, in that case all bets are off).
I don't know enough about Rust to say if it qualifies as a high-level language. I guess I have to study it.
"The problem is these languages cannot protect any abstractions you create."
But can Rust do so? The problem with C/C++ library encapsulation is that the lib developers cannot account for every possible corner use case. So some strange ones may slip through. But until someone can actually deliver on the promise of 100% compiler test coverage (which may be one of those NP-hard problems that computer scientists are always going on about), the bug has just been moved from the library to the compiler. I can code around library bugs. Doing so around compiler bugs may prove to be more difficult. Pretty soon your kernel is a bunch of in-line low level C or assembly wrapped in Rust.
"The problem with C/C++ library encapsulation is that the lib developers cannot account for every possible corner use case."
Yes they can. Moreover, it is a violation of tradecraft if they don't.
But way too many "library" developers don't know the tradecraft.
I say this as a mathematician whose been programming professionally for 24 years.
I don't know enough about Rust to say if it qualifies as a high-level language. I guess I have to study it. .... MacroRodent
And whenever told by studious others, it most certainly does qualify as a such, and able to activate and inter react with all lower-level SCADA Operations with instructions for the presentation of future directions never before imagined impossible, is it something of a revelatory gem, and for some and all who really should have known better, a cursed rebellious tongue on which devilish tasks founder and are forever perpetually to flounder and fizzle away/suddenly explode and practically disappear.
Methinks that make IT more than just a tad ESPecial and Engagingly Interesting.
What say y'all here, El Registering?
"A true high-level language"
You don't want a high level language with all its runtime crap in kernel code. You want something that compiles to assembler explicity -ie what the code says is what it does in assembler, no extra auto generated wrapper code. Thats one of the reasons C++ hasn't yet been used in the Linux kernel, there's too much implicit code generated by the compiler.
> You don't want a high level language with all its runtime crap in kernel code.
Yes, that is true. There are situations where you have to use a low -level language, despite its dangers, and kernels are the archetypical example. Still, a language that does smarter compile-time checking than C without adding "runtime crap" should be usable in kernels. I understand that is Rust's main claim to fame.
How about the Rust community start producing feature rich long standing quality performant applications for Linux first, instead of trying to nag their YAPL into the kernel. Also, we already had an OOOS. Remember that one, BeOS? Why not convert that into YAPL, or better yet write your own Rustix?
Until real substantial quality stuff start emerging out of the Rust community I don't want to hear about it. Nothing yet came close to C in terms of performance, simplicity and longevity. I'll be surprised if that ever changes.
Go and look at the CVEs for the kernel and note how many are caused by the language - double frees, null pointers, buffer overflows etc. A good half of them could have been stopped by Rust providing the code is running in safe mode as much as possible.
So that's the reason. I think the biggest issue is not the language per se but that it's underpinned by LLVM and to parse C bindings requires Clang and a bindgen tool so potentially there are issues with GNU keyword extensions in headers and the workflow to work out.
Go and look at the CVEs for the kernel and note how many are caused by the language - double frees, null pointers, buffer overflows etc.
That's not caused 'by' the language. The language doesn't write itself. It's caused by developers making codeing errors, using the language badly.
It is fair to say that the language makes it easy to make such errors, but the actual error is still the result of a developer making a mistake.
Fair enough, certainly sounds safer than C/C++, but that wasn't my point. I was replying to @DrXym who wrote (emphasis mine):
"... how many are caused by the language ..."
Double-frees, null pointer deref's etc. don't occur because the language made someone do it. They occur because a developer wrote a double-free or null-pointer deref in the code, the developer made an error, not 'the language'. That's the statement of a poor workman blaming their tools.
Just because a language does whatever you tell it to do is no reason for blaming it for doing what it was told to do ...
I know some people like to fixate on who's fault it is. However the point here is how many errors occur, their severity, and how they can be prevented. If RUST can reduce these a lot, then it has merit as a solution.
Being able to blame developers for mistakes doesn't solve those mistakes. They could be tired, have not been allocated enough time to complete a task, etc, none of which will be improved by pointing out to them that they made mistakes.
C lets you declare a buffer and gives exactly zero shits if you write off the front or end of it because it was not designed to stop that. Likewise it doesn't care if you call a NULL, which in itself is a magic number with special meaning. Or if you feed some other garbage pointer into something.
Rust stops those same issues at compile time or with an orderly panic at runtime. Ergo yes it is a problem caused by the language because it does not happen in this other language.
"Rust stops those same issues at compile time or with an orderly panic at runtime."
It can only stop it at compile time if it doesn't allow raw pointers full stop as the compiler would have to run the code to find out if any pointer would ever be incorrect. And runtime checking is all well and good, but it introduces a runtime overhead which in a kernel situaton you REALLY don't want.
Rust doesn't allow you to directly manipulate raw pointers, unless you explicitly say a block of code is "unsafe". "Unsafe" is a red flag to make you take extra care, and should be used very rarely.
You end up with the same code, as it's really just syntax to define sets of automatic checks.
Eg A C function that should have "if (ptr == null) fail;" at the top gets that autogenerated by Rust. The programmer cannot forget it or put it in the wrong place by mistake.
Which can sometimes result in slightly faster code: The Rust compiler can also notice that everything calling that has also said "must not be null", so it can put that the autogenerated check right at the beginning of the callstack, instead of the programmer writing it into every function "just in case" - much harder for the compiler to spot and optimize out.
1) It is NOT the same code. There are lots of ways to guarantee that a pointer is not null. Many of them don't involve a conditional branch.
2) Calling code "faster" because it is executed sooner is just weird. You get a (very) slight reduction in code size. Execution speed improvement is limited to improved cache utilization.
Rust doesn't use raw pointers in safe mode, it uses references (borrows in Rust parlance) and it makes sure that you cannot hold a reference outside of the lifetime of the thing it points at. All this compiles to zero at runtime.
There are runtime checks for other things generally there is better practice ways of doing those things in Rust, e.g. using iterators and slices instead of non-const indexing on arrays.
You can use pointers in unsafe blocks but you'd have no reason to except at a boundary interface, e.g. C calling Rust or vice versa and your unsafe block would encapsulate the action and no higher.
"You can use pointers in unsafe blocks but you'd have no reason to except at a boundary interface"
Good luck access anything that requires raw memory without them and if Rust is to be used in the kernel it'll be doing that frequently and if it has to be used in unsafe mode to do so then it has zero advantage over C.
“...zero advantage over C”
Well the first and obvious advantage is that you only need to worry about memory corruption vulnerabilities in the subset of code that you marked with the unsafe keyword, rather than the entire codebase (27 million LoC says hi). As a result you can spend all of your effort on a much smaller area and have much more confidence that it is safe.
As to having to use “raw memory” - Rust *does* access “raw memory”. It compiles to assembly language just like C. However the Rust compiler has a significant number of compile-time checks to ensure memory access will be safe at run time. Ergo it is basically as fast as C, and has far fewer vulnerabilities because you’ve just wiped out half a dozen classes of vulnerability at compile time.
Believe me - I hate doing vuln research on Rust code bases because 95% of the cheap RCE wins just don’t exist compared to C :( There are some crazy things that can happen in C that even experienced programmers make mistakes with, and where the language is broken (floats leaking memory content for example). Even stuff as innocuous as this can get you RCE -
size_t len = userSuppliedNumber;
unsigned char buf[len];
I love C but Rust is a great language, and I can see that because I bothered my arse to look into it. Linus’ concerns re: the compiler are valid, although gcc isn’t exactly covered in glory when it comes to “interesting” side effects and behaviour. Anyone wanting to work in systems programming would do well to look at both C and Rust, as it makes more of the jobs market available to you.
"floats leaking memory content for example"
Huh? How?
"Even stuff as innocuous as this can get you RCE -
size_t len = userSuppliedNumber;
unsigned char buf[len];"
Innocuous? No competent C developer would allow the user to potentially blow the stack like that.
I give you exhibit A: The Windows Server DNS server. Heap buffer overflow in C code with SYSTEM privs --> root RCE. See Patch Tuesday this month.
C.
(Yeah, I know the comment above is a stack overflow; same sort of principle.)
Ergo yes it is a problem caused by the language because it does not happen in this other language.
No. While it's probably mostly a semantic distinction (shit still happens after all), it's most definatly not a problem with the language, it's mistakes by the programmers.
The issue is the language allows programmers to make these simple mistakes, at the end of the day (compilter bugs aside) C just deals with pointers and does as it's told. It's just this lack of rigidity allows the mistakes to be easly made.
Whilst this is a bad thing, it's not a slight at programmers, everyone makes mistakes. However, having some idea of these mistakes and that you can make them does help minimise them. (Rather than just accepting them as a consiquence).
This will be just as true of Rust as any other language. (It's just that in Rust you've probably not given someone access to kernel memory by making the mistake, you've just caused a panic).
C was from a time when compilers and computers were unimaginably simple by todays standards, it's nice to see we finally have what sounds like a modern system level language to replace it.
Er yes. If Bad Thing can happen in one language and not in another then yes it can be said to have been caused by that language.
C's main strength is that it lets the programmer do what they like and trusts they know what they're doing. But even the best programmers make mistakes and those mistakes translate into bugs, time, money, even injury / death. Did you know that the automotive industry defined a subset of C called MISRA C (and spawned a veritable cottage industry of compliance checking tools) to lessen the chance of something calamitous happening? Why not go one step further and use a language that is designed to be safe by design?
I write functionally safe software as part of my day job, and while rust has some nice features, I couldn't advocate using it fo a FS project because it's just too immatue.
Yes, yes, rust is over 10 years old, but there were 6 releases this year alone. That's not stable. The static analysis tools I've seen all seem fairly primitive compared to those for, say C. Disclaimer: not checked rust sca tools for a while, so it's possible things have improved.
But when the rust language team lead writes on that lmkl thread that "I'd be happy to have the Linux kernel feeding into Rust language development priorities", it just screams "constantly evolving, not mature - avoid!". Rust can beat the safety drum all it wants, but unless and until it is stable and mature, I can't see it gaining any acceptance in the functional safety world.
Give it another 10 years then maybe, just maybe. But they need to nail it down and get out of the habit of doing a new release every few weeks.
Ergo yes it is a problem caused by the language because it does not happen in this other language.
It is not a problem caused by the language.
The language allows it to happen, but "allows" is not synomonous with "causes".
The language allows a bad coder to do bad code. A good coder will not make those mistakes.
Just like a bad craftsman might lose a finger to their chisel, whereas a good craftsman won't. Are you going to blame the chisel for causing the bad craftsman to lose their finger?
A good coder will not make those mistakes? I suspect there isn't a human alive who can write anything beyond a trivial C program without making some of those mistakes.
I have done C programming (including a lot of finding other people's bugs like one thread freeing memory that another thread is still using) and now I am doing Rust programming and the degree of control, precision, knowledge and certainty it gives you is liberating.
We need Rust because then a lot less human effort will go into fixing such hard to find bugs and a lot more into improving software in other ways. More efficient tools make us richer.
Sentiments like this justifying sloppy behavior on the part of the programmer are a major source of tire fire our industry has become.
I can hardly write five lines of code without some sort of bug. But guess what? I write 0 lines of production code without tests. What's more, I have the training to know when my tests are inadequate.
When I was at Google, the solution to memory leaks was often to grow the alloc. We had some small service that was running on 80G allocs (biggest available). I threw the flag, found the leak, fixed it. That service then ran on 10G or less.
Learn to find your own mistakes. Learn that the people who point out your mistakes are your best friend. Teach these lessons to others. And stop whining that your tools should stop you from playing the fool.
I see you like the idea of manually written tests that tell you about mistakes.
Wouldn't it be nice for the compiler to tell you about mistakes as well?
Automated compile-time tests?
A syntax that tells the compiler your assumptions, so it can check your code meets those?
Congratulations, you just reinvented Rust. (And ADA, to be fair)
"I can't remember the last time I actually built a kernel"
Dynamic modules have made kernel building almost unnecessary, especially if you're not using a device with limited hardware resources where a custom kernel would greatly limit the footprint, etc.. [that used to be a somewhat geek-popular thing, make your kernel as tiny as possible].
I've recently built FreeBSD kernels, most recently a version 13 kernel for an RPi 3 - I wanted to see how well it would work (It worked very well, so I left it running for several weeks with a PostgreSQL database server running on it to test database performance on an RPi for a customer). But if you're doing kernel dev on a module, you need to re-build a lot [but don't clean all first, or it'll take hours - must build incrementally].
Seriously, though, if you're working on a kernel module you do kernel builds a LOT. But otherwise, no real need these days.
but if you're doing 'make menuconfig' every time in Linux - consider 'make oldconfig' - save time. You can hand-edit the config files, too, which I believe is easier once you have something close to what you want. Then edit the config file(s) and 'make oldconfig' etc.. [I used to do this a lot with wifi routers a while back]
The simple way would be to ship the version used by the Kernel Devs with the kernel source. Then there would be no version mismatch when building the kernel. .... Steve Davies 3
Hmmm? Are you really sure you want to be doing that, Steve Davies 3, for it could be just like sharing how to make an atomic bomb whenever you just want to build a nuclear power plant ?
seeing as I've actually done kernel programming for Linux, FreeBSD, and even Windows (including bit-wiggle peripheral setup things and netfilter modules), I'd like to chime in with my significant concern that Rust inside the actual *kernel* is PROBABLY a bad idea. You need the low-level predictability and lightweight code of a language like C. Even C++ has been wholeheartedly rejected from being in the kernel, for similar reasons I might add.
My understanding of RUST suggests that this language is really _NOT_ well-suited towards the kind of programming that KERNEL programmers do. I'd like to suggest that a language like RUST might have a negative impact on kernel efficiency, memory footprint, and even reliability.
Remember: not everything running Linux has multiple cores, >32Gb of RAM and TB's of disk space available. Some machines might have a 4Mb flash (or even 2Mb) to load the kernel+userland from and still needs to run Linux. Saving that nickel on the BOM to reduce FLASH size down to "tiny" like that is an important feature. A lingo with too big of a footprint would RUIN this.
This is not to say there isn't room for what I'd call "Rust Support" in glibc (for example), which seems to be hinted at in an article linked to from this one. That would be fine with me, of course!
Though glibc and other things may actually be a part of (or closely associated with) the Linux kernel tree, this does not make it part of "the kernel". Still I couldn't see a Linux kernel ever NOT shipping with glibc.
Still, putting Rust code inside the actual kernel: It would (In My Bombastic Opinion) be WORSE for Linux than SystemD, Pulse Audio, or Wayland... combined!
"My understanding of RUST suggests that this language is really _NOT_ well-suited towards the kind of programming that KERNEL programmers do. I'd like to suggest that a language like RUST might have a negative impact on kernel efficiency, memory footprint, and even reliability."
You're completely wrong. Rust is designed to be a systems language. It's perfectly possible to write reliable, efficient bare-metal code using Rust.
C.
The answer to whether such-and-such is a systems language or not is to ask what language the language is written in. We tend to take the existence of compilers for granted but at one time there had to be the Ur-compiler, as it were, and with a true systems language like 'C' you'd bootstrap the compiler from earlier versions that incorporated subsets of the language.
I'm sure that there's plenty of room for a language like Rust to build components for the Linux OS -- but -- this language seems to rely on library support for it to be able to implement anything. A language like 'C' doesn't need any kind of library support -- its useful, possibly essential for most tasks -- but you really don't need anything to get a system running or even just incorporate a compiled module into a system that's built entirely from assembler level sphghetti.
Rust doesn’t require any kind of library support any more than C does. Both have a standard library (libc and libstd respectively) and should you delete those from your system you will find it becomes rather less useful. However, neither language *needs* those libs - they merely save you a lot of typing.
I’m secure code reviewing a few million lines of each (C/C++ and Rust) as we “speak”. The client is moving to Rust in a field that requires extraordinarily fast and reliable code. Not only is the Rust output able to match performance, it’s not a shitshow of buffer overflows, stack underflows, format strings etc. We’ll see a lot more Rust going forwards because it’s a good language.
At least use the language before commenting on its weaknesses rather than simply parroting what Dave said down the Nags Head (who likewise heard it third hand from someone scared that their skill set will be outdated and they won’t find much work in the future).
> It's perfectly possible to write reliable, efficient bare-metal code using Rust.
No. It's not.
If one's main motivation for advocating Rust over C as a systems programming language is one's inherent inability to handle C pointers correctly, I would suggest that systems programming falls outside one's area of competence in the first place.
Just sayin'.
Rust inside the kernel would probably be a bad idea; using Rust to write code to be compiled into the kernel is a whole other question. And one that the kernel /developers/ are not dead set against; and frankly they know more about this than you or I.
What I have noticed over the past years is that Rust as a language and community is highly divisive. My initial skepticism about it as a language has turned into outright disgust to the point where I as a senior developer who has worked on (commercial) projects involving everything from C and C++ to JavaScript and TypeScript now actively refuse to have anything to do with the language or its cult members. For that is what it feels like.
The fact that Rust needs an 'unsafe' keyword to function, that it doesn't just extend weak typing relative to C++, but actively encourages it. That it doesn't offer heap segmentation or heap access levels. That it is more like typing Python, with many of the same potential runtime issues due to type inference and logic errors from its very abstract syntax. That it doesn't offer contract-based programming, and abandons the intuitive nature of OOP for its own overly complicated, hard to learn and maintain 'alternative'.
My interactions with Rust fans have been less than amicable. When I try to point out the above facts and how Rust at no point would pass the Steelman requirements, it quickly gets hammered home that there is no intellectual debate possible. Rust good. C++ bad. And what is this 'Ada'?
Over the past years I have been moving more and more towards Ada development, finding in it everything that I missed in C++, and understanding why everything in Ada is there. My discussions with professional Ada developers (a lot from European defence companies) have been pleasant, in-depth and the Ada community as a whole has been nothing but graceful and interested in differing views. Among the C++ communities I venture in I have also noticed a strong interest in some aspects of Ada, especially its super-strong typing.
This all to say that the more Rust code appears in Open Source project, the more it risks pushing developers like myself away. Call it what you want, but to me this 'Rust' thing is something which I do neither relish nor tolerate, for reasons which I hope I have sufficiently articulated here.
Or maybe it could be your perspective. Obviously you prefer Ada, and it could be that as a result you come across more positively in your interactions in the Ada community. Rust is not trying to be Ada, and if most of your contribution to a forum is basically "you don't know what your doing, this isn't as good as Ada" then I wouldn't be surprised if that tested their patience. They seem a fairly pleasant bunch to me.
Oh and DBC is available in Rust.
general observation: your more in-depth analysis seems to make a lot of sense, and is not inconsistent with my initial (gut) reaction to all of this.
"When I try to point out the above facts and how Rust at no point would pass the Steelman requirements, it quickly gets hammered home that there is no intellectual debate possible"
like another 'religious war' in the programming world? yeah, we NEEDED THAT, *snark*.
I should look for examples of THIS kind of thing on my own, to see if I can get info about more than one person's experience with this... and if it's common, it's worth bellowing about.
Linux has become mission-critical software, and therefore they really need to move to something like Ada, which is designed from the ground up to be maintainable and suitable for mission-critical applications.
Any compiler changes are carefully vetted. With Linux as a major user, they will be even more carefully vetted.
Take the good ol' "Hello, World!" program written in C, C++ and Rust. Here's what I get when compiled with clang / clang++ 10.0 and rustc 1.39.0 on Fedora 31:
-rw-r--r--. 1 notafanof rust 1974 Jun 30 23:53 hello-c.ll
-rw-r--r--. 1 notafanof rust 9814 Jul 1 00:05 hello-cpp.ll
-rw-r--r--. 1 notafanof rust 11115 Jun 30 23:49 hello-rust.ll
-rwxr-xr-x. 1 notafanof rust 18328 Jun 30 23:51 hello-c
-rwxr-xr-x. 1 notafanof rust 18856 Jul 1 00:06 hello-cpp
-rwxr-xr-x. 1 notafanof rust 271328 Jul 1 00:04 hello-rust
%> size hello-c
text data bss dec hex filename
1252 532 16 1800 708 hello-c
%> size hello-rust
text data bss dec hex filename
182252 8616 544 191412 2ebb4 hello-rust
%> size hello-cpp
text data bss dec hex filename
2191 652 4 2847 b1f hello-cpp
The three *.ll files are the LLVM IR of the three programs, as emitted by the respective compilers.
Just take a look at the size of that Rust executable. Why does Rust need 182K of text segment to print "Hello, World!" on stdout?
By default Rust enables symbols and some other things to yield more useful runtime errors if code panics. i.e. if your hello world did a panic!() then you'd get a nice stack trace telling you the exact line it happened on.
If space was a premium then you can strip symbols, change the panic to simply abort, do link time optimization and even build a stripped down stdlib. There are articles on the web where people have built really tiny executables in Rust, e.g. a 10kb Windows app https://www.codeslow.com/2019/12/tiny-windows-executable-in-rust.html
But for the common use case space really isn't a big deal and it's better to have some useful debug messages if something goes wrong.
> By default Rust enables symbols and some other things [ ... ]
What are these other things?
Symbols have nothing to do with the programming language. They exist - or don't exist - independent of the language the program was written in. FORTRAN programs can have symbols. C programs can have symbols.
For this particular case, the C and C++ versions of the program have symbols too. I didn't strip them.
At any rate, symbols aren't written to the .text segment. So: No. Nothing to do with symbols, panic, abort(3C) or anything like that.
Userland programs don't panic. Only the kernel panics. Userland programs simply crash, for various reasons.
Why is the C version of the program 15 times smaller than the Rust version? Both versions of the program do one, and just one, same thing: they call write(2) to print an identical character sequence to the stdout file descriptor.
Just useless bloat caused by a sloppy language.
" they call write(2) to print an identical character sequence to the stdout file descriptor."
uh, wouldn't '2' be stderr? Not to pick nits or anything. icon for humor.
But yeah, this program shoudl be trivially small, only startup code for libc and call to 'main()', plus 'write()' call.
On FreeBSD, clang output was a 23128 byte binary. gcc8 however was 14160 bytes. I thought this was kind of interesting...
#include <unistd.h>
int main()
{
write(2, "hello world\n", 12);
}
> uh, wouldn't '2' be stderr?
write(2) -- the 2 in parens refers to the Section of the UNIX Programmer's Manual. As in Section 2 - System Calls.
abort(3C) -- Section 3 - Standard C Library.
sin(3M) -- Section 3 - Standard Math Library.
etc etc etc ...
The "other things" include an unwind mechanism that lets you get a nice stack trace. I mentioned you can turn that off to save memory - just abort instead of unwind. If you absolutely want small binaries you can do it. People are using Rust in embedded programming.
The point is that on a desktop, especially when developing code it is better to have useful diagnostics when things go wrong. And yeah maybe that overhead is wasted on a program that says hello. It's not wasted on a program that something meaningful. What you call bloat is actually a feature.
"But for the common use case space really isn't a big deal "
Except... when it comes to KERNEL programming! It is a completely different thing. Tiny and hyper-efficient. That's what KERNEL programming requires.
And for THAT reason, I question the "fit for purpose" of Rust as a kernel programming lingo.
You're forgetting that Rust by default links with its large std library.
Kernel-level code doesn't (and can't) use std so this hello, world stuff is comparing apple and oranges. You're comparing a std-linked executable to no-std kernel code, which has little overhead.
Anyway, build hello, world (hw) as a std binary with dynamic library loading and suddenly it's <15kB.
$ ls -l target/release/hw
-rwxr-xr-x 2 chris chris 14304 Jul 13 20:09 target/release/hw
$ size target/release/hw
text data bss dec hex filename
2009 632 8 2649 a59 target/release/hw
C.
> Anyway, build hello, world (hw) as a std binary with dynamic library loading and suddenly it's <15kB.
Not here:
%> ldd ./hello-rust
linux-vdso.so.1 (0x00007ffc9443c000)
libdl.so.2 => /lib64/libdl.so.2 (0x000014fc720b7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x000014fc72096000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000014fc7207b000)
libc.so.6 => /lib64/libc.so.6 (0x000014fc71eb5000)
/lib64/ld-linux-x86-64.so.2 (0x000014fc72139000)
%> file hello-rust
hello-rust: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=f58dbc13cc7cd51f02dd36e98cef083bf38be942, not stripped, too many notes (256)
Don't quite understand what "dynamic library loading" really means here. Unless it's explicitly statically linked - with -Bstatic, which isn't the case here - the default for Linux executables is dynamically linked. Which is what rustc produced.
If it was statically linked, ldd would print "not a dynamic executable" and report no dependencies. Nor would there be any DT_NEEDED dependencies recorded in the ELF.
The common use case: there are many more embedded Linux use cases than your x86 systems.
Space does matter. Number of institutions matter especially with energy limited devices. Batteries drain is real. Once you build something that runs for 20 years on batteries you start appreciating these concerns.
I have a question around the Human Resources aspect of going to Rust.
If a kernel module was submitted in Rust, and had issues, how many current kernel devs would be able to debug it in Rust, versus if it was a C/C++ module?
Are there enough skilled Rust kernel developers vs skilled C/C++ developers? Are you reducing the pool of relevant skilled developers by going to Rust? (Although if you get a huge decrease in errors, debugging time, and increased productivity due to not having to chase as many errors, that could cancel it out.)
How many current devs would be excluded from kernel development because they aren't interested in learning Rust? Say those who do it out of personal interest and have no need in their work life to learn Rust (e.g. in the twilight of their careers, or are mainframe developers that don't need Rust) therefore aren't keen on having to pick up a new skill set to continue the kernel development they've been doing for decades? Although I imagine it'd probably take decades for the kernel to convert fully to Rust - if ever - therefore devs in those positions would still have stuff to do, but only if they don't want to work on new and groovy kernel projects which may be in Rust.
There is no way that Linus will allow any rust in his kernel. He will grind it away and apply his zinC based anti-rust coating all over it. The same way he blocked a lot of C++ modules that were being written in the early 2000s.
Unfortunately there is no way you can get people to code is C these days. Maybe C++ but no self loathing tattooed hipster is going to want to touch C with a barge pole, much less any self-respecting one.
If Microsoft is saying "why we think that Rust represents the best alternative to C and C++ currently available." then what's the plan? Eliminate those buggy human programmers and use AI to write the next version in Rust?
All languages are the potential for bugs somewhere, but it's us programmers who actually create them, usually by not thinking that strings can overflow or that storing passwords in the cache might be a mistake, etc**10.
This:
https://blog.checkpoint.com/2020/07/14/sigred-this-is-not-just-another-vulnerability-patch-now-to-stop-the-next-cyber-pandemic/
Developers can't write secure code in any language - it is hard, and deadlines mean as soon as it code works, it goes out the door.
I look forward to Rust having a positive impact on systems and application security for my children.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
