LPC 2022: Rust Linux Drivers Capable Of Achieving Performance Comparable To C Code

[oiaohm]

Hey dude, you have to learn a language before you criticize it. Even if you write millions of lines of code, the C (and C++) compiler will tell you that you have made some mistakes. For example, if you compile the code

#include <stdio.h>

typedef struct _A {
int i;
} A;

A* f() {
A a;
a.i = 12;
return &a;
}

int main() {
A* p = f();
printf("%i\n", p->i);
return 0;
}
​

the compiler will issue the following warning:

ret-ptr-to-local.c: In function ‘A* f()’:
ret-ptr-to-local.c:10:10: warning: address of local variable ‘a’ returned [-Wreturn-local-addr]
10 | return &a;
| ^~
ret-ptr-to-local.c:8:5: note: declared here
8 | A a;
​

So, please stop spreading misinformation.

That only looks like 4 different CVE reported this year. You attempt todo the same with rust you don't get a compiler warning it simple will not build.

#pragma GCC diagnostic ignored "-Wreturn-local-addr"

The above was found in 3 of the cases this year.

Its not miss information. Compliers need to get more picky. Particular things that are currently warning need to be errors that programmer cannot disable. Yes return local address should be a error not a warning because there is no valid code that uses it.

The more common version of use local address in return.

int * f() {
int a, *b;
//declared at start of function
a = 12;
//defined to a value
// lines of code
b=&a;
// some like above on some optional path.
// lines of code
return b;
}
​

Then being wrapped in warning suppression zone of the code.

The one with return &a and it be local is directly is rare by CVE but it happened 4 times this year. Of course the function was a function that would only run if a error had happened in all 4 cases. So error followed by another error so general testing was not detecting goof.

[cardich]

the real world examples would have like 1000 lines of code from where something is declared as a local then by mistake turned into a pointer...

Hey dude, you have to learn a language before you criticize it. Even if you write millions of lines of code, the C (and C++) compiler will tell you that you have made some mistakes. For example, if you compile the code

#include <stdio.h>

typedef struct _A {
  int i;
} A;

A* f() {
  A a;
  a.i = 12;
  return &a;
}

int main() {
  A* p = f();
  printf("%i\n", p->i);
  return 0;
}
​

the compiler will issue the following warning:

ret-ptr-to-local.c: In function ‘A* f()’:
ret-ptr-to-local.c:10:10: warning: address of local variable ‘a’ returned [-Wreturn-local-addr]
   10 |   return &a;
      |          ^~
ret-ptr-to-local.c:8:5: note: declared here
    8 |   A a;
​

So, please stop spreading misinformation.

[oiaohm]

