Received: by 10.223.185.116 with SMTP id b49csp248261wrg; Thu, 8 Mar 2018 16:46:30 -0800 (PST) X-Google-Smtp-Source: AG47ELvU9mTeiViYahntVLC4wC/4R9/dqDnIz2Ff4N6boSrU0RHMpxYZ99T2NBftgbzK1bHLZwBm X-Received: by 10.98.247.9 with SMTP id h9mr28222441pfi.212.1520556390042; Thu, 08 Mar 2018 16:46:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520556390; cv=none; d=google.com; s=arc-20160816; b=qRudh9LJcnxnbg7GhX3dSWlHHL2GacxEy0uw78lwRNlFzzgZChVsKWiKIeq3s962y6 mLEcAWCRSd2+lOLOV/xdEmT/gtuB8KG+BZvMLWeViuhqNXBV/KcSd8JC1e87wsamucYV rekOf9Bm16HC8fjPRFyEd/8cC8wNmox1E8pUxeh4iVidgAhfVuy9NpGw4KiNI3WBM3Ba c5+VlLtRVgXwtB7pjeoKyVLgAWKMqcU7jkIHHkd5xtxYjFaCmcl0Qe14yJdObhqmc5YC TDmDJxxRuQN/jKJCa0CkhiR9q1pSK26nDGZlEkyFXCuHy4QSgOB/VKEb36oJmzWDVavC PtGg== 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=Gt6S3m61QB//6MnmHRHaVpeyvI/OjskR0bzCvxpnw8Y=; b=Kg8txpOlWS94/OEwYltiVnftfM+GVjeBBto3e/BY+43wjkZicMOHNw5t8vSh4wLD5o deUX1CVjwP+klvg3W/qo7PM0sxSMZKZVe0JZWfulQa17WYPqGBe/Rw3yGvx9Gdz2vlA2 rtwszGB3iXNHyWGS22ai8Zp6B03KlcSaYw+mpXGgHD7JwGkk+4l7+dJjVRYEpUiqxDjT 155voR3ipzZRkUZdI/MDTAnvV/VHB3ELBOrD1B6kqIQUWEMpP9ioN9g/2woBlmfh1EtE /c5U/v1ZWb2zgCPLheOLVPqtCjyob9OD+1PmpPmss+Zp+0kmaRr6BWn6qNzdNWjNrPha VPAQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=WeyQJRkz; dkim=fail header.i=@chromium.org header.s=google header.b=aSaALn2D; 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 o2si13480928pgq.750.2018.03.08.16.46.15; Thu, 08 Mar 2018 16:46:29 -0800 (PST) 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=WeyQJRkz; dkim=fail header.i=@chromium.org header.s=google header.b=aSaALn2D; 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 S1751483AbeCIApK (ORCPT + 99 others); Thu, 8 Mar 2018 19:45:10 -0500 Received: from mail-ua0-f193.google.com ([209.85.217.193]:37482 "EHLO mail-ua0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750848AbeCIApF (ORCPT ); Thu, 8 Mar 2018 19:45:05 -0500 Received: by mail-ua0-f193.google.com with SMTP id q12so1184118uae.4 for ; Thu, 08 Mar 2018 16:45:05 -0800 (PST) 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=Gt6S3m61QB//6MnmHRHaVpeyvI/OjskR0bzCvxpnw8Y=; b=WeyQJRkz7Af82BA3nscaOI4XLp95u4jfXu1lTQQFdUSvMK5p+0B5V0/C8qkCi75BMo AwI/Jms2iWYAInhlgELHVgSsLHjWTitfmsgapclB6GryBA+10CvnDghVEoc8DqOcyh4R L0OpnZfzB0m1QU6NRzxmWZxpy8zPA3KOjpeSB/ajMgmfSAkYfETDO9OkAS5tbmQkYY8R 1xfFM9bgUhyJLWLwbGfnSRT7h0Bk+Yz7o67dIAhdl+2Y17eLKbGCm3vQ3jAfLOmu7Uz6 Tvy25FCmvUDdwlOmJNttOZeIWoGv5MMJSivaFj6Xl5wizPGJqF67M913kUkXV2eclS0a UxYg== 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=Gt6S3m61QB//6MnmHRHaVpeyvI/OjskR0bzCvxpnw8Y=; b=aSaALn2Dt9u4NnZKiP/nzxG2gNuAzBp9/8vauQ35mrhtxax1LdZAsRH+UIhL1Tj1HJ EAQMT4p/TGdEZ8dRcWPApUlxvEUuvR5F+jiuFqXjIZi3Pqcy3k3AHmY92r/tbVWqbIuM KI62fUjev+zbS7xuyT6g0QEnqoAc+7p2NUENw= 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=Gt6S3m61QB//6MnmHRHaVpeyvI/OjskR0bzCvxpnw8Y=; b=Si+oD0LQ/CR9t0lNejWky6yt2YtpHWxFbOjWOTtHD515/arSc5yDnieiMdpvIoURXx vjLsYY0CpcVx1386jekBfQkozhjrFfbuRY6viyFpm4Qf+GdvvQKlCt3uOfYXETMGVM8Y lifLJCWBQ8XlgtTWB7Zd4PlG2/X0faMnDKdpq8HSkrGXtCVvHufquLD3WP9a8tz8Hl8L Inj72UGFm3xh1mL8r/bM2xdNP0FTmEdtHF9xaW/vZ9e3oKOpXmsq2+zdHHdodg5gWSmL bi6ua8wLZpeoxeuD7wgIulkQH0KzNHABG+/FbU/CDywV8ZinrZWWAfXHEmStbHXHM7Fn kOPw== X-Gm-Message-State: AElRT7ESHDU3fBrBewHpSM1LpJFymibPOK64NM0r4CGAwa52a1wuHiZe uNNMbDKC+6W0u30G/oQF5MEijv5ciTKKwopY7WtAnA== X-Received: by 10.176.48.231 with SMTP id d7mr9709554uam.0.1520556304375; Thu, 08 Mar 2018 16:45:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.242.140 with HTTP; Thu, 8 Mar 2018 16:45:03 -0800 (PST) In-Reply-To: References: <20180308214045.GA6787@beast> From: Kees Cook Date: Thu, 8 Mar 2018 16:45:03 -0800 X-Google-Sender-Auth: RvpRKXDuJjEsl6l2WSw39PDc6EI Message-ID: Subject: Re: [PATCH] kernel.h: Skip single-eval logic on literals in min()/max() To: Linus Torvalds Cc: Andrew Morton , Josh Poimboeuf , Rasmus Villemoes , "Gustavo A. R. Silva" , "Tobin C. Harding" , Steven Rostedt , Jonathan Corbet , Chris Mason , Josef Bacik , David Sterba , "David S. Miller" , Alexey Kuznetsov , Hideaki YOSHIFUJI , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , Masahiro Yamada , Borislav Petkov , Randy Dunlap , Ian Abbott , Sergey Senozhatsky , Petr Mladek , Andy Shevchenko , Pantelis Antoniou , 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 Thu, Mar 8, 2018 at 3:48 PM, Linus Torvalds wrote: > On Thu, Mar 8, 2018 at 1:40 PM, Kees Cook wrote: >> +#define __min(t1, t2, x, y) = \ >> + __builtin_choose_expr(__builtin_constant_p(x) && = \ >> + __builtin_constant_p(y) && = \ >> + __builtin_types_compatible_p(t1, t2), = \ >> + (t1)(x) < (t2)(y) ? (t1)(x) : (t2)(y), = \ > > I understand why you use __builtin_types_compatible_p(), but please don't= . > > It will mean that trivial constants like "5" and "sizeof(x)" won't > simplify, because they have different types. Rasmus mentioned this too. What I said there was that I was shy to make that change, since we already can't mix that kind of thing with the existing min()/max() implementation. The existing min()/max() is already extremely strict, so there are no instances of this in the tree. If I explicitly add one, I see this with or without the patch: In file included from drivers/misc/lkdtm.h:7:0, from drivers/misc/lkdtm_core.c:33: drivers/misc/lkdtm_core.c: In function =E2=80=98lkdtm_module_exit=E2=80=99: ./include/linux/kernel.h:809:16: warning: comparison of distinct pointer types lacks a cast (void) (&max1 =3D=3D &max2); \ ^ ./include/linux/kernel.h:818:2: note: in expansion of macro =E2=80=98__max= =E2=80=99 __max(typeof(x), typeof(y), \ ^~~~~ ./include/linux/printk.h:308:34: note: in expansion of macro =E2=80=98max= =E2=80=99 printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__) ^~~~~~~~~~~ drivers/misc/lkdtm_core.c:500:2: note: in expansion of macro =E2=80=98pr_in= fo=E2=80=99 pr_info("%lu\n", max(16, sizeof(unsigned long))); ^~~~~~~ > The ?: will give the right combined type anyway, and if you want the > type comparison warning, just add a comma-expression with something > like like > > (t1 *)1 =3D=3D (t2 *)1 > > to get the type compatibility warning. When I tried removing __builtin_types_compatible_p(), I still got the type-check warning because I think the preprocessor still sees the "(void) (&min1 =3D=3D &min2)" before optimizing? So, I technically _can_ drop the __builtin_types_compatible_p(), and still keep the type warning. :P > Yeah, yeah, maybe none of the VLA cases triggered that, but it seems > silly to not just get that obvious constant case right. > > Hmm? So are you saying you _want_ the type enforcement weakened here, or that I should just not use __builtin_types_compatible_p()? Thanks! -Kees --=20 Kees Cook Pixel Security