Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp4060540pxb; Tue, 26 Jan 2021 11:17:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJyw27p7zk7EC2VMwi6PoglbkZJYi4TDSK+w95rjAyTv5Lvrv/SA/oKEJfJjVd+8Uw99jk0U X-Received: by 2002:a17:907:16a2:: with SMTP id hc34mr4523391ejc.9.1611688657538; Tue, 26 Jan 2021 11:17:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611688657; cv=none; d=google.com; s=arc-20160816; b=0+mW9wIBvw0SWfZQzx6ctQFoAwE7/G3gbLTyCaZw0i2HOl+77ZXgl0on6W48ELzrIh 8YcqigIpGyoHJDMU+R7MuMikYfzIh/E5GCLCFj3WYH67wO451l4ar4dpMu28JVgDgcch KBuS/R1xkdHnNm+MN0M0hX9IToggtyM5Rh8SVjUChw+k2NSwzEFsndgVPtVUtsGtjCjT XgsF3d6nNTveu56ADbIcfJjycMJtgZxpQG++4y+/hlkmNRhq36GL2nnMfOegvPaYHSyj +ZSi/oXh8U0+ja/aorCVC6de0sy8As+7ZsvqDDq32CUfKAw5rBdS+vrQVk04UM8uRLNw XzeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=JYmGL08JF+gArRQ9p5k0wHfnv2GHvkk5CmReF6hsoP4=; b=Odq7HQcq/Kne1f8Zy90KPIjeRW3N6LbEVNh/Njeot3oaW03LXEeQeet0fRdHHHVpcl 25jYJzeEGx88b17SKGcg68WKlsHMDqvOzWPW5Yg/LekweZpJIbuFMa844cmnDC3GMO+v Gwtm6zorr6OPOV2kG1czLKMwZNn4Eiou8g+T4u2SoCiWGRGxJkKFnz0vNFZz1umREQOw pmHuno3BzVVrkwi058wWjKN59Kh9TN1z2Y1e5T5AfmQLeAMpC+spXZ17xq5s9P6mLqfg 6OMinOyDKyB2ByDr6idiAvOxFN6XNKlbUvAHjPWS8PdOQbzVP+MCh3t8rFqgnxMhOZxX R3wg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gLTsYT5t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b24si7348624ejp.190.2021.01.26.11.17.12; Tue, 26 Jan 2021 11:17:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gLTsYT5t; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405777AbhAZOx7 (ORCPT + 99 others); Tue, 26 Jan 2021 09:53:59 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:47196 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391355AbhAZOxa (ORCPT ); Tue, 26 Jan 2021 09:53:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611672722; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JYmGL08JF+gArRQ9p5k0wHfnv2GHvkk5CmReF6hsoP4=; b=gLTsYT5tXl7cYR3lptw28rmQghstxPXNbKb6TxqKx4rX+6PeE7GaYPE1j4akkEB37bZ9nv V/w19cxO6C4FyPS+k1NpIwTcrm1lxj/+gxyWXJOfteXNcXR4ZbWhr+1coV81VZBcfUOCya DBiUM/vGmThwe7KO5eWLJAmPWN6nr/c= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-118-Fy7Ek9dBP26p1I4vvyZkDg-1; Tue, 26 Jan 2021 09:52:00 -0500 X-MC-Unique: Fy7Ek9dBP26p1I4vvyZkDg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B63A515722; Tue, 26 Jan 2021 14:51:58 +0000 (UTC) Received: from treble (ovpn-120-118.rdu2.redhat.com [10.10.120.118]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 79B3260CD1; Tue, 26 Jan 2021 14:51:57 +0000 (UTC) Date: Tue, 26 Jan 2021 08:51:55 -0600 From: Josh Poimboeuf To: Greg KH Cc: Justin Forbes , Masahiro Yamada , Kees Cook , Linux Kernel Mailing List , Michal Marek , linux-hardening@vger.kernel.org, Linux Kbuild mailing list , Peter Zijlstra , Ondrej Mosnacek Subject: Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules Message-ID: <20210126145155.kcfbnzfqg5qugvcl@treble> References: <20210125212755.jfwlqogpcarmxdgt@treble> <20210125220757.vxdsf6sttpy46cq7@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 26, 2021 at 02:51:29PM +0100, Greg KH wrote: > On Tue, Jan 26, 2021 at 06:44:44AM -0600, Justin Forbes wrote: > > On Tue, Jan 26, 2021 at 2:21 AM Greg KH wrote: > > > > > > On Mon, Jan 25, 2021 at 04:07:57PM -0600, Josh Poimboeuf wrote: > > > > On Tue, Jan 26, 2021 at 06:44:35AM +0900, Masahiro Yamada wrote: > > > > > > > If people use a different compiler, they must be > > > > > > > prepared for any possible problem. > > > > > > > > > > > > > > Using different compiler flags for in-tree and out-of-tree > > > > > > > is even more dangerous. > > > > > > > > > > > > > > For example, CONFIG_GCC_PLUGIN_RANDSTRUCT is enabled > > > > > > > for in-tree build, and then disabled for out-of-tree modules, > > > > > > > the struct layout will mismatch, won't it? > > > > > > > > > > > > If you read the patch you'll notice that it handles that case, when it's > > > > > > caused by GCC mismatch. > > > > > > > > > > > > However, as alluded to in the [1] footnote, it doesn't handle the case > > > > > > where the OOT build system doesn't have gcc-plugin-devel installed. > > > > > > Then CONFIG_GCC_PLUGIN_RANDSTRUCT gets silently disabled and the build > > > > > > succeeds! That happens even without a GCC mismatch. > > > > > > > > > > > > > > > Ah, sorry. > > > > > > > > > > I responded too early before reading the patch fully. > > > > > > > > > > But, I do not like to make RANDSTRUCT a special case. > > > > > > > > > > I'd rather want to stop building for any plugin. > > > > > > > > Other than RANDSTRUCT there doesn't seem to be any problem with > > > > disabling them (and printing a warning) in the OOT build. Why not give > > > > users that option? It's harmless, and will make distro's (and their > > > > users') lives easier. > > > > > > > > Either GCC mismatch is ok, or it's not. Let's not half-enforce it. > > > > > > As I said earlier, it's not ok, we can not support it at all. > > > > > > > Support and enforce are 2 completely different things. To shed a bit > > more light on this, the real issue that prompted this was breaking CI > > systems. As we enabled gcc plugins in Fedora, and the toolchain folks > > went through 3 different snapshots of gcc 11 in a week. Any CI process > > that built an out of tree module failed. I don't think this is nearly > > as much of a concern for stable distros, as it is for CI in > > development cycles. > > It's better to have an obvious break like this than to silently accept > things and then have a much harder issue to debug at runtime, right? User space mixes compiler versions all the time. The C ABI is stable. What specifically is the harder issue you're referring to? -- Josh