From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 983D0168 for ; Tue, 6 Jul 2021 14:56:08 +0000 (UTC) Received: by mail-io1-f54.google.com with SMTP id u7so23197153ion.3 for ; Tue, 06 Jul 2021 07:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SpBZsyZTrhZS/FQ+d0iF7gRQqxorFw/R1xGMVIsn5WM=; b=N08vQ63gttAaPAgVp/GLrfqSvbZjSlcfHkempPXkIOAhxQH63Y6shiJYTe43q6i042 QPPE4zS3NC6pyhAKqdwGgu1Fy1WgfTjH/GToneSh2jk+39OxjQZ7wQMvAAHAnI84SXES v1fQTKggZKTU8Z71OoEifwhrdtN9bM5cGAVo4K7Tkytk1JzcfEj2kPCcexO+ZBzV75Fv raTSzHYZ0yLXyzak1mCeotoy0Btz4KFM+LPN3kJ5V2FvGp1ZO3i0+6afepiMuKoUyJBl QeTcLLX3eaVzxNmr4YzVyhSsatPQXbqih6KYa6gGciFpKPQR2YWx+qVv4uDQNwbBHrgV IWKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SpBZsyZTrhZS/FQ+d0iF7gRQqxorFw/R1xGMVIsn5WM=; b=qWLWZrV3VPnrGuA1cm/KUkoTLHPjrdfw8bdixP/vLc+wTnfQw/fC1ODwf1+A5KYBrM arijNptdSnZ35qRdnPVfejjABPCW+HlORUev0A4hyIe2/L/bk7db/Juq+80w5vbI81XB 79t3PTBo/CsRjtmhavy4RuqAqkhIE8P3z9bcbx/7h8KR8XJp7F/3bb8xz2uYqSGD8IGz bKa2DOXG60kdYPau3V+pSlDB6qLYIILMlVNcx+QM7IsdEWzcpkk7ZBJvNsBhwqFHl3ao iA7+5N2Oyi/YATdqHmViKmADIITN/cfVMES5NfgueTx82AHa8NG/jVqJC2O/01lXPtGr tZmQ== X-Gm-Message-State: AOAM533UayAismu+/cb52ylRID2zxP+MFaWB0ppExRwJCoWyFiFGHxmB Pw/xyQu30Y8hE6bz6ZnY5vxYNaPe5Ev0A49E254= X-Google-Smtp-Source: ABdhPJyixrbAYLeX1cyHCHi4UNzKMqWc+RvVIQHZtTwRwFCgUATZduFe4DsUqDyAl8+ZXGDwqAVmYTcJxQ6tXS02dpo= X-Received: by 2002:a05:6602:2c85:: with SMTP id i5mr1139496iow.91.1625583367822; Tue, 06 Jul 2021 07:56:07 -0700 (PDT) Precedence: bulk X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <19e0f737a3e58ed32758fb4758393c197437e8de.camel@HansenPartnership.com> In-Reply-To: <19e0f737a3e58ed32758fb4758393c197437e8de.camel@HansenPartnership.com> From: Miguel Ojeda Date: Tue, 6 Jul 2021 16:55:56 +0200 Message-ID: Subject: Re: [TECH TOPIC] Rust for Linux To: James Bottomley Cc: Leon Romanovsky , Linus Walleij , ksummit@lists.linux.dev Content-Type: text/plain; charset="UTF-8" On Tue, Jul 6, 2021 at 12:20 PM James Bottomley wrote: > > The main advantage is supposed to be "memory safety": > > https://en.wikipedia.org/wiki/Memory_safety Yes, although please note it covers other things, like data races. In general, Rust prevents the kind of thing that is UB in C, which means it also covers you from the usual surprises that optimizers may give you. > But that's tempered by the fact that all non-rust code is deemed unsafe > and it's hard to write drivers without calling into the core, so > there's a lot of unsafe stuff going on even if you write your driver in > rust. Yes, but bugs on the C side are still bugs, and they need to be fixed regardless of Rust. That is to say: the fact that the C side has bugs does not mean Rust is pointless in the kernel. The value is to write drivers with a safe-as-possible API. By doing that, we avoid extra bugs (but, of course, bugs on the unsafe Rust code or in the C side remain can still happen). > The other thing that makes comparison with C hard is the fact that > compilers and fuzzers are pretty good at detecting memory problems in > the existing code, so it's unclear what memory safety ab initio > actually buys for the kernel. Compilers definitely do not detect all memory safety issues -- not even close. They cannot anyway, in the general case. Not even in C++ with `std::unique_ptr`, `std::vector`, etc. Rust can do so because it places extra restrictions in the modeling capabilities (in the safe subset only). Runtime detection of UB in C is, of course, possible, but the idea is to have static guarantees vs. runtime-checked ones. There is also runtime detection of UB in Rust for unsafe code with tooling like Miri. plus all the language-independent tooling, of course. > 3. Less review: The lack of kernel programmers understanding rust > hampers reviewing. Since most of our CVE type problems are usually > programming mistakes nowadays, the lack of review could contribute to > an increase in programming fault type bugs which aren't forbidden by > the safer memory model. Yes, this is a fair point. Initially, our plan is to work with subsystem maintainers that do want to start providing a Rust API for their subsystem. Then they can maintain drivers using such API. We definitely do not want to have drivers written for a particular subsystem if nobody is able to review (or even write) the Rust abstractions for that particular subsystem. Cheers, Miguel