On Wed, 2024-01-24 at 15:43 +0000, Matthew Wilcox wrote: > On Wed, Jan 24, 2024 at 09:26:34AM -0500, James Bottomley wrote: > > On Tue, 2024-01-23 at 19:09 +0000, Matthew Wilcox wrote: > > > > - The use of outside library code: Historically, C code was > > > > either written for userspace or the kernel, and not both. But > > > > that's not particularly true in Rust land (and getting to be > > > > less true even in C land); should we consider some sort of > > > > structure or (cough) package management? Is it time to move > > > > beyond ye olde cut- and-paste? > > > > > > Rust has a package manager. I don't think we need kCargo. I'm > > > not deep enough in the weeds on this to make sensible > > > suggestions, but if a package (eg a crypto suite or compression > > > library) doesn't depend on anything ridiculous then what's the > > > harm in just pulling it in? > > > > The problem with this is that it leads to combinatoric explosions > > and multiple copies of everything[1]. > > OK, but why do we care? We still have buffer_heads in the kernel > (v1.0 of the block layer abstraction) while also have bios, iomap and > numerous NIH in various filesystems. I don't even know if it's going > to be quantitatively worse. Multiple copies lead to kernel bloat and problems for embedded systems as well as security problems. > > For crypto in particular the last thing you want to do is pull some > > random encryption routine off the internet, particularly if the > > kernel already supplies it because it's usually not properly > > optimized for your CPU and it makes it a nightmare to deduce the > > security properties of the system. > > That seems like a strawman. Why is it _so_ much worse to have your > kernel compromised than your web browser, your email client, or your > corporate authentication provider? If I follow that argument to the logical conclusion you're saying security of our crypto functions doesn't matter that much because others also get it wrong? I'd say that might be slightly controversial ... To illustrate the problem with cryptography in rust: just because it's rust safe doesn't mean its correct or bug free. Crypto functions are the most difficult to get right (algorithmically, regardless of memory safety). Look at this Medium report on the top ten bugs in blockchain: https://medium.com/rektoff/top-10-vulnerabilities-in-substrate-based-blockchains-using-rust-d454279521ff Number 1 is a rust crypto vulnerability due to insecure randomness in a random number generating function (note it was rust safe code just not properly checked for algorithmic issues by a cryptographer). The reason for using the kernel functions is that they are vetted by cryptographers and crafted for our environment. > Why would we allow code in that pulls in random shit from the > internet instead of the vetted stuff on crates.io? The pallet problem in the blockchain bug came from crates.io. > > However, there's nothing wrong with a vetted approach to this: keep > > a list of stuff rust needs, make sure it's properly plumbed in to > > the kernel routines (which likely necessitates package changes) and > > keep it somewhere everyone can use. > > ... like crates.io. Why are we better at this than they are? The volume is way smaller so scrutiny can be way greater and they have to be crafted for our environment anyway. > > [1] just to support this point, I maintain a build of element- > > desktop that relies on node (which uses the same versioned package > > management style rust does). It pulls in 2115 packages of which > > 417 are version duplicates (same package but different version > > numbers). > > I'd suggest that node.js has a very different approach from > crates.io. > I don't see there being a rust left-pad. Really? crates.io currently has 135,010 packages which can all be uploaded and changed instantly by their respective owners. Security vetting is mostly supposed to be done by the uploaders (it can't be done by the repo since there are so many packages) ... is this starting to sound familiar? because it's the same security policy all the web package repositories have. Sure they've got safeties in place for left-pad essential package removals problems, but they could still get a log4j issue. James
