On Wed, Jan 24, 2024 at 11:04:14AM -0500, James Bottomley wrote: > 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. Yes, but it's a problem we already have, and sure introducing a package manager might lead to lead to more duplication and bloat if we don't bother to care about this issue. But introducing a package manager also means we'll have standard tooling for checking for duplicated dependencies, so if we make sure to use the tooling and make it part of the review process we should be fine. It wouldn't be hard to make checkpatch check for this on changes to Cargo.lock. > > > 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 I think the argument is more just "why exactly is the kernel special here?". > 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. Are you arguing that typical kernel code is more secure than typical Rust code? > > 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. No, and being special snowflakes isn't helpful. They don't in general have to be crafted for our environment, and we're slowly working to reduce the differences between the kernel environment and userspace (gfp flags). We can and should have our own review process when pulling in new dependencies, but we shouldn't otherwise be making it difficult to use crates.io dependencies just for the sake of it. > 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. Comitting the cargo lockfile pins your dependencies to an exact git revision, and then updating to new versions of dependencies requires a new commit in our repository. We have the means to do our own review here.
