Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp5181010pxb; Tue, 5 Oct 2021 20:07:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJweTS/n7kZ9JErBGO7vCHCD/DBxnDSPIXi06EyelNc4JcL7RjZ3Uzu5dv7kySJEBT8XooUD X-Received: by 2002:a17:90b:3144:: with SMTP id ip4mr7139582pjb.23.1633489648150; Tue, 05 Oct 2021 20:07:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633489648; cv=none; d=google.com; s=arc-20160816; b=Xz6liQpzGV2x+fJjiC2CJEUvz2fgYuv981TNPgqpCZSxqETUELY1oWE7VlKhP3b++1 ovMgqIRBHMOtHmE3ElhW4wmrh+SKEza58ZZUFxanT8JAmMecEegae0DMcAsHDbu5GAIV gNzGCRRsy4Pyek4uWzfEnIIG3JTGHynC9gnEDQ+B14Rzc8C6vPkOjxO0Bv7hZ+tjtKLp sjgBteI5PvnPv+klNbwlncb448ylrSxOYSMV8GRYhuqLSApeKWye/uT6k0DZCfXQf8Co BQfEm6Iv1/+9XArXHA++0+Y5G5rfvOipUxEnB1jIxjKIrY+z1s8qTximCzCYOEwiTb10 YFqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=h/B2/4lvsg/CGVwkkVTPAzFHikkG/kMza4mFfWJz56M=; b=PoJtDd35W9TY8W9DNhzWA7k111Es6dg2b6WKZq9Zo5fzJ3qXWzl7bjM2xGDlZw7npJ H95bVa0pYlmQhvv8o81uxVccltiH2PhRC6hcFQM2/SgizIqrShDxSkGQ8cg3RoxYbaRo C+32dT5CAVUP3pEnzCdgsGAJO3ZhItwo6dZFhNkr9ugrOsMZv8RCdFAxRgCNv0wP/Jhj t4uoBVHAwwUhuU/5azwe0XW9+btuXUi2Od2enfYODZvMYtVsoMbxqdFtvij2ig+VD9mQ WcYlG1WByrL4ftZvZV2d+L5Q137rt2c07FnRPrpJN6hr5h7a+AOZiL38XjVY25QZ67d7 5D0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=RoIQ370O; 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=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w16si23917209plk.198.2021.10.05.20.07.13; Tue, 05 Oct 2021 20:07:28 -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=@chromium.org header.s=google header.b=RoIQ370O; 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=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230261AbhJFDIO (ORCPT + 99 others); Tue, 5 Oct 2021 23:08:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50700 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230306AbhJFDIN (ORCPT ); Tue, 5 Oct 2021 23:08:13 -0400 Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CEA2AC061749 for ; Tue, 5 Oct 2021 20:06:21 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id rm6-20020a17090b3ec600b0019ece2bdd20so1206647pjb.1 for ; Tue, 05 Oct 2021 20:06:21 -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=h/B2/4lvsg/CGVwkkVTPAzFHikkG/kMza4mFfWJz56M=; b=RoIQ370OysL/Vat32I9DE1b65g2D9zD1Su7VuAiStesPYk8mNSoeyahvzP3MVGUf35 9s7no6dpO/dT6vVvpKpHp23xb2HwN3BPV7urynVsqosllSY4TX1f72huqIqUzBWz2fVr g7bKg+U3G3fU6Z7TcAByj7Ma+/ydevcwWBjUU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=h/B2/4lvsg/CGVwkkVTPAzFHikkG/kMza4mFfWJz56M=; b=ulYJw4JFad1GKP7kBDo4+ushhsIun7Ao1H3FoFknNi3RgXqkAe5x3UHoSO2XrHvdA4 xJYGANQSEwZbarPCchezQI1p6aH5SrdUleo9EKxuuozBHt5tpxf+WJegPwVC7DL7G7D4 Uvjg5DTXHGUYwXpyn17pR8dyYY2OGdL9Wv0P5U9G64RcGQIMNXroeVdwNKXGNk1txzBH kUy/HvOe7dOswNRefP2/m/hKSORKi9cJLuea82Bzo2Bx9EnRF3L+28vZv4pvcSC3x+/b fwWEgGzCtCyzfcWvCjdPf2gxhIT0epOA9EE8LhUBpzP5UXJXhWtWNZ85cx1YwKbHDYMB pSdw== X-Gm-Message-State: AOAM532/a3GFzYnxM6mvyTfVr8+Pdqrq1QhsLGt0/LWN/EXwmHIw21mb CGjfsbcgwywKvo+lUug8MHWCag== X-Received: by 2002:a17:90a:6405:: with SMTP id g5mr7951706pjj.71.1633489581366; Tue, 05 Oct 2021 20:06:21 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id y8sm19333896pfe.217.2021.10.05.20.06.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Oct 2021 20:06:21 -0700 (PDT) Date: Tue, 5 Oct 2021 20:06:20 -0700 From: Kees Cook To: Andrew Morton Cc: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Vlastimil Babka , Andy Whitcroft , Dennis Zhou , Dwaipayan Ray , Joe Perches , Lukas Bulwahn , Miguel Ojeda , Nathan Chancellor , Tejun Heo , Daniel Micay , Nick Desaulniers , Masahiro Yamada , Michal Marek , clang-built-linux@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH v3 4/8] slab: Add __alloc_size attributes for better bounds checking Message-ID: <202110052002.34E998B@keescook> References: <20210930222704.2631604-1-keescook@chromium.org> <20210930222704.2631604-5-keescook@chromium.org> <20211005184717.65c6d8eb39350395e387b71f@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211005184717.65c6d8eb39350395e387b71f@linux-foundation.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 05, 2021 at 06:47:17PM -0700, Andrew Morton wrote: > On Thu, 30 Sep 2021 15:27:00 -0700 Kees Cook wrote: > > > As already done in GrapheneOS, add the __alloc_size attribute for regular > > kmalloc interfaces, to provide additional hinting for better bounds > > checking, assisting CONFIG_FORTIFY_SOURCE and other compiler > > optimizations. > > x86_64 allmodconfig: What compiler and version? > > In file included from ./arch/x86/include/asm/preempt.h:7, > from ./include/linux/preempt.h:78, > from ./include/linux/spinlock.h:55, > from ./include/linux/mmzone.h:8, > from ./include/linux/gfp.h:6, > from ./include/linux/mm.h:10, > from ./include/linux/mman.h:5, > from lib/test_kasan_module.c:10: > In function 'check_copy_size', > inlined from 'copy_user_test' at ./include/linux/uaccess.h:191:6: > ./include/linux/thread_info.h:213:4: error: call to '__bad_copy_to' declared with attribute error: copy destination size is too small > 213 | __bad_copy_to(); > | ^~~~~~~~~~~~~~~ > In function 'check_copy_size', > inlined from 'copy_user_test' at ./include/linux/uaccess.h:199:6: > ./include/linux/thread_info.h:211:4: error: call to '__bad_copy_from' declared with attribute error: copy source size is too small > 211 | __bad_copy_from(); > | ^~~~~~~~~~~~~~~~~ > make[1]: *** [lib/test_kasan_module.o] Error 1 > make: *** [lib] Error 2 Hah, yes, it caught an intentionally bad copy. This may bypass the check, as I've had to do in LKDTM before. I will test... diff --git a/lib/test_kasan_module.c b/lib/test_kasan_module.c index 7ebf433edef3..9fb2fb2937da 100644 --- a/lib/test_kasan_module.c +++ b/lib/test_kasan_module.c @@ -19,7 +19,12 @@ static noinline void __init copy_user_test(void) { char *kmem; char __user *usermem; - size_t size = 128 - KASAN_GRANULE_SIZE; + /* + * This is marked volatile to avoid __alloc_size() + * noticing the intentionally out-of-bounds copys + * being done on the allocation. + */ + volatile size_t size = 128 - KASAN_GRANULE_SIZE; int __maybe_unused unused; kmem = kmalloc(size, GFP_KERNEL); -- Kees Cook