Rust Null Block Driver Published To Begin Experimenting With Rust For Linux Storage

[marios]

Dude, the only reason you asked this question is to start another round of flame wars, simply because of your grand technical incompetence. You can ask the same question about *any* language with exactly the same outcome, depending on what kind of runtime checks are we talking about.

Is there a way to disable runtime checks when strcpy_s is used in the code, to "optimize your Gentoo builds"? If no, then C language is too slow for kernel development.

Nice try, but it is not the same. strcpy_s() is a library function, boundary checking on array accesses, is builtin into the language. In the one case, the developer uses it knowing of the performance overhead. In the other case, the developer uses it in full ignorance of the overhead, and in order to avoid it he has to go out of his way and write twice the amount of code. There is a way to disable runtime checks of strcpy_s, without even a recompile if it is dynamically linked, by overriding the default function implementation (using LD_PRELOAD for example).

PS. I didn't start a flame war, the guy who said that runtime tests can be disabled started it. I never believed it, but I hoped t was true. In the best case I would know of a flag that improves performance, in the worst case I would expose his lies. Maybe this guy was you, I am too bored to look for that.

[dremon_nl]

Nice try, but it is not the same. strcpy_s() is a library function, boundary checking on array accesses, is builtin into the language. In the one case, the developer uses it knowing of the performance overhead. In the other case, the developer uses it in full ignorance of the overhead, and in order to avoid it he has to go out of his way and write twice the amount of code. There is a way to disable runtime checks of strcpy_s, without even a recompile if it is dynamically linked, by overriding the default function implementation (using LD_PRELOAD for example).

PS. I didn't start a flame war, the guy who said that runtime tests can be disabled started it. I never believed it, but I hoped t was true. In the best case I would know of a flag that improves performance, in the worst case I would expose his lies. Maybe this guy was you, I am too bored to look for that.

It doesn't matter whether it's a language feature or a standard library function (which, by the way, is most likely a compiler intrinsic anyway in modern compilers) as soon as it's used in the code. The point here is that if the software is written with bounds checking in mind it would be absolutely stupid and pointless to disable those checks with any compiler flag or 'optimization' even if such a flag would exist.

Regarding the overhead and ignorance, I think it's actually other way around: the absolute performance at the expense of security must be a weighted opt-in, when you know what are you doing and when you really need it, like for kernel development. It should definitely not be a compiler flag which globally disables bounds checking on user input.

[marios]

It doesn't matter whether it's a language feature or a standard library function (which, by the way, is most likely a compiler intrinsic anyway in modern compilers) as soon as it's used in the code. The point here is that if the software is written with bounds checking in mind it would be absolutely stupid and pointless to disable those checks with any compiler flag or 'optimization' even if such a flag would exist.

Regarding the overhead and ignorance, I think it's actually other way around: the absolute performance at the expense of security must be a weighted opt-in, when you know what are you doing and when you really need it, like for kernel development. It should definitely not be a compiler flag which globally disables bounds checking on user input.

We can agree that we see things from different angles. If you want my opinion, any hardening (it is hardening, not security) option that introduces performance overhead should be disabled by default. There are cases that should be guarded, even at the expense of performance, but they are rare (for example,system calls should be protected against bad/malicious input arguments). The hardening-centric view of things, is acceptable, however I strongly disagree with it.
I find great difference between the standard library and the syntax of the language. Th syntax is the core of the language, while the standard library is the "extras". There are also cases, where there is no standard library (Linux kernel code for example). For you it might not matter, but for me it does. Finally, if the software is written with bounds checking in mind, it is badly written software. The C equivalent is shipping software that breaks with NDEBUG. I can discuss these all day, and I think it could clear things out.

On the other hand, your previous post was just trying to insult me. Accusing me of starting a flame war, because I asked clarification about a lie? Yes, telling "runtime checks can be disabled", is a lie if they can't, no matter the reason why the can't. I might have "grand technical incompetence" but you are not the one that can diagnose me with that. If you want an honest discussion, I am open to that. I think that you, unlike some others, can be reasonable if you want to.

[Developer12]

I do not see how that follows from what I wrote. The issues were fixed. Therefore, you are not fixing them again by doing a rewrite in rust.

The driver itself is mature code by this point, so there are not likely to be many unfixed issues of this nature left. Furthermore, it is solely a kernel development aid, so the already limited hypothetical benefit to memory safety from doing a rewrite in Rust is non-existent as far as production systems are concerned.

If the goal is to rewrite a driver that would benefit in the area of memory safety, pick something less mature such as something in the staging tree and rewrite that. If the goal is to give an example of how to write storage code in the kernel, then avoid distracting people from it by writing that memory safety will improve because of all of the long fixed issues in a mature driver.

The simple fact that *multiple* rounds of fixes have been applied demonstrates that there is no "it's fine, everything's fixed now." I'm sure after the first round of fixes people thought "well there can't possible be more" and yet it continues to see new fixes being needed to this day.

