Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3355639pxb; Mon, 25 Jan 2021 13:49:36 -0800 (PST) X-Google-Smtp-Source: ABdhPJyiCsh1j6EUxA9Je+MgR2r8HuZvg1pv+CsUREQrUImU88a/J9toUjn3I1fY38nN6G9cJPni X-Received: by 2002:a17:906:f991:: with SMTP id li17mr1610414ejb.31.1611611375927; Mon, 25 Jan 2021 13:49:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611611375; cv=none; d=google.com; s=arc-20160816; b=AWB9qxqngwZ0s2HXH9I3QhaBb9KPXS2I3y7He30r6LJub7NngtRyEQrag2Lgj+90eR zAjtSOyIYx9y2UNkJbAFioETDLsBYoQ9MP/aTY+1e5Op50aIxABvOT1GSLci8Lxe1TVx fAEPZXAZ1d1pcRHQsBQ1vikAA6S/uTwul8PGD5xGVvJdKwLgfKml0VCsYGbBeEFE61QL 7BeFx0YF0PWMo2VjHmtjGIiM/BhhTi3U/5n1lHUSje2HtRCJPamSQQJg+ePn3Gqp2dSO nUxEKxf9qFJ1bjjnMeG1ZQF+gyRfE0VZbRjMgLuprDDmD/oK64HBtiWGoMn3V0BYCAt5 aZpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature:dkim-filter; bh=jwaaWfOLyNeFlQAnNSQKJK+MaHiqrQ7LlTnPQQHpVeo=; b=sc2PsPVoCaPDrgQ5qaioxsGFwEU0MohvFrGhUQRsqMy1EGmQQ9Oy8hTN+CuFxcXigr 1w70NRVxixGg8tX3QiNzb05UnX3I0FULZYnOAo+gJGzu/quaQSBfOYHb2JhWHveRThUv uDaKnP7rrClwNQbWBmXAOdkmmE0hLLoPNrenwfM35DqwWokSK8vIZdVP7F4TWAaB7JeT JbXqFtI2ALQjxukgHlgRaopaTLuuiNr+DsdSowp1gcImQiUMPhGroCkkfoway7b0G1gy vq9caQp4z/5pwHsh/x/0PbiNHI6/Xwl6qDb61Kc1JSj1hEjGSQYyo60IfD5syhPTDKfM t8Lw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=Qks7wY5a; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t4si7687933edw.62.2021.01.25.13.49.12; Mon, 25 Jan 2021 13:49:35 -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=@nifty.com header.s=dec2015msa header.b=Qks7wY5a; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731802AbhAYVrl (ORCPT + 99 others); Mon, 25 Jan 2021 16:47:41 -0500 Received: from conssluserg-06.nifty.com ([210.131.2.91]:51450 "EHLO conssluserg-06.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732685AbhAYVql (ORCPT ); Mon, 25 Jan 2021 16:46:41 -0500 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) (authenticated) by conssluserg-06.nifty.com with ESMTP id 10PLjDno004170; Tue, 26 Jan 2021 06:45:13 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-06.nifty.com 10PLjDno004170 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1611611113; bh=jwaaWfOLyNeFlQAnNSQKJK+MaHiqrQ7LlTnPQQHpVeo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Qks7wY5aADVmF4XYs8OlPjdaDH3h5ka6z5dhbv7EP02zWHjZUTwRO31ezHou7DVnV 94Os2PewULekRpL7uxIc32AZj2biTHQ197L3zWJ09CHxN0BYKk5eve9841THtS6UKn +D1VVvRJN61oE29syEoqRXZIEGlY88UNt6q9aFaZuNqWMtJME3qp0BwNXCfhfirUHE F3uwgToQhJ3K2n8x9WubXsRObVlJavqRNdzR83DCg+9m0ZPjc5mgTIHY4MkFTjmKsJ VoCpxO/y63nufFpS6B1LOnf/95fsav2yPIyVmYWja89yL2jby54ngEqxr4H826Rm0z i4gtLs2qTHzrg== X-Nifty-SrcIP: [209.85.216.43] Received: by mail-pj1-f43.google.com with SMTP id a20so427653pjs.1; Mon, 25 Jan 2021 13:45:13 -0800 (PST) X-Gm-Message-State: AOAM531kMSxyyCztv9bTQCgrqJRA4uAO/u/+UNJsnRFFsaRF4Fx4sNlk S97zqW5Ju3kKhSIUoO+KX9aa62m+WwPUHbv3pxg= X-Received: by 2002:a17:90a:9a84:: with SMTP id e4mr2273222pjp.87.1611611112750; Mon, 25 Jan 2021 13:45:12 -0800 (PST) MIME-Version: 1.0 References: <20210125212755.jfwlqogpcarmxdgt@treble> In-Reply-To: <20210125212755.jfwlqogpcarmxdgt@treble> From: Masahiro Yamada Date: Tue, 26 Jan 2021 06:44:35 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules To: Josh Poimboeuf Cc: Kees Cook , Linux Kernel Mailing List , Michal Marek , linux-hardening@vger.kernel.org, Linux Kbuild mailing list , Peter Zijlstra , Justin Forbes , Ondrej Mosnacek Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 26, 2021 at 6:28 AM Josh Poimboeuf wrote: > > On Tue, Jan 26, 2021 at 06:16:01AM +0900, Masahiro Yamada wrote: > > On Tue, Jan 26, 2021 at 5:42 AM Josh Poimboeuf wrote: > > > > > > When building out-of-tree kernel modules, the build system doesn't > > > require the GCC version to match the version used to build the original > > > kernel. That's probably [1] fine. > > > > > > In fact, for many distros, the version of GCC used to build the latest > > > kernel doesn't necessarily match the latest released GCC, so a GCC > > > mismatch turns out to be pretty common. And with CONFIG_MODVERSIONS > > > it's probably more common. > > > > > > So a lot of users have come to rely on being able to use a different > > > version of GCC when building OOT modules. > > > > > > But with GCC plugins enabled, that's no longer allowed: > > > > > > cc1: error: incompatible gcc/plugin versions > > > cc1: error: failed to initialize plugin ./scripts/gcc-plugins/structleak_plugin.so > > > > > > That error comes from the plugin's call to > > > plugin_default_version_check(), which strictly enforces the GCC version. > > > The strict check makes sense, because there's nothing to prevent the GCC > > > plugin ABI from changing -- and it often does. > > > > > > But failing the build isn't necessary. For most plugins, OOT modules > > > will otherwise work just fine without the plugin instrumentation. > > > > > > When a GCC version mismatch is detected, print a warning and disable the > > > plugin. The only exception is the RANDSTRUCT plugin which needs all > > > code to see the same struct layouts. In that case print an error. > > > > > > [1] Ignoring, for the moment, that the kernel now has > > > toolchain-dependent kconfig options, which can silently disable > > > features and cause havoc when compiler versions differ, or even when > > > certain libraries are missing. This is a separate problem which > > > also needs to be addressed. > > > > > > Reported-by: Ondrej Mosnacek > > > Signed-off-by: Josh Poimboeuf > > > --- > > > > > > We are based on the assumption that we use the same > > compiler for in-tree and out-of-tree. > > Sorry, but that assumption isn't based in reality. And it's not > enforced. > > > 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. > > This patch is ugly, and not doing the right thing. > > Maybe, but I doubt the solution is to make assumptions. > > -- > Josh > -- Best Regards Masahiro Yamada