From patchwork Mon Jan 20 07:43:39 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Daniel Axtens X-Patchwork-Id: 11341185 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id B85D1921 for ; Mon, 20 Jan 2020 07:43:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 77436207E0 for ; Mon, 20 Jan 2020 07:43:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=axtens.net header.i=@axtens.net header.b="k+UiYYHG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 77436207E0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=axtens.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BE9CA6B05BA; Mon, 20 Jan 2020 02:43:51 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id B98B36B05BB; Mon, 20 Jan 2020 02:43:51 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A87686B05BC; Mon, 20 Jan 2020 02:43:51 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0071.hostedemail.com [216.40.44.71]) by kanga.kvack.org (Postfix) with ESMTP id 8C4D16B05BA for ; Mon, 20 Jan 2020 02:43:51 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 2BD6B2C33 for ; Mon, 20 Jan 2020 07:43:51 +0000 (UTC) X-FDA: 76397223462.22.care43_219077e86a75b X-Spam-Summary: 2,0,0,72500f98fed43973,d41d8cd98f00b204,dja@axtens.net,:kernel-hardening@lists.openwall.com::keescook@chromium.org:linux-kernel@vger.kernel.org:akpm@linux-foundation.org:dja@axtens.net,RULES_HIT:41:152:355:379:541:973:988:989:1260:1277:1311:1313:1314:1345:1437:1461:1515:1516:1518:1535:1543:1593:1594:1711:1730:1747:1777:1792:1801:2393:2559:2562:2693:2736:2892:3138:3139:3140:3141:3142:3355:3865:3866:3867:3868:3870:3871:3872:3874:4031:4117:4250:4321:4605:5007:6119:6261:6653:6691:7875:7903:7974:8603:10004:10400:11026:11658:11914:12043:12291:12296:12297:12438:12517:12519:12555:12663:12683:12895:12986:13161:13208:13229:13869:13894:14394:14659:14721:21067:21080:21325:21433:21444:21451:21627:21740:21990:30003:30005:30034:30054:30070:30075:30091,0,RBL:209.85.216.65:@axtens.net:.lbl8.mailshell.net-62.14.0.100 66.201.201.201,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:35,LUA_SUMMARY:none X-HE-Tag: care43_219077e86a75b X-Filterd-Recvd-Size: 6163 Received: from mail-pj1-f65.google.com (mail-pj1-f65.google.com [209.85.216.65]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Mon, 20 Jan 2020 07:43:50 +0000 (UTC) Received: by mail-pj1-f65.google.com with SMTP id e11so6762565pjt.4 for ; Sun, 19 Jan 2020 23:43:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=6YkuZ8tp2wmCPxdpgMXItiYj736TUwlM7992jMev2hM=; b=k+UiYYHG/v+VJD/4zWr69Wkd6H+h5loGovze3xLnJFbvL7nXcqhcsBh3ieanqlchRQ jcG9Xv5AvZxJ/UXVHazQgMkBxNtnZELVWNUt27L+7mDr53+M2Yan5mS45jhpnJa/NRZz v1nM8OE/bwDqVj/nZcOPD1br0C8bHAa892PKA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=6YkuZ8tp2wmCPxdpgMXItiYj736TUwlM7992jMev2hM=; b=BOw7q/w2ZYS2Jqv3C3T/g+eQnr3Ik6hXjOjIPkdWOJUsgjpCssPJqWID9nXtbmD5XJ w4settWXk2DhUweLumypkjzX8GTLKau9HZ4ZLKGgZdmq660kaHNmGE6bn7f1C/Kx/5xO 2e8ErHHBNTzFxXBHNAC3fufbBprTvzI7J/2zpZ8yO6ts5264hqjJIUaqULBaRh/UHETV HXPzg05JbOeDCku1A1RV9H+J2xNTSgwsVbk0JXcdf2/W7NGV0tD/0fV6Nbz+Nl0XUPrQ RQoqyN0156zCONZ6KBewoOkUu1oWClUf45iLPYz4Mye+TX/gshYavcZXr14dVwo1vgvF 2A2g== X-Gm-Message-State: APjAAAXVq3TR5sHTyJ5F0yLAtUyXw2vyosbppx88W0aS84ngEg5K2nt9 Em6EJO2p5JP3trWlTpy0u6rXpQ== X-Google-Smtp-Source: APXvYqx6WIelXXQ1XxBQSJPB9fvVEwMpFGLYN0Oq9eHgf6RjMRe6JDnsTVkTumU89S7sClpvNsw8dQ== X-Received: by 2002:a17:902:b704:: with SMTP id d4mr12873725pls.54.1579506229307; Sun, 19 Jan 2020 23:43:49 -0800 (PST) Received: from localhost (2001-44b8-1113-6700-4064-d910-a710-f29a.static.ipv6.internode.on.net. [2001:44b8:1113:6700:4064:d910:a710:f29a]) by smtp.gmail.com with ESMTPSA id 83sm37136676pgh.12.2020.01.19.23.43.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Jan 2020 23:43:48 -0800 (PST) From: Daniel Axtens To: kernel-hardening@lists.openwall.com, linux-mm@kvack.org, keescook@chromium.org Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org, Daniel Axtens Subject: [PATCH 0/5] Annotate allocation functions with alloc_size attribute Date: Mon, 20 Jan 2020 18:43:39 +1100 Message-Id: <20200120074344.504-1-dja@axtens.net> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 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: Both gcc and clang support the 'alloc_size' function attribute. It tells the compiler that a function returns a pointer to a certain amount of memory. This series tries applying that attribute to a number of our memory allocation functions. This provides much more information to things that use __builtin_object_size() (FORTIFY_SOURCE and some copy_to/from_user stuff), as well as enhancing inlining opportunities where __builtin_mem* or __builtin_str* are used. With this series, FORTIFY_SOURCE picks up a bug in altera-stapl, which is fixed in patch 1. It also generates a bunch of warnings about times memory allocation functions can be called with SIZE_MAX as the parameter. For example, from patch 3: drivers/staging/rts5208/rtsx_chip.c: In function ‘rtsx_write_cfg_seq’: drivers/staging/rts5208/rtsx_chip.c:1453:7: warning: argument 1 value ‘18446744073709551615’ exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] data = vzalloc(array_size(dw_len, 4)); ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The parameter to array_size is a size_t, but it is called with a signed integer argument. If the argument is a negative integer, it will become a very large positive number when cast to size_t. This could cause an overflow, so array_size() will return SIZE_MAX _at compile time_. gcc then notices that this value is too large for an allocation and throws a warning. I propose two ways to deal with this: - Individually go through and address these warnings, usualy by catching when struct_size/array_size etc are called with a signed type, and insert bounds checks or change the type where appropriate. Patch 3 is an example. - Patch 4: make kmalloc(_node) catch SIZE_MAX and return NULL early, preventing an annotated kmalloc-family allocation function from seeing SIZE_MAX as a parameter. I'm not sure whether I like the idea of catching SIZE_MAX in the inlined functions. Here are some pros and cons, and I'd be really interested to hear feedback: * Making kmalloc return NULL early doesn't change _runtime_ behaviour: obviously no SIZE_MAX allocation will ever succeed. And it means we could have this feature earlier, which will help to catch issues like what we catch in altera-stapl. * However, it does mean we don't audit callsites where perhaps we should have stricter types or bounds-checking. It also doesn't cover any of the v*alloc functions. Overall I think this is a meaningful strengthening of FORTIFY_SOURCE and worth pursuing. Daniel Axtens (5): altera-stapl: altera_get_note: prevent write beyond end of 'key' [RFC] kasan: kasan_test: hide allocation sizes from the compiler [RFC] staging: rts5208: make len a u16 in rtsx_write_cfg_seq [VERY RFC] mm: kmalloc(_node): return NULL immediately for SIZE_MAX [RFC] mm: annotate memory allocation functions with their sizes drivers/misc/altera-stapl/altera.c | 12 ++++---- drivers/staging/rts5208/rtsx_chip.c | 2 +- drivers/staging/rts5208/rtsx_chip.h | 2 +- include/linux/compiler_attributes.h | 6 ++++ include/linux/kasan.h | 12 ++++---- include/linux/slab.h | 44 +++++++++++++++++--------- include/linux/vmalloc.h | 26 ++++++++-------- lib/test_kasan.c | 48 +++++++++++++++++++++-------- 8 files changed, 98 insertions(+), 54 deletions(-)