You're living in a fantasy world where "mature software" exists. News flash: that's total bullshit. Absolutely imaginary. There are bugs that continue to be found and fixed in BSD memory management code that dates back to 1981 and this is true of ALL C software.

[ryao]

The simple fact that *multiple* rounds of fixes have been applied demonstrates that there is no "it's fine, everything's fixed now." I'm sure after the first round of fixes people thought "well there can't possible be more" and yet it continues to see new fixes being needed to this day.

You're living in a fantasy world where "mature software" exists. News flash: that's total bullshit. Absolutely imaginary. There are bugs that continue to be found and fixed in BSD memory management code that dates back to 1981 and this is true of ALL C software.

It takes time for software to mature and multiple rounds of fixes will need to be done, but at some point, people stop finding things. For example, Linux 2.4.y stopped receiving fixes because no one found anything particularly serious for over a year. It would still be receiving regular fixes today if people had not stopped finding significant bugs. They were not finding many trivial/minor bugs by that point either.

Saying "There are bugs that continue to be found and fixed in BSD memory management code that dates back to 1981" is not even an example, since it needs a citation. If it had a citation, it could be a bad example, since you could simply port the code from 1981 and then start finding bugs that were long fixed in FreeBSD for example. If you find a bug in code that has been in regular use and maintenance for 3 decades, it probably is a fairly minor thing, so simply saying it had a bug is fairly meaningless. If you had a citation, it likely would be something of that nature.

That said, bugs being present in software applies to all non-trivial software that is not formally verified. They are not just in software written in C. They are in software written in every language, including Rust.

[oleid]

Nice try, but it is not the same. strcpy_s() is a library function, boundary checking on array accesses, is builtin into the language.

Actually, bound checks in rust are also library functions. There are default implementations of the index trait for slices etc. in the core library.

This is the trait:

https://doc.rust-lang.org/std/ops/trait.Index.html#tymethod.index

[ryao]

Actually, bound checks in rust are also library functions. There are default implementations of the index trait for slices etc. in the core library.

This is the trait:
https://doc.rust-lang.org/std/ops/tr...tymethod.index

He wants to avoid bounds checks that are not specified through the use of library functions such as those in the following example:

https://shnatsel.medium.com/how-to-avoid-bounds-checks-in-rust-without-unsafe-f65e618b4c1e

Library functions having bounds checks are tangential.

By the way, strcpy_s() Is a really bad example because it is part of appendix k that the standard states is optional. That has effectively made it non-portable as few platforms have implemented it and consequently next to no one uses it. I realize you are not the one who mentioned it, but since I am talking about it here, I thought I would add this.

[oleid]

He wants to avoid bounds checks that are not specified through the use of library functions such as those in the following example:

https://shnatsel.medium.com/how-to-avoid-bounds-checks-in-rust-without-unsafe-f65e618b4c1e

Library functions having bounds checks are tangential.

Yeah, I was taking about the same thing. They are defined in the core library. The code snippet on the page you linked also mentions the same index function I linked before.

[ryao]

Yeah, I was taking about the same thing. They are defined in the core library. The code snippet on the page you linked also mentions the same index function I linked before.

Are you saying that `fib[i] = fib[i-1] + fib[i-2];` involves library functions? What about in the case of the primitive array type?

This would not be a conscious choice by a developer like it would be with strlcpy(), where the developer is explicitly calling a library function that does a bounds check in place of the version that does not. I could see why users might want to disable Rust’s implicit bounds checks for a performance boost, since if a developer had properly handled this, there would be an explicit check to prevent the Rust compiler from emitting code to crash the program on out of bounds conditions. A compiler flag to disable bounds checks with the caveat that incorrect behavior will happen should an out of bounds operation occur seems reasonable. It would be trivial for a compiler to be modified to remove branches that jump to

core::panicking::panic_bounds_check

via a compiler switch, regardless of whether it comes from a library function or not. It could probably be done via a compiler plugin.

That being said, it would be trivial to disable strlcpy() via CPPFLAGS by specifying a macro through -D that replaces it with strlen(strcpy()) if someone wanted. If we believe your claim that these things are equivalent, then you just compared functionality that users seem to want from the Rust compiler to functionality that we already have from C compilers (although technically, it is from the C preprocessor).

I do not think the compiler implicitly mapping an operator to a library function is equivalent to strlcpy(). Instead, it would be equivalent to C’s division operator, which GCC implements through a library function for 64-bit numbers on 32-bit processors. That is purely an implementation choice that the compiler is free to make and does not make the compiler immune to requests for it to be turned off, which Linux does by telling GCC not to link the libgcc library that contains the library function. If you use / to divide 64-bit numbers on a 32-bit system in Linux kernel code in place of Linux’s own division function, GCC will emit code to call the non-existent function and things will either fail at link time or module load time.