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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 9A4CBC433B4 for ; Thu, 15 Apr 2021 12:40:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 73A4E61184 for ; Thu, 15 Apr 2021 12:40:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232854AbhDOMkf (ORCPT ); Thu, 15 Apr 2021 08:40:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42780 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230202AbhDOMke (ORCPT ); Thu, 15 Apr 2021 08:40:34 -0400 Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7DEAFC061574; Thu, 15 Apr 2021 05:40:10 -0700 (PDT) Received: by mail-yb1-xb29.google.com with SMTP id v3so23612003ybi.1; Thu, 15 Apr 2021 05:40:10 -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=HNWPrpdPoD+pXH9p1hvOGpr8+bIHmvjS+4XG2ldZ0Sc=; b=PHuF3KrGqNBmqAhI7J+l69fge3/RxdwOfMm73BbiapXnaS25fJER94tzGL0volq6nJ uVBdFT87qfAFF6Mk9bToFO5RRpRY90hP8G2jKu6QeUr2Kt50f58LPPu85yVORSpWVKYQ hd5D4KclIVt0np3ZmNZEmb7ZR6eE10A3wTDxilcHC6fMWxbsbaw7jKcI3tcqLt7m/ckn QCJhcjmQCzFCbiJw4xc7e+DIitZozXwIlcRRUisdbJZcbZMG2ORchleytjjRVcsDlsJG RID3l6K3+u7ePY/dvZTSnJKqVAerSfoEiYE3lytwF4HiVmXSsLtV4suJai+7Q/Hp3CEL ia6g== 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=HNWPrpdPoD+pXH9p1hvOGpr8+bIHmvjS+4XG2ldZ0Sc=; b=FP4tmY1b/bHhUbmHF7dd4X43sr9hNfsRYQO1uy8Yq1AprYKopqsC987jJriFyLqfNG MMkKQVYnihXyHWoGq+B85YXA6uFqSS6s7OaaS2msKFe2PUQuOs6trzHHj4K+tl2NvYlR etI4sED1MUGhOaE5o28W4vFggPAjErh0y/rVjy0LBcKjPtZEo7TMzY61NnZ7yXb1eT/0 qJaj79/l8yi8NTGBZTjKuYXB5IaEKROy3BnF/nTq6yJ/UWVNHwPhDkNJ/tDoYSpNHqpb W8umJxPNsHNpndXk7nKQoVdLn+q+wgNFpp1YwCyYnW8fH+Yzl5XsRIi0PL3ckPXVGdl9 Cm/w== X-Gm-Message-State: AOAM533uA6CJ/ssg3J/DvhRgh9cFZhpCGyh7DUk44GsGIlczf7cJZuvZ 29H+uf2gHd2dGWYERI+mwpCnyyL373RI9FzNrXugrek1iyc= X-Google-Smtp-Source: ABdhPJxxvwHaN8MXNkZ2cWP+VxR/Oi6OrV25u/8c4Sk71cAVeHSDikukkFzc+2IPtDy3JiqOzh/Ywn1UnHBoDwcKALw= X-Received: by 2002:a25:cfc2:: with SMTP id f185mr4317197ybg.26.1618490409882; Thu, 15 Apr 2021 05:40:09 -0700 (PDT) MIME-Version: 1.0 References: <20210414184604.23473-1-ojeda@kernel.org> <202104141820.7DDE15A30@keescook> In-Reply-To: <202104141820.7DDE15A30@keescook> From: Miguel Ojeda Date: Thu, 15 Apr 2021 14:39:58 +0200 Message-ID: Subject: Re: [PATCH 00/13] [RFC] Rust support To: Kees Cook 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: rust-for-linux@vger.kernel.org On Thu, Apr 15, 2021 at 3:38 AM Kees Cook wrote: > > Before anything else: yay! I'm really glad to see this RFC officially > hit LKML. :) Thanks! :) > 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". +1 Agreed, we need to get this right (and ideally make both the C and Rust sides agree...). Cheers, Miguel