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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <bddea099-4468-4f96-2e06-2b207b608485@usi.ch> Date: Fri, 18 Aug 2023 00:27:33 +0200 From: Davide Rovelli <roveld@....ch> To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Michele Dalle Rive <dallerivemichele@...il.com> Cc: Andrew Lunn <andrew@...n.ch>, Greg KH <gregkh@...uxfoundation.org>, Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, Wedson Almeida Filho <wedsonaf@...il.com>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, Björn Roy Baron <bjorn3_gh@...tonmail.com>, Benno Lossin <benno.lossin@...ton.me>, Alice Ryhl <aliceryhl@...gle.com>, Davide Rovelli <davide.rovelli@....ch>, rust-for-linux@...r.kernel.org, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, patches@...ts.linux.dev Subject: Re: [RFC PATCH 0/7] Rust Socket abstractions On 8/17/23 19:14, Miguel Ojeda wrote: > On Thu, Aug 17, 2023 at 4:53 PM Michele Dalle Rive > <dallerivemichele@...il.com> wrote: >> >> The idea behind this patch is that, as of now, Rust is not a viable option for >> any OOT module that requires even the highest-level network support. >> >> I am wondering whether the `net` subsystem is interested in reviewing, giving >> feedback and eventually accepting code that is currently OOT-only. > > It is unlikely kernel maintainers in general accept code intended for > out-of-tree modules only. > > To be clear, Rust for Linux's focus has never been out-of-tree > modules. In fact, the whole effort since the beginning was about > adding support for Rust in-tree, unlike other projects that e.g. > linked `rustc`-built object files into an out-of-tree kernel module. > > We do support out-of-tree modules, and have a sample of that, but that > is just only to the degree that the kernel supports out-of-tree > modules in general. > > The abstractions that have been upstreamed so far are those that have > (or should soon have) a user in-tree. Sometimes we have had to bend a > bit the rules in order to split the dependency chain or make things > easier, but abstractions (in general) cannot be upstreamed that do not > have at least an expected and public user that is going upstream too. > Here, by user, we generally mean an actual driver or useful component > (rather than a sample). > > If I understood correctly from Zulip, you cannot (right now) show your > use case because it is confidential and therefore you cannot upstream > it, so we will need another user (and, of course, that is a necessary > but not sufficient condition for the code to be accepted). Correct. I work with Michele, let me clarify. We are a research lab working on a low-jitter networking prototype implemented as an internal LKM (our last paper: https://www.usenix.org/system/files/atc21-jahnke.pdf). When trying to convert it to Rust, we noticed the lack of socket abstractions which Michele implemented. We then simply thought about sharing the abstractions with the community since they could fit a variety of use-cases - hence the patch. We now understand the necessity of a concrete in-tree user, apologies for not realising this earlier: we are indeed new to patch process as you probably understood. Our prototype might become available in the future but there's no clear path on when, this is our starting point. > Of course, this does not preclude discussing about them or having a > `rust-net` branch or sub-subsystem or similar. That could be quite > useful so develop those users and to experiment. In fact, we are > actively trying to onboard more people (and companies and other > entities) to the Rust overall kernel effort, so please feel free to > join us. We will be more than happy to. In fact, I think the best place for this patch would be in a net branch/subsystem of the Rust for Linux repo. As mentioned in the Zulip chat, it's hard to provide a "full-fledged" patch in Rust at this point as many network building blocks are missing. The result is a number of bindings patches such as this one which do not match maintainers' interests but could be useful for other developers to eventually make a concrete user. It would have helped us significantly when starting this project, I think other researchers/developers share the same view. If anyone is interested, we could add these patches to the mailing list with a low priority tag for feedback. > By the way, I am a bit confused -- the patch seems to add an in-tree > sample, not an out-of-tree one. It is an in-tree sample, I guess Michele meant an "out-of-tree use-case" as in the sample doesn't introduce new core features in the kernel, just showcasing.
Powered by blists - more mailing lists