Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp618712pxb; Thu, 19 Aug 2021 07:24:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw39reChbcil2KPCT+uc5lgqpTfILSrQOKA8uT+icZmC/cq/Bel02O4FHCAXwu1tL/g8HCR X-Received: by 2002:a17:906:a14b:: with SMTP id bu11mr16060049ejb.260.1629383073571; Thu, 19 Aug 2021 07:24:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629383073; cv=none; d=google.com; s=arc-20160816; b=mR+YLrM9YoiFkfcZTvBQID+IJowApDwaIRm8Lfo6h7F0WAj0K1tEtMhC78qn4Lgvvq fImZs62dYoRcJgWmk/0orke99+Vc05OO72gbjGLgfziyUl8dQaDgoPIJfiXhLGq/UDKh /I/rKuQw2GWp1O+PVYgzgjRrYz7ADnyKJdMlotL7VKhF+IKQmqXGTnj+cS4X39pdKpu8 xHWUJzpRI37H7ovzpjmh0/wjKGWNcJv0gCewt6RuqVoOGQ4jYwqRUknblpVs80eGNi2R x9NJm88jzKL7piD2SanORKxe8AYvM4Ttk3J4yDsddLgFxAb2reeppcLzT2S+f03Brxwu aRpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=m7+BP1bcT0EhLLn/h4/nBsVXxgUv4mRHVL2f79asbyo=; b=mHejp/GFWzNZRDA54gneebv0JC7s/bQKcE7Dl0hH7WyNta4KutKRq6G9+0d/cQUd3j B4DrUs4lBO9i+67AT08Nsz5k2DTcZmAKEG7rEBWEY66qywLx6Wbzjha8Gi06YJxDMqPl ycN7urVPvPg66pjfnN2fGfmh2Hns5d/aOQa77JKW/xsjEf1excL8b3z4mwBuZcJjG+TZ eCWw1miOFMemKm2TemS3woAdJ0Spjpzs2cC9XphMR+pNRO2tMA46tpsI5sMJp2AKitYw 595E16jZPU1OgDOrnUBOb6ugPM7AtLa4YTXFM5piwM8LFo5PuBwOI0ktZb7jbE51+fpR w5jQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=sJy0lKg4; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g23si3507997ejk.552.2021.08.19.07.24.04; Thu, 19 Aug 2021 07:24:33 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=sJy0lKg4; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240522AbhHSOTq (ORCPT + 99 others); Thu, 19 Aug 2021 10:19:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41172 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240520AbhHSOTo (ORCPT ); Thu, 19 Aug 2021 10:19:44 -0400 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9D5C2C06179A; Thu, 19 Aug 2021 07:19:04 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id x10so9376580wrt.8; Thu, 19 Aug 2021 07:19:04 -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=m7+BP1bcT0EhLLn/h4/nBsVXxgUv4mRHVL2f79asbyo=; b=sJy0lKg4BujeOZG0aEbYvf4mp/tF9x+Df2SvQ9OkbJh504JB91e3TnLbF5pWafsRB9 qTa3Vh1S3B+Uo75DbUR4dUF8Xvo+ggTL8faS9fN8zfe3vaM7d1oVs238noo4X3zgx6Rg hhUmG7sb27ka01VNC8ZeoVKag8AuEpRQFMG9dzCtRywDlYtQOAe1Alza2XyPZv0FS+OY GeSam7wB44VJgkyn0QPFrabVwZM4goVDKFZgPqTwpuV+oswgHlgU+fvDn+xjz7Hm6XQh LJvptuVExrPI2LiHYfX+vGeik2BDciC5ulfQeGtOTspVxHq49dSnoRHeAXPI5UQi+SHB iyTw== 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=m7+BP1bcT0EhLLn/h4/nBsVXxgUv4mRHVL2f79asbyo=; b=hEdXI8v5jYA5yA853lIwH4B/+wZiNMoHuDg0TKlA9xnlKLMcyHWJDb79pyTiYjAcF5 HvsBOCagshJuN4Y+S4KPum3pvOOmThZESYswsLNni4O6b0LmGujYB3eYq4g5avAUs8Pw 1PMSrrL87BrNF9hzp2D52Yx0GrqubAy2FOnmiiQh4KfsqOj62CXOPdN5VBZpDvLZNHdk RQGE9+EqdEjqjnGkadc8Nx7emyo20LpXxjmHncj2FArth/eCMn2hT+q4wMnV7SMaNZTm JkCSKmoLf5Bm++KKSmj22Py1MvIeB3T6o6jLyiB80cUym+o8szev7RYQG0PVXlquR9Mt TIzA== X-Gm-Message-State: AOAM530Lpdnke7M70LG5bLhL5yfkOkeomzFENeG8ppyVPGD3HMoM1ogS OE7qegguGZ5dkvvru3b/yMoqRYqALaDMASS1kFw= X-Received: by 2002:adf:a29c:: with SMTP id s28mr4132793wra.318.1629382743247; Thu, 19 Aug 2021 07:19:03 -0700 (PDT) MIME-Version: 1.0 References: <20210818050841.2226600-1-keescook@chromium.org> In-Reply-To: From: Daniel Micay Date: Thu, 19 Aug 2021 10:18:47 -0400 Message-ID: Subject: Re: [PATCH 0/5] Add __alloc_size() for better bounds checking To: Christoph Hellwig Cc: Kees Cook , kernel list , Andrew Morton , Miguel Ojeda , Nathan Chancellor , Nick Desaulniers , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Dennis Zhou , Tejun Heo , Masahiro Yamada , Michal Marek , clang-built-linux@googlegroups.com, Linux-MM , linux-kbuild , linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org It tells the compiler the function will either return NULL or an allocation of the size specific by the parameter referenced by alloc_size. It could also be used for functions resembling allocation functions which aren't actually allocating. The compiler will use it for optimization so it's extremely important that it's only used correctly. It only really has a use on the top-level API used externally. The compiler uses it for __builtin_object_size which is primarily used by FORTIFY_SOURCE and also internally by -fsanitize=object-size which will be available for the kernel via UBSan to find bugs or as hardening in the trapping mode. There are currently compatibility issues (undefined out-of-bounds accesses) blocking using -fsanitize=object-size beyond fixing those relatively benign issues to allow using it elsewhere. For example, it will know that kmalloc(n) returns either NULL or an allocation of size n. A simple sample program with calloc in userspace: #include #include int main(void) { char *p = calloc(64, 1); if (!p) { return 1; } printf("%zu\n", __builtin_object_size(p, 1)); return 0; } It will also detect an out-of-bounds access via the allocation with -fsanitize=object-size including with a runtime value as the index. It's not as useful as it should be yet because __builtin_object_size must return a compile-time constant. Clang has a new __builtin_dynamic_object_size that's allowed to return a value that's not a compile-time constant so it can work for kmalloc(n) where n is a runtime value. It might not be quite ready for use yet but it should be able to make it a lot more useful. GCC also seems open to adding it too.