lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 22 Oct 2021 14:03:15 -0700 From: "Paul E. McKenney" <paulmck@...nel.org> To: gregkh@...uxfoundation.org, tglx@...utronix.de, clm@...com, corbet@....net Cc: peterz@...radead.org, mingo@...hat.com, will@...nel.org, longman@...hat.com, miguel.ojeda.sandonis@...il.com, wedsonaf@...gle.com, boqun.feng@...il.com, rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-team@...com Subject: "Using Rust for kernel development": Memory model Hello! This email is in response to the Rust memory-model discussion at Maintainers Summit (https://lwn.net/Articles/870555/). My blog series entitled "So You Want to Rust the Linux Kernel?" [1] is now feature complete, and a big "thank you" for all the great feedback that this series received. I have recommendations at "TL;DR: Memory-Model Recommendations for Rusting the Linux Kernel" [2], and this email is therefore TL;DR(TL;DR). Given the Rust-for-Linux's focus on device drivers, the Linux-kernel features requiring special Linux-kernel-memory-model features can be avoided within Rust code. For example, code using RCU, sequence locking, or control dependencies can remain written in C, and higher-level APIs based on that code can be exported to Rust in manner consistent with Rust's current ownership models. This approach reasonably straightforwardly accommodates the more likely short-term choices for the Rust memory model, which would presumably be the C/C++ memory model or some stronger subset thereof, for example, one that excludes consume and relaxed accesses. If the Rust community chooses a less mainstream memory model, the code that makes C-code functionality available to Rust code would need to take up any slack. For example, memory barriers might need to be inserted into this wrapper code. Longer term, I hope that the core Rust community will become interested in supporting modern techniques, and to that end I have suggested some longer-term goals in the TL;DR post. There is already plenty of interest in modern techniques within the greater Rust community, and number of people produced prototype wrappers for various sequence-locking and RCU use cases. I am grateful to all who took on this challenge. However, arriving at good wrappers requires a sufficient understanding of Rust to be combined with sufficient knowledge of the Linux kernel's wide variety of sequence-locking and RCU use cases, and unfortunately this combining seems to be some ways off [3]. It therefore makes sense to defer the need for such wrappers in order to allow time for this diffusion of knowledge to take place. So, in the near term, if a Rust-code project were to request direct access to RCU APIs, I would instead ask them to create higher-level APIs so that the RCU APIs would remain within C code. I am also working to better document the wide range of RCU use cases that are present in the Linux kernel, which I hope will speed up the process of working out what a Rust-language RCU API should look like. Of course, the corresponding choices for sequence locking are in the capable hands of the relevant maintainers, who are CCed. Thoughts? Thanx, Paul [1] https://paulmck.livejournal.com/62436.html [2] https://paulmck.livejournal.com/65341.html [3] This process took four years in the C/C++ standards committees, but perhaps things will go faster with the Rust community.
Powered by blists - more mailing lists