Hey dude, please stop kidding. Not even a schoolboy would return a pointer to a local variable (in function vec_new). The C code in your example is ridiculous. You are comparing ridiculously false code with correct code. Do you call it a comparison?
By the way, no serious C programmer uses homemade code for data structures. There are several packages for this. The first example that comes to mind is GLib (https://gitlab.gnome.org/GNOME/glib).
If you want to write your own code for vectors, lists, sets, and the like in plain C you must read a book like Schreiner's "Object-Oriented Programming With ANSI-C."
Of course, in C++ one would use the C++ STL library or the boost C++ library. C and C++ code is MUCH SAFER, much more controllable, and much more robust than code with toys like Rust and the likes.

Cardich there is a problem here you are well and truly over estimating the quality of developer work. About 20 CVE a year appear with a local variable being turned into local variable and then being returned.

No serious C program uses homemade code for data structures again CVE show you otherwise.

That example is very in the face vec_new issue the real world examples would have like 1000 lines of code from where something is declared as a local then by mistake turned into a pointer then like another 1000 to where it returned normally this would be a conditional fault as so the function would work right using correctly declared memory most of the time. Yes where you find stuff like this commonly sign of bad code. Once example was presented at a Linux conference where developer found this class of bug and by the time he was finished fixing the bug he had deleted 50000 lines of code that was replaced by 1 line of code lot of that was attempted fixes to race conditions. Yes the one line of code was correcting var from being local to what it should have been.

Cardich this is the scary point every fault that example you could using the last 5 years CVE put at least 1 CVE next to it. The most common there would be looking at about 900 CVE next to it and that is just over 5 years of CVE issues. Yes the one you picked out is not the rarest in that example to turn up as a CVE.

The reality here there are lot of developers releasing code on github or for business who are paid professionals who have not done the required reading how to correctly do object oriented programing in C who code in C and write their own structures so making defective code.

C++ is only safer if the coder is going to follow the safer way. The CVE example with local variable being turned into a pointer then returned some of those are in fact from C++ code bases so C++ is not magic solution to that problem.

Its about time you stop presuming real world paid professional developers in C and C++ are highly skilled. Spend some time looking at the CVE faults from C and C++ code bases. C++ turns out not to be MUCH Safer because people end up doing C stuff inside C++ code bases with all the same defects.

Something has to change. C and C++ as languages either need to evolve with the compilers coming more picky and developers forced to add extra information and prevent developers from being being able to do a stack without question bugs or they be replaced by something.

Cardich how many more years of CVE records do we need before we admit the reality that humans coding in C and C++ is a problem waiting to happen that we need to fix. Its like the saying absolute power corrupts absolutely or Murphy law.

Please note I am not saying that rust is the future. The examples of faults rust detects and prevents should be possible in C and C++ code bases but it will need compilers to be more picky and would never version of C and C++ standards mandating extra information be put in by programer.

Calling rust a toy language allows you to ignore that it successfully detecting particular faults and prevents programmers from doing those faults. We need to stop doing this. Rust has kind of set as standard in what kind of faults are compiler detectable and we need C and C++ compilers to step up and match this even if it requires language changes to C and C++.

This is an example of a dangling pointer.

Note the fault you complained about the write called a dangling pointer and you can use that to search CVE records for it. The 7 faults in the example the author include the name to go and look up CVE for them so you could see how they happen in real world and that they happen way too often.

[cardich]

https://willcrichton.net/notes/rust-memory-safety/

Open page see example I am not foolish enough to attempt create my own new example when very good examples already exist. That page has C and rust equals to each other. Yes has intentional worse case C example with faults that a C or C++ compiler will normally miss.

Hey dude, please stop kidding. Not even a schoolboy would return a pointer to a local variable (in function vec_new). The C code in your example is ridiculous. You are comparing ridiculously false code with correct code. Do you call it a comparison?
By the way, no serious C programmer uses homemade code for data structures. There are several packages for this. The first example that comes to mind is GLib (https://gitlab.gnome.org/GNOME/glib).
If you want to write your own code for vectors, lists, sets, and the like in plain C you must read a book like Schreiner's "Object-Oriented Programming With ANSI-C."
Of course, in C++ one would use the C++ STL library or the boost C++ library. C and C++ code is MUCH SAFER, much more controllable, and much more robust than code with toys like Rust and the likes.

[oiaohm]

Still no example. No code, too much prattling.

https://willcrichton.net/notes/rust-memory-safety/

Open page see example I am not foolish enough to attempt create my own new example when very good examples already exist. That page has C and rust equals to each other. Yes has intentional worse case C example with faults that a C or C++ compiler will normally miss. There are many existing website that have done this with rust. Basically cardich do you research and stop asking people to make new examples. There are many highly skilled people who have already made very good examples of the differences between C and C++.

yes errors like this in the example on that site

cardich you did not read everything I posted right. I was reference in what I was writing the example on the site I was quoting first.

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

This above is another way to fix the C/C++ problems. Yes fix/prevent them at runtime by altering the ISA itself.

Solutions to the C/C++ problems. Alter Language or make new language(rust path) both will not be backwards compatible to existing. Alter platform ISA this also the worst form of not backwards compatible as it basically everyone replace their hardware..

[cardich]

https://willcrichton.net/notes/rust-memory-safety/

Rust language is you must declare more about how memory will be used resulting in the rust compiler being able to be pick up defects with less processing.
Please note attempt since calculation of the missing information is not right all the time there are defects with C/C++ programs that get past that will not happen with rust...

Still no example. No code, too much prattling.

[oiaohm]

Why don't you give us an example (if any) instead of concocting unfathomable speculations?

https://willcrichton.net/notes/rust-memory-safety/

There are many write up on the topic its not speculations. There are many memory handling errors you can code in C that rust simple will not allow without jumping though a lot of hoops. The reason why rust will not allow is the language has extra information that you must include or it not valid rust that can be processed to validate memory operations. Yes that extra information can be include in C/C++ but you normal C/C++ compliers don't process it or mandate it.

More cases with rust will fail at compiler of source file to object than what C and C++ will. You see more cases be detected when you use LTO with gcc or llvm than without but this is still not as many cases as rust can detect due to language mandating more information about memory usage.

error[E0106]: missing lifetime specifier << yes errors like this in the example on that site are about lack of information that happened when they did a 1 to 1 C to rust conversion. This is something you find doing a 1 to 1 C to rust conversion in lot of cases will result in the rust compiler yell at you that you have missed declaring important things about how memory will be used. Without how the memory will be used information the compiler really cannot make correct judgement calls when you are doing source file to object file and when doing complete Link time optimization you are doing lot of processing to calculate this missing information to attempt to reduce C/C++ memory issues.

Lot of the information that rust language mandates can be calculated(take this a computer guessed) by complete program analysis. Please note this is a lot more processing to work out that hey I missed allocating X correctly so this is going to segfault or other memory fault.

Rust language is you must declare more about how memory will be used resulting in the rust compiler being able to be pick up defects with less processing.

Please note attempt since calculation of the missing information is not right all the time there are defects with C/C++ programs that get past that will not happen with rust as simply.

Do take into account I am not saying that rust is perfect. C and C++ language standards could be extended to mandate programmers include the extra information in future that the issues rust detects are detectable by a C/C++ compiler at the same stages but this would also be a backwards compatibility breaking change.

[arQon]

Why don't you give us an example (if any) instead of concocting unfathomable speculations?

erm... because it's reality, and there's no "speculation" at all to that statement? Not sure what your question / point is supposed to be.

[cardich]

if you screw up the Rust code will fail to compile; whereas the C++ code will fail at runtime

Why don't you give us an example (if any) instead of concocting unfathomable speculations?

[oiaohm]

No - in fact, it's provably as "perfect" / correct as Rust is.

That's not the point though, despite all the shouting you hear about it. The difference, and sole benefit of Rust, is that if (i.e. realistically "when", for any team of more than a handful of people) you screw up the Rust code will fail to compile; whereas the C++ code will fail at runtime. One of those outcomes is significantly more desirable than the other.

There is more to the difference than that. Static program analysis there exists Coverity and others like for C++ that do more than C and C++ compilers do these days.

Lot of the issues rust prevent using Coverity and other full program C++ tools will prevent as well. Then you notice something rust prevents the problem when you build a single object file but with C++ and C with extra notation cannot instead requires complete program source.

Note I said extra notation item that do extra notation is items like sparse with the Linux kernel. Rust language in fact more strict language on what has to be include so the information is there that issues can be solved in a single source file making a single object.

C++ code failing at runtime is not 100 percent correct. C++ code failing when complete program is built is the true answer. Remember full program being built this could be runtime or this could be complete program static analysis. Being at the complete program point is not ideal for productivity. Like you have modified one source file ideal is just remake that object and make the program for testing. C and C++ having to run complete program analysis or some form to find problems is really not ideal.

Over the years C and C++ compilers have been adding more and more Static program analysis but there is still the problem that the C and C++ language does not have the data to lot of the static program analysis without processing the complete program. Remember this is a bigger nightmare when people are using closed third party libraries because the C/C++ headers to standard don't in fact declare enough information to perform Static program analysis.

Rust fails when you make object for 100 percent of rust detectable faults.
C and C++ attempts with modern compilers to fail when you make object with items like address sanitizer but then you notice its missed stuff that it magically detects when you use link time optimization and yes link time optimization is running address sanitizer complete program where it has more information and has to perform lot of process to work out the information. Remember the faults rust prevents includes address sanitizer detected faults when you make the object.

The reality here C and C++ in theory are both fixable to be rust quality language. But the fix would be a code breaking change. As in compilers would have to refuse to build different C and C++ files until extra information is added describing how different items should behave.