From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18FADC63777 for ; Thu, 26 Nov 2020 22:01:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AB32720DD4 for ; Thu, 26 Nov 2020 22:01:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="yBdnOJfR" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732498AbgKZWA7 (ORCPT ); Thu, 26 Nov 2020 17:00:59 -0500 Received: from mail.kernel.org ([198.145.29.99]:33096 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729608AbgKZWA7 (ORCPT ); Thu, 26 Nov 2020 17:00:59 -0500 Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2413E221E9 for ; Thu, 26 Nov 2020 22:00:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1606428058; bh=Xgbuor/K6EwrWLIYx10ku1nuvTAPw69hoyTl993aAUw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=yBdnOJfRHB/HaUrM5bTfaacI4pvpHgcKa/pitshDGzs1yMsu+Ryo2IRhs7zqouL6V uPcZerOzecDL377gZXk0hoW+CaK582cy4GixOIgFoFX+Tj57lqB2nSWTwNUWhCJnMy MNrDgdrtXW77QINZO/U/tRDoAR+Wq/dWVjQ93S30= Received: by mail-ot1-f54.google.com with SMTP id 79so2982950otc.7 for ; Thu, 26 Nov 2020 14:00:58 -0800 (PST) X-Gm-Message-State: AOAM530/Xci+0pTkWQd3NDIGpECxhhiGQnMLz1WVqHBt505ldc3dCBy+ W7XFAJGgQ4jl/LHMykhqF0p4kq7qMVKiNI8BCi4= X-Google-Smtp-Source: ABdhPJyFEk6PExOel56+j9A+DSCHI6p8Puw76JWC3DIf9hdq5060ZbmmIjd5o7XqRn+sLa92ggWzDd77V2/Uz09lS90= X-Received: by 2002:a05:6830:214c:: with SMTP id r12mr3585489otd.90.1606428057438; Thu, 26 Nov 2020 14:00:57 -0800 (PST) MIME-Version: 1.0 References: <202011131552.4kvOb9Id-lkp@intel.com> <20201113234701.GV2672@gate.crashing.org> <20201114002624.GX2672@gate.crashing.org> <202011251156.055E59A@keescook> <20201125230010.GC2672@gate.crashing.org> <20201126202207.GE2672@gate.crashing.org> In-Reply-To: <20201126202207.GE2672@gate.crashing.org> From: Ard Biesheuvel Date: Thu, 26 Nov 2020 23:00:46 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC][PATCH 21/24] x86/entry: Disable stack-protector for IST entry C handlers To: Segher Boessenkool Cc: Kees Cook , Miguel Ojeda , Nick Desaulniers , Alexandre Chartre , kbuild-all@lists.01.org, clang-built-linux , linux-toolchains@vger.kernel.org, kernel test robot , Arvind Sankar Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Thu, 26 Nov 2020 at 21:25, Segher Boessenkool wrote: > > On Thu, Nov 26, 2020 at 07:40:10AM +0100, Ard Biesheuvel wrote: > > On Thu, 26 Nov 2020 at 00:03, Segher Boessenkool > > wrote: > > > On Wed, Nov 25, 2020 at 11:56:40AM -0800, Kees Cook wrote: > > > > On Sat, Nov 14, 2020 at 11:20:17AM +0100, Ard Biesheuvel wrote: > > > > > In spite of the apparent difference of opinion here, there are two > > > > > irrefutable facts about __attribute__((optimize)) on GCC that can only > > > > > lead to the conclusion that we must never use it in Linux: > > > > > - the GCC developers refuse to rigorously define its behavior, so we > > > > > don't know what it actually does; > > > > > > This is because it isn't clear at all what it *should* do, for some > > > options. For others it is obvious, and it works just fine for those. > > > > The problem is that the distinction of some vs. others is not > > documented, and may change between architectures or GCC versions. > > And obvious is still obvious. > Not really, due to the way it interacts with other options set on the command line. > > > (And we do not rigorously define the behaviour of almost *anything*, not > > > in the user manual anyway!) > > > > > > The interface has huge usability problems. We want to wean people off > > > of using this attribute. But claiming all kinds of FUD about it is a > > > disservice to users: it works fine for where it does work, there is no > > > reason for people to hurriedly change their code (or change it at all). > > > > What do you mean by all kinds of FUD? The kind of FUD appearing on the > > GCC wiki? I'll quote it again here for everyone's convenience. > > > > No, saying "ohnoes this feature (that always worked fine for many > purposes) is so broken that it is super dangerous to keep using it even > a minute longer". _That_ FUD. > It is. When we add -fno-stack-protector on the command line, we do that for a reason. When we notice that __attribute__((optimize)) makes GCC forget about that, we have a problem. > > The reason we have to change code in the kernel is because it actually > > breaks stuff. > > That makes sense. Then please write *that*? :-) > See above. > > For instance, functions using __attribute__((optimize)) > > to disable GCSE are suddenly compiled with or without stack protector > > checks or frame pointers, even though the opposite option is set at > > the compilation unit level. > > Not that disabling GCSE makes much sense anyway (there are other passes > that do many of the same things, for example). So why was this added? > To avoid some bug on some older compiler version? > No, it is related to x86 specific tooling (objtool) that exists in Linux, which gets confused when code containing indirect gotos is built with GCSE. So the proposed fix was to use something like __attribute__((optimize("-fno-gcse,-fno-stack-protector,-fomit-frame-pointer"))) because just disabling GCSE interferes with those other options as well. I'm sure you can agree that this is not maintainable, and so __attribute__((optimize)) is simply not suitable for our use. But let's not get into objtool, that is another can of worms I'd prefer to keep closed. > > I am not disputing that __attribute__((optimize)) is highly useful in > > some cases, I am just arguing that such cases don't exist in a Linux > > kernel running on a production system. > > And I am saying that before you can remove something, you probably > should look at why it was added in the first place, and see if you need > a replacement for that, etc. Just destroying stuff you do not agree > with is iconoclasm. > I will point out again that this is not about whether the option itself takes effect or not, it is about the fact that other, completely unrelated options are affected as well, and those options may affect code generation in a way that can cause crashes or other catastrophic failures.