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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C784AC433EF for ; Wed, 6 Oct 2021 03:56:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 61AF0611C1 for ; Wed, 6 Oct 2021 03:56:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 61AF0611C1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id BDF306B006C; Tue, 5 Oct 2021 23:56:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B8F38900002; Tue, 5 Oct 2021 23:56:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A564F6B0073; Tue, 5 Oct 2021 23:56:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0207.hostedemail.com [216.40.44.207]) by kanga.kvack.org (Postfix) with ESMTP id 940A76B006C for ; Tue, 5 Oct 2021 23:56:47 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 32B111837E006 for ; Wed, 6 Oct 2021 03:56:47 +0000 (UTC) X-FDA: 78664651254.33.DCEF8F2 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) by imf06.hostedemail.com (Postfix) with ESMTP id D89E6801AB32 for ; Wed, 6 Oct 2021 03:56:46 +0000 (UTC) Received: by mail-pf1-f179.google.com with SMTP id u7so1174425pfg.13 for ; Tue, 05 Oct 2021 20:56:46 -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=b84QyZzxdfWttrk72IQ61VKUmWrKjM777rszm24bGaM=; b=LURrqYKe8uPYHzUH11ppbTUR0uO0Bztb64979rnO6hUW73LrpVFSwWuNCl1NDlCDVZ Iytf4MzDURalEMfX8EvXzSF7Ab5BUKCl7UcOuTJdrmn4IL65AkFew6NB6iagqN/XzZ0Y C+9VMTGMKbmk+/Su+diio1PMQLNQ0YGZiwpNU= 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=b84QyZzxdfWttrk72IQ61VKUmWrKjM777rszm24bGaM=; b=XhxqvHauQPMxeQksksmG5MVbMX7pjJIxTslzc7D4+j64sobo64GbdaFgLRDiwzpk5O LLSMbHiDMqOeG23b7DZwBnqLO66R8k1NOp3Upi1PWA2J9sahsNRE73pYJcfRcGa60zjJ 9Np6sc3WVFBAGCqzNshyvaz+mwiZ4QfFVpaX0p6YSBUPLA9HjGitsLd99g5DJ7c7ZIG1 X4AKWKhrxgC/IgeAmoYvBvyJVPQAJ8GRYOzW+1PpLHyFDg6lyOR0F4woI6+QY9PHX7fu Jx7i3T+eE0zK4N5NsF3hUSP5PYIuK8ANW5pdbicvvrCSB29Uq7ypf6AWz4nJV0rG4jS0 4+dQ== X-Gm-Message-State: AOAM530fZ+DqDSFWehKI5sL8kg0Zhraw6TGtdyCyxRdY+bjjNB0GmIIX Y+Svg/r00PB9MeFj4gcvDZv1Vg== X-Google-Smtp-Source: ABdhPJxY0xeG5xlVDooWwmTdv3QhIZVaLpcWEFnuLL4tOLEdHX4A7rjnWkeJWxZVz6fUPOx3FAmCuw== X-Received: by 2002:aa7:9209:0:b0:44b:e5d4:d8cb with SMTP id 9-20020aa79209000000b0044be5d4d8cbmr34958352pfo.65.1633492605823; Tue, 05 Oct 2021 20:56:45 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id z23sm19421948pgv.45.2021.10.05.20.56.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Oct 2021 20:56:45 -0700 (PDT) Date: Tue, 5 Oct 2021 20:56:44 -0700 From: Kees Cook To: Jann Horn Cc: Andrew Morton , 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: <202110052056.F09CD8A@keescook> References: <20210930222704.2631604-1-keescook@chromium.org> <20210930222704.2631604-5-keescook@chromium.org> <20211005184717.65c6d8eb39350395e387b71f@linux-foundation.org> <202110052002.34E998B@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: D89E6801AB32 X-Stat-Signature: me3o51kj6opzcqyoo196bgcf74a5e4fh Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=LURrqYKe; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf06.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.179 as permitted sender) smtp.mailfrom=keescook@chromium.org X-HE-Tag: 1633492606-923467 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, Oct 06, 2021 at 05:22:06AM +0200, Jann Horn wrote: > On Wed, Oct 6, 2021 at 5:06 AM Kees Cook wrote: > > 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; > > Maybe OPTIMIZER_HIDE_VAR()? The normal version of that abuses an empty > asm statement to hide the value from the compiler. Oh! I hadn't seen that before. Is that better than volatile in this case? -- Kees Cook