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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 14E4EC43214 for ; Thu, 26 Aug 2021 18:09:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F0D1A60ED3 for ; Thu, 26 Aug 2021 18:09:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243278AbhHZSJu (ORCPT ); Thu, 26 Aug 2021 14:09:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54508 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243259AbhHZSJs (ORCPT ); Thu, 26 Aug 2021 14:09:48 -0400 Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C094C0613C1 for ; Thu, 26 Aug 2021 11:09:01 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id p15so6728713ljn.3 for ; Thu, 26 Aug 2021 11:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sdk8oq9F9d0RnEa7dfHJHGoL0Z5yyU5Y/fEoZ2o9vEs=; b=oFaf1OcBV6BFwvxWMUemdMKSedBA9yLmq2eCG+ad7OwqaD0DiP62OtgHqbIW+StaVP VddT4aGeBBKdcB+6YQiOVT6GNI7ARrjOkBRKmAU2/fCGYmPqB7KBFkirU1o2quzVOqyD dFYM2M7vmIQanPHyRne5WCpOOnba+vaLR25yr2+x1D2q0IbH1jUFCvTT7LGPdrSqehFb KtY+S9RhbII4vMAKnm/Gb63bmnkY8PaCXXIrrHLFrr0+f/JzC/phq3kYrUtwJL/wngqf oRGQAzTOeaUoQJtayoEQ4qAuMwS+HkFfmja7WeOMv0YCv2M+JwqoUVHe62GEZLzsyhHd hJfQ== 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=sdk8oq9F9d0RnEa7dfHJHGoL0Z5yyU5Y/fEoZ2o9vEs=; b=oXo6Lo1BfSROAEI2jxUfJQqckVXot/cOA9/EPaWemnRnZ8o0PIHP5XtotdDxiqVRoc orMdSPkmqa4goQGTbEBP0iAKQ7RBljmxyVFSH6tPYg4gxHxDa1bfHEbv3T1StC/4yuuQ f0HZVo5IM/zP988p2C9lHkLKgq50AqVgAeaZVCZFHKWzVCYZmAlBcqUN169o464FBlwc hhx5GiBbmPBGjAbUZjZ+OHYGnwIJZvoHmV6N5QNbBjFeOquOQP1jkqpP6Qdi1Ak0Rrl3 /ZTkXLEaKYaMCzi+UarnHi8EJcyONxKMN19NRkRmhodYTDNIG6iypf+Tsx9ja5Bu6VTs OJSQ== X-Gm-Message-State: AOAM532VruD6B9W9lKofsgBAptYQkrzAA4T5k3KrXy1ZbFBUAyTb0FlZ cICQCpDKprXbM4iOGW4eWRVRTJ9e3XZG8ZXh9CEDwQ== X-Google-Smtp-Source: ABdhPJzS/iKs/tjwCArh2Yfh+JVfg8cE0yOVo4BTu9i3Q7phsaRzNSlcZw5F+bAfVa5AUqVC5B4BcEZLW9JJgaQbkq4= X-Received: by 2002:a2e:a788:: with SMTP id c8mr4240939ljf.116.1630001338932; Thu, 26 Aug 2021 11:08:58 -0700 (PDT) MIME-Version: 1.0 References: <20210822075122.864511-1-keescook@chromium.org> <20210822075122.864511-15-keescook@chromium.org> <202108251942.26FC1B8E7@keescook> In-Reply-To: <202108251942.26FC1B8E7@keescook> From: Nick Desaulniers Date: Thu, 26 Aug 2021 11:08:47 -0700 Message-ID: Subject: Re: [PATCH for-next 14/25] lib/string: Move helper functions out of string.c To: Kees Cook Cc: linux-kernel@vger.kernel.org, Andy Shevchenko , Rasmus Villemoes , Daniel Micay , Francis Laniel , Bart Van Assche , David Gow , linux-mm@kvack.org, clang-built-linux@googlegroups.com, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 25, 2021 at 7:47 PM Kees Cook wrote: > > On Wed, Aug 25, 2021 at 02:48:30PM -0700, Nick Desaulniers wrote: > > are memset16, memset32, and memset64 worth moving as well? Also, > > memscan(), check_bytes(), memchr_inv()? > > All of these are implementations, so they should stay put. All of the functions being moved here are definitions. So what's the difference between moving the definitions of functions like strrreplace, fortify_panic, etc., but not memscan(), check_bytes(), memchr_inv(), etc? ie. it looks to me like a few more functions can or should be moved as well. If the point of this patch is to "move all the helper functions into string_helpers.c so that they gain the fortification coverage they had been missing" then it looks like you missed a few. I don't think the compiler will recognize those non-libc identifiers for any fortification related transforms (unlike memcpy and friends which are left in place). -- Thanks, ~Nick Desaulniers 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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 BCE13C432BE for ; Thu, 26 Aug 2021 18:09:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3AB6860F4C for ; Thu, 26 Aug 2021 18:09:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3AB6860F4C Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id CE5FA8D0002; Thu, 26 Aug 2021 14:09:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C95D68D0001; Thu, 26 Aug 2021 14:09:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B84318D0002; Thu, 26 Aug 2021 14:09:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0212.hostedemail.com [216.40.44.212]) by kanga.kvack.org (Postfix) with ESMTP id 9BD458D0001 for ; Thu, 26 Aug 2021 14:09:01 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 4BDC08249980 for ; Thu, 26 Aug 2021 18:09:01 +0000 (UTC) X-FDA: 78518018082.11.CD81A41 Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) by imf19.hostedemail.com (Postfix) with ESMTP id 1124DB0000B0 for ; Thu, 26 Aug 2021 18:09:00 +0000 (UTC) Received: by mail-lj1-f179.google.com with SMTP id w4so6661628ljh.13 for ; Thu, 26 Aug 2021 11:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sdk8oq9F9d0RnEa7dfHJHGoL0Z5yyU5Y/fEoZ2o9vEs=; b=oFaf1OcBV6BFwvxWMUemdMKSedBA9yLmq2eCG+ad7OwqaD0DiP62OtgHqbIW+StaVP VddT4aGeBBKdcB+6YQiOVT6GNI7ARrjOkBRKmAU2/fCGYmPqB7KBFkirU1o2quzVOqyD dFYM2M7vmIQanPHyRne5WCpOOnba+vaLR25yr2+x1D2q0IbH1jUFCvTT7LGPdrSqehFb KtY+S9RhbII4vMAKnm/Gb63bmnkY8PaCXXIrrHLFrr0+f/JzC/phq3kYrUtwJL/wngqf oRGQAzTOeaUoQJtayoEQ4qAuMwS+HkFfmja7WeOMv0YCv2M+JwqoUVHe62GEZLzsyhHd hJfQ== 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=sdk8oq9F9d0RnEa7dfHJHGoL0Z5yyU5Y/fEoZ2o9vEs=; b=QdfM2DJHLiwvE9MUqIiR4SFC5IjHYM/UjAhNqRwvL9xa5JJy0nCmpzA9UDXeIHQYQY sbx6FqV4NZ+Yk2Ygwq0PnfEjyBdNlbD1HscYLTyIJz/K5zbDPS8TMDw3srTrpScT3m1e e6irTBJU6XFUj7zZLuDBnQeHWEwUW8sBsDS12vVI/kkOXyHlaZCpWzI8A5y4bw7BuCVB 7s5WmoAguvex1fn1cE8pIRZuSZzLxO48/Blp26G8WMauD1/gFXgVMwFskblt/DSZjc+3 QoGS0fMB6fob1mnvVmMIQZjYmI7XHWQHWMRrzb7l6ZRRmER5gKIdSGEDXOs4hH8/JNPl /QEA== X-Gm-Message-State: AOAM531pviJkspG/BwkcxpAd/SsiiELgHWZ1LsO6iwdkkeL+YSw2MMPw BYR89mleQGFdy1h20NOy+tyrjRJrODEK38OuV3zrdw== X-Google-Smtp-Source: ABdhPJzS/iKs/tjwCArh2Yfh+JVfg8cE0yOVo4BTu9i3Q7phsaRzNSlcZw5F+bAfVa5AUqVC5B4BcEZLW9JJgaQbkq4= X-Received: by 2002:a2e:a788:: with SMTP id c8mr4240939ljf.116.1630001338932; Thu, 26 Aug 2021 11:08:58 -0700 (PDT) MIME-Version: 1.0 References: <20210822075122.864511-1-keescook@chromium.org> <20210822075122.864511-15-keescook@chromium.org> <202108251942.26FC1B8E7@keescook> In-Reply-To: <202108251942.26FC1B8E7@keescook> From: Nick Desaulniers Date: Thu, 26 Aug 2021 11:08:47 -0700 Message-ID: Subject: Re: [PATCH for-next 14/25] lib/string: Move helper functions out of string.c To: Kees Cook Cc: linux-kernel@vger.kernel.org, Andy Shevchenko , Rasmus Villemoes , Daniel Micay , Francis Laniel , Bart Van Assche , David Gow , linux-mm@kvack.org, clang-built-linux@googlegroups.com, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=oFaf1OcB; spf=pass (imf19.hostedemail.com: domain of ndesaulniers@google.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=ndesaulniers@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 1124DB0000B0 X-Stat-Signature: ra77j5cengt44xs98i7fxit16i1xf879 X-HE-Tag: 1630001340-243729 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Aug 25, 2021 at 7:47 PM Kees Cook wrote: > > On Wed, Aug 25, 2021 at 02:48:30PM -0700, Nick Desaulniers wrote: > > are memset16, memset32, and memset64 worth moving as well? Also, > > memscan(), check_bytes(), memchr_inv()? > > All of these are implementations, so they should stay put. All of the functions being moved here are definitions. So what's the difference between moving the definitions of functions like strrreplace, fortify_panic, etc., but not memscan(), check_bytes(), memchr_inv(), etc? ie. it looks to me like a few more functions can or should be moved as well. If the point of this patch is to "move all the helper functions into string_helpers.c so that they gain the fortification coverage they had been missing" then it looks like you missed a few. I don't think the compiler will recognize those non-libc identifiers for any fortification related transforms (unlike memcpy and friends which are left in place). -- Thanks, ~Nick Desaulniers