Received: by 10.223.185.116 with SMTP id b49csp1237007wrg; Wed, 21 Feb 2018 14:48:40 -0800 (PST) X-Google-Smtp-Source: AH8x225CiV9Hk8UXAAs+ZiuHxJ3Lx/ypj5mjTSnzwzR8LweEciiLKQP6fbYHzrHoL7XjJsl3bOZ3 X-Received: by 10.101.97.72 with SMTP id o8mr3975563pgv.119.1519253320077; Wed, 21 Feb 2018 14:48:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519253320; cv=none; d=google.com; s=arc-20160816; b=sFElFXwqnQNGgeFl9Dx1r7w7J99GXQTupFjtYC2hS+Em58RSfiTejH6YAP8NsEBYRc +CKG2kXlpglGRU19cOwc9WbBNPYk+jYfd7usUp3DislIdY+ZqwIQsiFPGuRf3hgS2I0t s0Zz1PxS0EuehT67IlboUShg1NQtUTbQuCRu3/2/UKcineWRlkMn/li6MXUXbRLr6W1d 22RwVm/fE7Xylqfb4yFr24MM1ceuiVro0R7Qu6wNq4yLJV6gbtgqNGjklFyVeRRpXTG5 MUsvwEbPNLxLPiJX1U4D+UubG64ndZ5M04EBUkcMkjxdW3snCIWUvQm7FbV6Vaz6Iv8a c6ug== 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:arc-authentication-results; bh=1PZcvfUajswGpVWPSiVtIZHjBVvuJujtPvjGby0/8So=; b=G6Xeu8LnTvtgBNtjEYUD4dm3OmBmRAfcxIrlBsFD70abVTbebmh2k3soECGHEzKQd8 lEomQnt62ynAe0U3R2epukhUbmotDA3mro2/JrAjSNOE8cL4keByGsBNNAmE0EUb2gLQ vz1csaTYj5tAfP3kzih8R/gMurWjwOAeQITN+WUxRja0CkjN60xxLqhfzs0JY0kbh0wx vcC2IAagE39zmdLcGtn2nuu1dSR5Zuk7zQM1PBs+3ZPuzyynKGZcK5pKSP32ftDsn/Pq /YL+0warwEp6tVlhnLZPrY3pM/8fypMGtEWgv8iVl+YdeREhZ4sJuaZJMsnAXOj7WDVo lXOQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=DoNBnQ3c; 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 o6-v6si257898plk.820.2018.02.21.14.48.25; Wed, 21 Feb 2018 14:48:40 -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=@gmail.com header.s=20161025 header.b=DoNBnQ3c; 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 S1751265AbeBUWrs (ORCPT + 99 others); Wed, 21 Feb 2018 17:47:48 -0500 Received: from mail-io0-f195.google.com ([209.85.223.195]:46454 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750752AbeBUWrq (ORCPT ); Wed, 21 Feb 2018 17:47:46 -0500 Received: by mail-io0-f195.google.com with SMTP id p78so3864796iod.13; Wed, 21 Feb 2018 14:47:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=1PZcvfUajswGpVWPSiVtIZHjBVvuJujtPvjGby0/8So=; b=DoNBnQ3cjPICacrmRf4zqFtk8I5jY2ipxGMrC8jd0t+MQOC6EdHC4nL332umhGwjNO Kkqh/o9NhO6qqi6dn+tA89fBE+EuA58F6FAqkIxihLwC2Otg112AFUyudVscfGrAYJ6q XWhqM+mNZLoSulxBqa2cT+4LW0eMVvJuc+EmfmS2NCSYD2adepLHX+QsGSbg8HFKrJv4 67O/lNfqQykA1mjPkWuobckEX9yNprECx194bN6BQNm4i7a4dC/xfIhcAZBtJ0sKFQ53 ejBvSClOdKOcndkIO46rOUJkQXC2mEs6YrXsRW0xsmFkLMCVivqBDSiAG9AnMEhiCd01 BfXg== 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=1PZcvfUajswGpVWPSiVtIZHjBVvuJujtPvjGby0/8So=; b=jP36CuLMe2QjuZQF9f0IdD0DoAoH3hzyz//GMWgp93KePmMO0WDsx4kEitzu+Zw91v D+0WGWCwkUZHRbolMeE1kaBf2tV7FnaFu4W+4R3H2OJNb7dSyf/XB6fmOJsYCzo9TNHn dA3bzdj5nhx8T8OKYkSByeps3HpfJgKPSowIM4NpVGZWVBGb4Iuc4nGylCKQGPlBq75u 4IChPYf/dHmqLpdOTp8P4OG6vNF7eL+wi3yWu6wqphLk394K5DIEMAREVmQncJSSzvnP ab3fiij8JPOZdYJ5eJtHZBx3GEjo333CEungnUqDQtRzm7SMnkKMBwmj6QVefnRg9HmF 3HMQ== X-Gm-Message-State: APf1xPDcZ9tzt9Fi5GG9aRY/dxlPMDahhvvHkBej4oO+hpVk5fGHqDX6 P7/ORBxt6O1nGzQgp0tBwBeSvhjHZTm/wskD5RI= X-Received: by 10.107.12.213 with SMTP id 82mr6222314iom.48.1519253264900; Wed, 21 Feb 2018 14:47:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.221 with HTTP; Wed, 21 Feb 2018 14:47:44 -0800 (PST) In-Reply-To: <6be06ce5-87e6-0d9d-55b9-6c70c3578ecf@maciej.szmigiero.name> References: <6be06ce5-87e6-0d9d-55b9-6c70c3578ecf@maciej.szmigiero.name> From: Linus Torvalds Date: Wed, 21 Feb 2018 14:47:44 -0800 X-Google-Sender-Auth: zCp95De_eVCC1yv8AhW6v_B20fI Message-ID: Subject: Re: RANDSTRUCT structs need linux/compiler_types.h (Was: [nfsd4] potentially hardware breaking regression in 4.14-rc and 4.13.11) To: "Maciej S. Szmigiero" Cc: Kees Cook , Patrick McLean , Emese Revfy , Al Viro , Bruce Fields , "Darrick J. Wong" , Linux Kernel Mailing List , Linux NFS Mailing List , Thorsten Leemhuis , "kernel-hardening@lists.openwall.com" 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 Wed, Feb 21, 2018 at 2:19 PM, Maciej S. Szmigiero wrote: > > One can see that offsets used to access various members of struct path ar= e > different, and also that the original file from step 3 contains an object > named "__randomize_layout". Whee. Thanks for root-causing this issue, and this syntax of ours is clearly *much* too fragile. We actually have similar issues with some of our other attributes, where out nice "helpful" attribute shorthand can end up being just silently interpreted as a variable name if they aren't defined in time. For most of our other attributes, it just doesn't matter all that much if some user doesn't happen to see the attribute. For __randomize_layout, it's obviously very fatal, and silently just generates crazy code. I'm not entirely sure what the right solution is, because it's obviously much too easy to miss some #include by mistake. It's easy to say "you should always include the proper header", but if a failure to do so doesn't end up with any warnings or errors, but just silent bad code generation, it's much too fragile. I wonder if we could change the syntax of that "__randomize_layout" thing. Some of our related helper macros (ie randomized_struct_fields_start/end) don't have the same problem, because if you don't have the define for them, the compiler will complain about bad syntax. And other attribute specifiers we encourage people to put in other parts of the type, like __user etc, so they don't have that same parsing issue. I guess one _extreme_ fix for this would be to put extern struct nostruct __randomize_layout; in our include/linux/kconfig.h, which I think we end up always including first thanks to having it on the command line. Because if you do that, you actually get an error: CC [M] fs/nfsd/nfs4xdr.o In file included from ./include/linux/fs_struct.h:5:0, from fs/nfsd/nfs4xdr.c:36: ./include/linux/path.h:11:3: error: conflicting types for =E2=80=98__rand= omize_layout=E2=80=99 } __randomize_layout; ^~~~~~~~~~~~~~~~~~ In file included from :0:0: ././include/linux/kconfig.h:8:28: note: previous declaration of =E2=80=98__randomize_layout=E2=80=99 was here extern struct nostruct __randomize_layout; ^~~~~~~~~~~~~~~~~~ make[1]: *** [scripts/Makefile.build:317: fs/nfsd/nfs4xdr.o] Error 1 and we would have figured this out immediately. Broken example patch appended, in case somebody wants to play with something like this or comes up with a better model entirely.. Linus --- diff --git a/include/linux/kconfig.h b/include/linux/kconfig.h index fec5076eda91..537dacb83380 100644 --- a/include/linux/kconfig.h +++ b/include/linux/kconfig.h @@ -4,6 +4,10 @@ #include +#ifndef __ASSEMBLY__ + extern struct nostruct __randomize_layout; +#endif + #define __ARG_PLACEHOLDER_1 0, #define __take_second_arg(__ignored, val, ...) val