Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp2999751pxb; Mon, 19 Apr 2021 20:50:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwG+KKweW8IMNUiNZvLSgGx2GIbahJrVTSOxanPzpkexhZVy0M6X1sMixd52Mp131o9I+rl X-Received: by 2002:a17:90a:3e43:: with SMTP id t3mr2760952pjm.216.1618890625649; Mon, 19 Apr 2021 20:50:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618890625; cv=none; d=google.com; s=arc-20160816; b=Y98QL4XwWZLhUYT39tyUeHDEBQPjg8EXKxuV79NyrL+LsE7U97zQ5ue5Ghqh0Ulk8P hObUYfXa6mRcDAHZaD7gnpn1vZunYeVCFFnfp/EKXdneQCKHY32nw4aoHtfufOcfik80 l7wPVA86jMCGF5xAskKFE5AstHzni3P74AxnJGZKXt26/GteQIbS4gqfQmMCVYOQjpic TFtQMqOZm5piD/yull+Wax6OO08pUGjnLGK9YIkHnou/8AAxHXyRvPhaBuhzanCaCt+t gpB8LtCFpjto/X2XeZ+jRySLqNi8WBkr1V8h6d11Oo4c2wWihXr16CyW18X28r6R7Qek VM1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=uuBs04sE65XGNA9zHl6RK1FHkGOq/aMaSOPOqMP+7Nw=; b=Kpp/gTTa2/+9vLMfz0NYDAYtU400y61ZIyy540BYPUwdk+aBPmoS9zIsV6BEDbb6p4 xov8n8KBD6278mSK6sVvMt2bdTKg9HtCaYd3PyzDsAUab3i7qv5jpetYJSSeGKGLJoq2 CLFqIDuuy/KyZVIx7AyHYoW5cdmxyFODs0AINq9kSHSsAGejyz247gXRBgzZzjmD+PvD MEYK/fw97lHtR+S13OKiy2nIyWb4P25chW+TfX1mrXr8wpHe0PpoCKXjxZ2L6t6UrRb1 zUD+fw586B8s9OEz2U4XKNm46dyrh/WWhDQHdVEEr/HAZd5KDNXf2Asm5fhUiHcz86cR rDqg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q29si20109870pgb.153.2021.04.19.20.50.12; Mon, 19 Apr 2021 20:50:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229968AbhDTDtB (ORCPT + 99 others); Mon, 19 Apr 2021 23:49:01 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:51894 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229579AbhDTDtA (ORCPT ); Mon, 19 Apr 2021 23:49:00 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 13K3lniw030310; Tue, 20 Apr 2021 05:47:49 +0200 Date: Tue, 20 Apr 2021 05:47:49 +0200 From: Willy Tarreau To: Nick Desaulniers Cc: Wedson Almeida Filho , Peter Zijlstra , Miguel Ojeda , Linus Torvalds , Greg Kroah-Hartman , rust-for-linux , Linux Kbuild mailing list , Linux Doc Mailing List , linux-kernel , Dmitry Vyukov , Miguel Ojeda Subject: Re: [PATCH 00/13] [RFC] Rust support Message-ID: <20210420034749.GA28662@1wt.eu> References: <20210414184604.23473-1-ojeda@kernel.org> <20210416161444.GA10484@1wt.eu> <20210416173717.GA10846@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Nick, On Mon, Apr 19, 2021 at 05:24:33PM -0700, Nick Desaulniers wrote: > I don't think the introduction of Rust made Firefox _more_ insecure. > https://wiki.mozilla.org/Oxidation#Within_Firefox Browsers are human interfaces and do not fundamentally require low level access to memory/hardware/whatever. They can be written in about any language, only the resource usage and performance will make a difference. As such, some were even written in Java or JS for example. Operating systems, and particularly drivers *do* require low-level accesses, and stuff that can hardly be abstracted or understood by a compiler. You may have to perform two 16-bit reads/writes on a 32-bit MMIO address to perform an operation and the compiler does not have to know it, just to obey. > Really, a key point is that a lot of common mistakes in C are compile > time errors in Rust. I know no "true" kernel dev would make such > mistakes in C, Everyone makes mistakes, the level of attention varies over time and the focus often changes when dealing with build errors. How many time some of us facing a bug remembered having changed the code very late after a build error, and being less careful from this point when the goal changed from "let's do it right" to "let's get this to build" ? > but is there nothing we can do to help our peers > writing drivers? The point is to transfer cost from runtime to > compile time to avoid costs at runtime; like all of the memory safety > bugs which are costing our industry. And do we have stats on the number of logical bugs, some of which are caused by developers trying to work around compilers' stubbornness ? For me, personally speaking, they have *increased* over time, usually trying to avoid some annoying modern gcc warnings, resulting in integer casts being placed close to string formats, or returns being placed in switch/case to avoid the fall-through warning, etc. Thus I'm worried that a non-negligible part of the 70% of bugs caused by memory safety issues could be replaced with logic bugs to get to the point where the rust compiler finally accepts to compile the code. It makes me think about researchers trying to reduce the causes of certain deaths and claiming to "save lives" while in the end the people they "save" will simply die from something else. And I'm not particularly trying to blindly defend C here. I'm complaining every single day about some of its shortcomings like the vast amount of UB, stupid type promotion, counter-intuitive operators precedence when combining bit-ops with arithmetic, limited size of enums, lack of rotate operator, strict aliasing, or the recourse to asm() statements every 10 lines to do stuff that can hardly be expressed in a way understandable by a compiler. I'm just seeing that a lot of the griefs I'm having against C come from the compiler trying to be too smart or too stubborn, so giving even more of the handle to a compiler doesn't appeal me at all. In addition, we all know how painful it is to work around compiler bugs by writing complex code that carefully avoids certain constructs. I'm wondering if we'll still have that luxury with a stricter compiler, or if the only response will have to be between "let's disable this driver that does not compile" or "please force distros to upgrade their compilers". But we'll see :-/ Regards, Willy