Rust For The Linux Kernel Sent Out For Review A Fourth Time

[tyolotd]

Looks dead to me. They're getting into some really serious issues now, like how to make Rust support optional (not all architectures support Rust, for instance IBM POWER and RISC-V). I don't have faith that they'll be able to resolve them.

[jacob]

I have a very old LG LCD tv that has an USB for service only. With a simple universal remote a series of clicks activated the media player function that was supposed to be disabled in that model. Same instructions said that using an infrared emitter connected to an audio jack and playing an mp3 file could achieve the same results. Not exactly the same scenario but it is a bit of a proof of concept.

TV security is probably non existent.

I imagine that more advanced remotes may exist in the future making them a more interesting target.

TV security is obviously nonexistent. Just to clarify I was not talking about attacking code within the TV using the remote, I was talking about the code in the remote itself. I really don't see how that one could have any security implications however badly implemented it may be.

[darkonix]

How would the payload get into the remote in the first place? If it's an antifeature or a built-in backdoor, it can be implemented in Rust just as well. The point is that if the remote is not harmful by itself but the code in it is crappy, then it's basically inexploitable.

I have a very old LG LCD tv that has an USB for service only. With a simple universal remote a series of clicks activated the media player function that was supposed to be disabled in that model. Same instructions said that using an infrared emitter connected to an audio jack and playing an mp3 file could achieve the same results. Not exactly the same scenario but it is a bit of a proof of concept.

TV security is probably non existent.

I imagine that more advanced remotes may exist in the future making them a more interesting target.

[jacob]

So... you agree it it can deliver a payload to the TV to hack the TV, right?

How would the payload get into the remote in the first place? If it's an antifeature or a built-in backdoor, it can be implemented in Rust just as well. The point is that if the remote is not harmful by itself but the code in it is crappy, then it's basically inexploitable.

[billyswong]

So... you agree it it can deliver a payload to the TV to hack the TV, right?

I guess the point is a TV should never trust input signal received from the infrared remote to be conformant to any scheme in the first place. One don't need to hack the TV remote; one can use a custom "remote" to send arbitrary infrared signal to the TV.

[darkonix]

A remote can send messages to the TV over infrared but never actually receives any input. All it does is react to keypresses, one at a time. So even if the code it runs is theoretically vulnerable as hell, in the context there is basically no way to exploit it.

So... you agree it it can deliver a payload to the TV to hack the TV, right?

[jacob]

The remote could be an attack vector for your smart TV, which is basically a computer with a big screen, and may have network access and even a microphone and camera. A cheap TV remote sounds an interesting target. But let's not tell that to the various governments sponsoring high level hacking organizations just yet ;-)

A remote can send messages to the TV over infrared but never actually receives any input. All it does is react to keypresses, one at a time. So even if the code it runs is theoretically vulnerable as hell, in the context there is basically no way to exploit it.

[darkonix]

Of course you also need to consider the case for using Rust in the first place on such a ultra low end, ultra cheap microcontroller. If you are writing code for a TV remote, the safety guarantee requirements are exactly zilch, so there is no actual problem with using plain C if it means less workarounds.

The remote could be an attack vector for your smart TV, which is basically a computer with a big screen, and may have network access and even a microphone and camera. A cheap TV remote sounds an interesting target. But let's not tell that to the various governments sponsoring high level hacking organizations just yet ;-)

[jacob]

Nothing prevents people from writing the same kind of code they were already writing in C though. You don't have to rely on monomorphism at that level. But even if you do, it's still generating code that you would have otherwise have written by hand anyway. And there are ways to give hints to the compiler to encourage it to not inline anything. There's also some useful crates that can automatically convert impl return types into enums, which are 10x faster than trait objects while not needing allocations.

But I wouldn't be so quick to judge the memory consumption of monomorphism. There were prior attempts by Rust's compiler team to investigate automatically converting generic type definitions into dyn traits and trait objects, and it actually generated more code, used more memory, and burned more CPU cycles. This is something that you need to be very careful with measuring.

It's not all about dyn traits, the return types, iterators etc will always need per-instance monomorphisation. Of course if your code only ever uses integers then it's not a problem, it will monomorphise once and as you say, it's the same code you SHOULD write in C anyway. You can also do it the "C" way by boxing everything, again it will monomorphise just once for pointers. That would be even more efficient than dyn traits, because box pointers are raw pointers while dyn traits use fat pointers.

Of course you also need to consider the case for using Rust in the first place on such a ultra low end, ultra cheap microcontroller. If you are writing code for a TV remote, the safety guarantee requirements are exactly zilch, so there is no actual problem with using plain C if it means less workarounds.

[jacob]

To my (limited) knowledge, Rust has the same ABI as C. In this sense, any Rust code introduced into the kernel, should be portable going forward. Rust is an awesome addition to Linux, one that will transform the entire kernel into a more stable, less buggy, more easily testable/performant piece of code.

Rust is like C++ in that regard. It has its own ABI, but can use the C one when needed.