Received: by 10.213.65.68 with SMTP id h4csp768015imn; Thu, 22 Mar 2018 08:09:22 -0700 (PDT) X-Google-Smtp-Source: AG47ELuNW5mwJ3BwIJ2voxwCWn+4z+Wbet4B8d0TTsyxqKiKtL9fj+NjAB/CbJXUkbrxNzdJEntm X-Received: by 10.98.170.13 with SMTP id e13mr8420241pff.137.1521731361967; Thu, 22 Mar 2018 08:09:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521731361; cv=none; d=google.com; s=arc-20160816; b=SvTCSyMXCMyshiBAFTHfxWB8xd4WyBxEmBE7auwhrMtg5cxC2l0Q0m/Jtm62Iqgq7y K1nq4xt4O3+Hn+jcySjA3bEk8ZhCCFekShsb6WrRLWmHmM4o8OkEtZ9VnsRz/Q6DXfcE Uw/bJqeq90tYGAD7iRD2u0t6ELbiVa6IQ/z9QE55At2jmwbGiBwHtJ8V0H3aCnzyHaJ1 Pd10h69ThDDjwikIOB3FJ9eHRPqe2Z4QTDLWc6iQnnKGPYhXV+SiFhZo6hk8IK39qgkp pr7IRa6YF4XYW0luYe+Rsm1k3mi7wgSdsS3Yt+dqoq5EamoA55cqBe89bP6UjUmcCUiA DrGw== 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:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature:dkim-signature:arc-authentication-results; bh=VLSPWUJ0cZuCoJS3zaXtSZeorTu5j6/7rFkfi5XlhTs=; b=oSTUo7gXtAoBCcOIDvqqrWNeXbrRJDn5nsSX31olcw2HRhShvZtTYRCpa/ahzii1PJ 4neu0S0mwg7h3OvXGldMX1g5Fr8phT/eibHPgZ4j7O/guckNN/2s78ic9U2pWEdRZpJj Cym8NoAw8vbyAGtdo6jSEOKPDGvW2OUKSOD1d3cMcG3jlI26kiPui9yYXZD8pYWElVY1 Zp1B5APVGX/Pq3NTt11mMFtPIRpXDij9yJ6gz+/EZhL9JibjbJY5MwkOr3U5QUs0LGx7 f5ph8Rw85Htk2nnOqLss4loNVzD2E9dZJErHh0IcICzNjG9pTNRdAf5FS+3nikLJHd3s ihNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=qc81Zu6r; dkim=fail header.i=@chromium.org header.s=google header.b=BlS5XDH8; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b59-v6si3053907plb.530.2018.03.22.08.08.55; Thu, 22 Mar 2018 08:09:21 -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=fail header.i=@google.com header.s=20161025 header.b=qc81Zu6r; dkim=fail header.i=@chromium.org header.s=google header.b=BlS5XDH8; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754583AbeCVPHg (ORCPT + 99 others); Thu, 22 Mar 2018 11:07:36 -0400 Received: from mail-ua0-f194.google.com ([209.85.217.194]:33021 "EHLO mail-ua0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752613AbeCVPHe (ORCPT ); Thu, 22 Mar 2018 11:07:34 -0400 Received: by mail-ua0-f194.google.com with SMTP id f6so5778406ual.0 for ; Thu, 22 Mar 2018 08:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=VLSPWUJ0cZuCoJS3zaXtSZeorTu5j6/7rFkfi5XlhTs=; b=qc81Zu6rmP6MGDIuELDbOpRw8x/hlJYCsXD15L4ptsM1x97NsdOcrC0dj0JpyREM4V vVPmqimYa48D1JaZu5FJY69qYEu7G2sZvbKvu1NGZfPSZ0dGQh8/vh2ejpSxbjxv6YPw K8CiRXoN3/HfxCG4E8GW4TNIfn2F7LgDttkBcBy+k7dEWIHoeaRxAxh7Sk2OzAGqR8B+ S12KXqhIfa69PTd23NoM5AKWz5IjWZTyJXXK/8eWx1nuGttLQxgdnk80TWEDyuPNP0es GjKMlpFCv5GbPpmz8iGOK4vQJDlNEJtM77IB/YIbyBnXsFtF1Pq0jNUOX9ttlbjtTdyY 0QQQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=VLSPWUJ0cZuCoJS3zaXtSZeorTu5j6/7rFkfi5XlhTs=; b=BlS5XDH8xaE2e9tT3Z6B3pMwIDy3FlNyZXZKH17Shek45FoTfhfRmNALW3LNajNe0K RJpNxkyjF8nzKBSET0aFEzaIh+0ax8f0pPIrhZwzSfeBkcsqJs+MGMdVTVhBj4zlqpKR fkYPKu9SJpY00y+3+ES2bYL2X7AJAukSUSDBI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=VLSPWUJ0cZuCoJS3zaXtSZeorTu5j6/7rFkfi5XlhTs=; b=DiTXBfWOcx4jVWNxj1m7ZTDciQDd2vww1IfUHTNOrnrw2klbR8R8ThX1YuyIlJURXQ Go/VVNlx8hu62S7SzofqpFcrgaClHuXRC0KH53WWkhZj1S7AdEWEevbjK6VMwVljDFKw kP8LaIPVn918cE3yVvBmhLRnc+lu54OrBDkmwfwlGB5CjFjsPm9PnVbLgly/ltqbOv46 OWZvGPoI5s0WWfUMtcFvub1W47aH6SzFD/zSERs/XdswaF6O6EcO4T/IOoOJcC9et3+c kGRV4v+LBLvsbmNBC/du0pbR2Fj7dw3/NvUDgW1NnrQJHYcTBqAtllkdmdNu4oc7pp+J 8wHA== X-Gm-Message-State: AElRT7GVC7nuoX7V35nVnXhIiKwfnJ5dTtD/1kwlNCgv80I20kqLxSvK O5cDyVGw1bny5KjVdQ1/JBUn6hNiD7nFPaCIYPHJ5Q== X-Received: by 10.159.54.227 with SMTP id p90mr16504334uap.74.1521730886679; Thu, 22 Mar 2018 08:01:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.172.6 with HTTP; Thu, 22 Mar 2018 08:01:25 -0700 (PDT) In-Reply-To: References: <1521174359-46392-1-git-send-email-keescook@chromium.org> <20180316175502.GE30522@ZenIV.linux.org.uk> From: Kees Cook Date: Thu, 22 Mar 2018 08:01:25 -0700 X-Google-Sender-Auth: s_al2l8zf_ClnTEicNPxUGVtDOw Message-ID: Subject: Re: [PATCH v5 0/2] Remove false-positive VLAs when using max() To: Linus Torvalds Cc: Al Viro , Florian Weimer , Andrew Morton , Josh Poimboeuf , Rasmus Villemoes , Randy Dunlap , Miguel Ojeda , Ingo Molnar , David Laight , Ian Abbott , linux-input , linux-btrfs , Network Development , Linux Kernel Mailing List , Kernel Hardening Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 20, 2018 at 4:23 PM, Linus Torvalds wrote: > On Sat, Mar 17, 2018 at 1:07 PM, Kees Cook wrote: >> >> No luck! :( gcc 4.4 refuses to play along. And, hilariously, not only >> does it not change the complaint about __builtin_choose_expr(), it >> also thinks that's a VLA now. > > Hmm. So thanks to the diseased mind of Martin Uecker, there's a better > test for "__is_constant()": > > /* Glory to Martin Uecker */ > #define __is_constant(a) \ > (sizeof(int) =3D=3D sizeof(*(1 ? ((void*)((a) * 0l)) : (int*)1))) > > that is actually *specified* by the C standard to work, and doesn't > even depend on any gcc extensions. I feel we risk awakening Cthulhu with this. :) > The reason is some really subtle pointer conversion rules, where the > type of the ternary operator will depend on whether one of the > pointers is NULL or not. > > And the definition of NULL, in turn, very much depends on "integer > constant expression that has the value 0". > > Are you willing to do one final try on a generic min/max? Same as my > last patch, but using the above __is_constant() test instead of > __builtin_constant_p? So, this time it's not a catastrophic failure with gcc 4.4. Instead it fails in 11 distinct places: $ grep "first argument to =E2=80=98__builtin_choose_expr=E2=80=99 not a con= stant" log | cut -d: -f1-2 crypto/ablkcipher.c:71 crypto/blkcipher.c:70 crypto/skcipher.c:95 mm/percpu.c:2453 net/ceph/osdmap.c:1545 net/ceph/osdmap.c:1756 net/ceph/osdmap.c:1763 mm/kmemleak.c:1371 mm/kmemleak.c:1403 drivers/infiniband/hw/hfi1/pio_copy.c:421 drivers/infiniband/hw/hfi1/pio_copy.c:547 Seems like it doesn't like void * arguments: mm/percpu.c: void *ptr; ... base =3D min(ptr, base); mm/kmemleak.c: static void scan_large_block(void *start, void *end) ... next =3D min(start + MAX_SCAN_SIZE, end); I'll poke a bit more... -Kees --=20 Kees Cook Pixel Security