Received: by 10.192.165.148 with SMTP id m20csp112834imm; Thu, 3 May 2018 16:02:37 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoOsD6FYzv3qu9jUPvxIQcJZorpcgVVX6mWxoQag5HQDtmQHmJKZ8UN4BKz0acQdBxdYFtL X-Received: by 10.98.205.69 with SMTP id o66mr24770244pfg.250.1525388557396; Thu, 03 May 2018 16:02:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525388557; cv=none; d=google.com; s=arc-20160816; b=wljL3ddZDaoe0GCphQ3cYx9dO9DmuVAJd6yRZpEFHU/FR0Km2TXUUy5L+EXx/hc3aw +kmPcvfp1o0zWkQZjRMRPRAj0RyG13/FV2pYO0PdPcgdZGM0LYw+22/T0BsCksN4oqEK 4Fp+brYIleaTYLGggWQ6QTOPmoX39y8DjenEC1KB+5sjPlrfjlHY5J6SFg2bHhmj19EJ S/8pfaprO3evmrz1Dc7jd6SrPAjYCq68kzBtHHl4E/X8LtkjJYBDyeVXeNDir3Lpv68x Jp50zKJKSkauMelKzDkkP+k/CsCQarfjQDB1sFv4j+wpbyrjaExQjpSEBq7uvqW3pNOe 0SwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=O+Lrn2lKB4gkOyLjCccSfgJ9fnUIL7BNXmxLDCqEhdk=; b=P+aCKpHD5OTY7BMFI4F8fGsVKRNg20L+kvvTknOGx4poQUMhFpHdAPJWal5wgyW5/+ IE6/RcjSNJ8ManIehS8sfUob3UAkR5dilL8YWPnSclYZNXZ+bBDXgUrKMcuLfAmdA0Xj 7srg9pq7rzKEaXW4lR/lCFW035Ne76LuHoZV6q5GYHdDAEtsQu3zDjhStQfhx8zlKT/i c2S08kD6z0TkDqc+BTlHA75s8ll2C2Ou78NIwIXnTaG0Rs488XT6q8yDbc3LPENFKauo LTGxBfxevcyW/B1DcMVqGIqtXLsi5aIHOWV9Y66+9+fPzvn0z/l/DWLsudJdtEWA31jy iyug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rasmusvillemoes.dk header.s=google header.b=Nc+8LkI8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g11-v6si14949228plt.284.2018.05.03.16.02.23; Thu, 03 May 2018 16:02:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@rasmusvillemoes.dk header.s=google header.b=Nc+8LkI8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751359AbeECXAw (ORCPT + 99 others); Thu, 3 May 2018 19:00:52 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:37372 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751111AbeECXAv (ORCPT ); Thu, 3 May 2018 19:00:51 -0400 Received: by mail-wm0-f66.google.com with SMTP id l1-v6so1602251wmb.2 for ; Thu, 03 May 2018 16:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=O+Lrn2lKB4gkOyLjCccSfgJ9fnUIL7BNXmxLDCqEhdk=; b=Nc+8LkI82vXd6tD0PS6YrZAaNvEDiKIUEZgdhBkkPB8VBXTu3AAt3du35yXv1qi8Hx SbDMwB1GnNKnoEpyUmwpOddpK971kowPd0QIDDNCCzra7MOhCj7LwTKJ6iAdg3ttCBP5 StZT+qgCbQ0XBD0NYdu/L+Vaa2uObMlAiU6XU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=O+Lrn2lKB4gkOyLjCccSfgJ9fnUIL7BNXmxLDCqEhdk=; b=K6HQrr3AB4g5VgRLkCDN0wy8hkNAogr5T9FctXk6Yuyml0a+yDR87e+KhyHoIjOvEu IPvzPrv/bMF6yKf5jf0aa+1t8K/JFNkXrgXRy/rq9J4SamIKc0p99ohwUttOFT2Ehckp V9XK9nCYhQBA5enHe1u3vg4DxOwyqn0LXEF8K3pQaibMm+CU/j+yRQIsGCx/HRfe8L21 wJFzk5IxadfWPUTI82v3C6T4XKDXuzxFpj0BE3D8to+dKphypUb6D9pzYD2ikwdJyFwm +qNo2YVyVvwWMmzqX3XTN8Ig/wWaossC0zJFVgEpaxsCkGHIw0tAPBduc6S1pQ8MjNBz mmbA== X-Gm-Message-State: ALQs6tCCglzvbIKyWChV3zSv/NDDzEHO67JzWH8bS2Psv1PQ6PAEL229 OoZoYHBCGeNpxnpc2wWrr5Xmrw== X-Received: by 2002:a50:8b26:: with SMTP id l35-v6mr32877192edl.224.1525388450363; Thu, 03 May 2018 16:00:50 -0700 (PDT) Received: from [192.168.0.189] (dhcp-5-186-126-104.cgn.ip.fibianet.dk. [5.186.126.104]) by smtp.gmail.com with ESMTPSA id b7-v6sm9064518eda.18.2018.05.03.16.00.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 May 2018 16:00:49 -0700 (PDT) Subject: Re: [PATCH 2/2] mm: Add kvmalloc_ab_c and kvzalloc_struct To: Kees Cook , Daniel Vetter Cc: Matthew Wilcox , Julia Lawall , Andrew Morton , Matthew Wilcox , Linux-MM , LKML , Kernel Hardening , cocci@systeme.lip6.fr, Himanshu Jha References: <20180308025812.GA9082@bombadil.infradead.org> <20180308230512.GD29073@bombadil.infradead.org> <20180313183220.GA21538@bombadil.infradead.org> <20180429203023.GA11891@bombadil.infradead.org> <20180430201607.GA7041@bombadil.infradead.org> <4ad99a55-9c93-5ea1-5954-3cb6e5ba7df9@rasmusvillemoes.dk> From: Rasmus Villemoes Message-ID: <4e25ff5b-f8fc-7012-83c2-b56e6928e8bc@rasmusvillemoes.dk> Date: Fri, 4 May 2018 01:00:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-05-01 19:00, Kees Cook wrote: > On Mon, Apr 30, 2018 at 2:29 PM, Rasmus Villemoes > wrote: >> >> gcc 5.1+ (I think) have the __builtin_OP_overflow checks that should >> generate reasonable code. Too bad there's no completely generic >> check_all_ops_in_this_expression(a+b*c+d/e, or_jump_here). Though it's >> hard to define what they should be checked against - probably would >> require all subexpressions (including the variables themselves) to have >> the same type. >> >> plug: https://lkml.org/lkml/2015/7/19/358 > > That's a very nice series. Why did it never get taken? Well, nobody seemed particularly interested, and then https://lkml.org/lkml/2015/10/28/215 happened... but he did later seem to admit that it could be useful for the multiplication checking, and that "the gcc interface for multiplication overflow is fine". I still think even for unsigned types overflow checking can be subtle. E.g. u32 somevar; if (somevar + sizeof(foo) < somevar) return -EOVERFLOW; somevar += sizeof(this); is broken, because the LHS is promoted to unsigned long/size_t, then so is the RHS for the comparison, and the comparison is thus always false (on 64bit). It gets worse if the two types are more "opaque", and in any case it's not always easy to verify at a glance that the types are the same, or at least that the expression of the widest type is on the RHS. > It seems to do the right things quite correctly. Yes, I wouldn't suggest it without the test module verifying corner cases, and checking it has the same semantics whether used with old or new gcc. Would you shepherd it through if I updated the patches and resent? Rasmus