From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2F85C43461 for ; Thu, 15 Apr 2021 01:39:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A53DD611B0 for ; Thu, 15 Apr 2021 01:39:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229641AbhDOBjX (ORCPT ); Wed, 14 Apr 2021 21:39:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39108 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229701AbhDOBjW (ORCPT ); Wed, 14 Apr 2021 21:39:22 -0400 Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4019AC06175F for ; Wed, 14 Apr 2021 18:38:59 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id h20so11165265plr.4 for ; Wed, 14 Apr 2021 18:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=bX6POsGmP4rs/rcLgPiRiQi4oaHEHZ6HqQN4nR2RIow=; b=QsNXz83U6yLc/9B6Ylh4qLBbM+mPoSDKwIE36jf24RToMnYA6W/NTMnk4CSkDaUDu1 fchQlGZSES0NTLp9wu5LBdzEchrvbRvU9yKyeV2C6p6gEALe0GLxpC0aSOGEOyTJgPOr +t6OqHmIWMjLTfFGARripHpVxPqOF70SbTut4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=bX6POsGmP4rs/rcLgPiRiQi4oaHEHZ6HqQN4nR2RIow=; b=JeabncyTHBIwpK2jqktt4vjnlpGrAWGWfbfFp4IgxuuGMWIdI8+2v5DMLGv5hDDHVd hNa7U0FPqag79SvFS1pAX97/GFwH7pb3yvpkzgbsancW/bbQ2bdBw6Pp0qoEWDwFto5E S7/1e8Ge/yD0LTvNkXxxyVTq0ExD77VTfmud+7OuAJFYhY61bmo4gB2uAtZGh2AzLAMB LZKqPeVkx1P0lChY890+HcJR98k7z7gT8I45IEbS7It49KW2wln2y14xMf5MrK5PZnn4 3ZU6oKKLtqMdMg5vxXGGEYLtK5akL/XHDTKelL8ISk1aF/z6vjrzKKxoIqDy9an/9EWN 79kg== X-Gm-Message-State: AOAM530dqSOh9gLCbTJlyMPmRMQ4m9H8S1BGZMLcJF9BhAdcJIku7SHN TNdSJD7QzYWSryydmY10OWOl5FV8F6mIrg== X-Google-Smtp-Source: ABdhPJwd5bR54OWgpgBTnm6xH0X8VpmlK7vpSuR0Oz+hSNYVch3S//NX4ZCB3JzVG85QOgXpbg0aOw== X-Received: by 2002:a17:902:e851:b029:eb:1fd0:fa8e with SMTP id t17-20020a170902e851b02900eb1fd0fa8emr1262234plg.38.1618450738773; Wed, 14 Apr 2021 18:38:58 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id o9sm516255pfh.217.2021.04.14.18.38.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Apr 2021 18:38:58 -0700 (PDT) Date: Wed, 14 Apr 2021 18:38:56 -0700 From: Kees Cook To: Miguel Ojeda Cc: Linus Torvalds , Miguel Ojeda , Greg Kroah-Hartman , rust-for-linux@vger.kernel.org, Linux Kbuild mailing list , "open list:DOCUMENTATION" , Linux Kernel Mailing List Subject: Re: [PATCH 00/13] [RFC] Rust support Message-ID: <202104141820.7DDE15A30@keescook> References: <20210414184604.23473-1-ojeda@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: rust-for-linux@vger.kernel.org Before anything else: yay! I'm really glad to see this RFC officially hit LKML. :) On Wed, Apr 14, 2021 at 10:20:51PM +0200, Miguel Ojeda wrote: > - On floating-point, 128-bit, etc.: the main issue is that the > `core` library is a single big blob at the moment. I have already > mentioned this to some Rust team folks. We will need a way to "cut" > some things out, for instance with the "feature flags" they already > have for other crates (or they can split `core` in to several, like > `alloc` is for similar reasons). Or we could do it on our side > somehow, but I prefer to avoid that (we cannot easily customize `core` > like we can with `alloc`, because it is tied to the compiler too > tightly). Besides just FP, 128-bit, etc, I remain concerned about just basic math operations. C has no way to describe the intent of integer overflow, so the kernel was left with the only "predictable" result: wrap around. Unfortunately, this is wrong in most cases, and we're left with entire classes of vulnerability related to such overflows. When originally learning Rust I was disappointed to see that (by default) Rust similarly ignores the overflow problem, but I'm glad to see the very intentional choices in the Rust-in-Linux design to deal with it directly. I think the default behavior should be saturate-with-WARN (this will match the ultimate goals of the UBSAN overflow support[1][2] in the C portions of the kernel). Rust code wanting wrapping/checking can expressly use those. The list of exploitable overflows is loooong, and this will remain a weakness in Rust unless we get it right from the start. What's not clear to me is if it's better to say "math with undeclared overflow expectation" will saturate" or to say "all math must declare its overflow expectation". -Kees [1] https://github.com/KSPP/linux/issues/26 [2] https://github.com/KSPP/linux/issues/27 -- Kees Cook