Content-Length: 13949 | pFad | http://lwn.net/Articles/830182/

Supporting Linux kernel development in Rust [LWN.net]
|
|
Subscribe / Log in / New account

Supporting Linux kernel development in Rust

Supporting Linux kernel development in Rust

Posted Aug 31, 2020 22:19 UTC (Mon) by nickodell (subscriber, #125165)
In reply to: Supporting Linux kernel development in Rust by adobriyan
Parent article: Supporting Linux kernel development in Rust

I assume that Rust has an equivalent of the C++ reinterpret_cast.


to post comments

Supporting Linux kernel development in Rust

Posted Aug 31, 2020 22:23 UTC (Mon) by josh (subscriber, #17465) [Link]

It does. We also have work in progress to provide a safe way to do that, via the "safe transmute" project.

Supporting Linux kernel development in Rust

Posted Aug 31, 2020 22:25 UTC (Mon) by adobriyan (subscriber, #30858) [Link]

Cast covers implementation part, what about interface? I've posted what C++ would do.

Supporting Linux kernel development in Rust

Posted Aug 31, 2020 22:47 UTC (Mon) by notriddle (subscriber, #130608) [Link]

The Rust version of reinterpret_cast is called transmute. https://doc.rust-lang.org/stable/std/mem/fn.transmute.html

But copy_from_user itself looks closer to ptr::copy. https://doc.rust-lang.org/stable/std/ptr/fn.copy.html

Both of these functions are unsafe, as any form of copy_from_user must be, since there's no way to be sure that the contents of userspace memory are valid for whatever data structure you're transmuting them into. You would need to ensure that the data structure in question can accept any arbitrary byte sequence, which is what "safe transmute" proposals are supposed to do.

Supporting Linux kernel development in Rust

Posted Aug 31, 2020 22:55 UTC (Mon) by nybble41 (subscriber, #55106) [Link]

> I assume that Rust has an equivalent of the C++ reinterpret_cast.

It exists (you can cast raw pointers from one type to another and dereference them within unsafe blocks) but, like reinterpret_cast, you need to be very careful about how you use it. This is one area where it is probably easier to accidentally trigger undefined behavior in unsafe Rust code than in C, since Rust places more constraints on pointers/references than C does. At a minimum the target object would need to have a repr(C) type to ensure a consistent ABI, and the Copy trait as evidence that the content can be safely duplicated with a straightforward byte copy. The operation itself would also need to be marked as "unsafe" since there is no way that overwriting a Rust object (even one which is Copy and repr(C)) with arbitrary data from a buffer can be guaranteed to preserve whatever invariants might be expected by the object's implementation. With all that said, however, the std::ptr::read_unaligned function[1] is fairly close to a typed copy_from_user—without, obviously, the extra checking and error recovery that comes with accessing user memory from kernel mode.

[1] https://doc.rust-lang.org/std/ptr/fn.read_unaligned.html


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://lwn.net/Articles/830182/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy