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=-11.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 5D083C4742C for ; Sat, 14 Nov 2020 00:49:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1A9F52225E for ; Sat, 14 Nov 2020 00:49:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ElzZMpKI" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725885AbgKNAsy (ORCPT ); Fri, 13 Nov 2020 19:48:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43742 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725866AbgKNAsy (ORCPT ); Fri, 13 Nov 2020 19:48:54 -0500 Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2CA6FC0613D1 for ; Fri, 13 Nov 2020 16:48:53 -0800 (PST) Received: by mail-pf1-x443.google.com with SMTP id w6so9078295pfu.1 for ; Fri, 13 Nov 2020 16:48:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=onm4dr1InisAD+cCAy/oaBVxFnLM3ZfeLTvFJjnOxb8=; b=ElzZMpKINpzIJEGiAAqPN0TJFl5TcaffPdzw1t5KP6v11bKZmvOu5ycVq+tNaRunlz QHrzO1OoSeyRRhsoewwAkDuh7KIO2+9xuZb197ujxcw7BplPGOPUqHkDQ0N18sJiOvS7 iCwrD8EDVIA0rtwytEICpUgXlHLMqwGvJKAi+uutEF7SW76CtFEWTStiRE5wA6iUpKjg b2Nr37YyuS/1XQa+P9324XQYJ5r/Vee9b0JVvcha/DBc37d63h3j7Jc8B+ztfJ5TIY6b KAeb4VZPrKwpOvAsQ/f5AoOPJXBRiVFIH2rnQKBADU7cpTGza6/vDY3QrKVH7uS2LKQO AafA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=onm4dr1InisAD+cCAy/oaBVxFnLM3ZfeLTvFJjnOxb8=; b=RUaDGh5beHKScme3FAfUtDDGT6nVLN+daGZOWhzKPAJQWGyPOXSO7bHOwViTGwimxV xxQjHWdkRN3d6JXuv2l3SpSxwJInFb+c5zyUwVLrp05OhKKZOWwSjYNDRoJsDVFhmwBY 9MZcx+Wl1BFD9MKKwf9UHKE0P2292vsrpv1n8NLO2HUyk0wBalQ8vIyUPnVcD6LsIoOp klxhBgCP/spiQ81tR136iH9NRjpIxyFrK8C8ay1wlLbKVyreL/dHNe4O5Au1evgZNTCs 5g395j6/SU8oRJvgEYUemX3irEaQ9qksztzz0FQpYe5NnQP/cuIBcT3krWLSPI07rkZE p9sQ== X-Gm-Message-State: AOAM531fjq9xBK4/AXCdDxI2P63epzfOUKHRzHsfRifBy7RSW48Jdl8n RNtC0erX3XwQx+8NoUivzUpntlWvWRdK+ypulswfLg== X-Google-Smtp-Source: ABdhPJzQZaoWCJoz4r2f+K79INecgvhCZ+FlAUGzt1GQ/z1HeaaEaT4cg7YFAcWom5k9Wwf2+N0khaQ+fHUDgEBHc0s= X-Received: by 2002:a63:b55e:: with SMTP id u30mr3825439pgo.381.1605314932422; Fri, 13 Nov 2020 16:48:52 -0800 (PST) MIME-Version: 1.0 References: <20201109144425.270789-22-alexandre.chartre@oracle.com> <202011131552.4kvOb9Id-lkp@intel.com> <20201113234701.GV2672@gate.crashing.org> <20201114004318.GY2672@gate.crashing.org> In-Reply-To: <20201114004318.GY2672@gate.crashing.org> From: Nick Desaulniers Date: Fri, 13 Nov 2020 16:48:41 -0800 Message-ID: Subject: Re: [RFC][PATCH 21/24] x86/entry: Disable stack-protector for IST entry C handlers To: Segher Boessenkool Cc: Alexandre Chartre , kbuild-all@lists.01.org, clang-built-linux , linux-toolchains@vger.kernel.org, kernel test robot , Arvind Sankar , Ard Biesheuvel , Miguel Ojeda , Peter Zijlstra , Linus Torvalds , Kees Cook Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Fri, Nov 13, 2020 at 4:45 PM Segher Boessenkool wrote: > > On Fri, Nov 13, 2020 at 04:11:41PM -0800, Nick Desaulniers wrote: > > On Fri, Nov 13, 2020 at 3:49 PM Segher Boessenkool > > wrote: > > > On Fri, Nov 13, 2020 at 10:59:26AM -0800, Nick Desaulniers wrote: > > > > The `optimize` attribute is both non-portable across toolchains (hence > > > > this warning) > > > > > > Like *all* GCC extensions. > > > > > > > and a little quirky in GCC. > > > > > > How so? Don't spread FUD please, say what *is* wrong, then people can > > > decide for themselves whether they want it or not. > > > > Spread FUD? Ard literally sent TO YOU: > > https://lore.kernel.org/lkml/CAMj1kXHxX+u5-cN0v3SLdqZTSiKsWsFOvc2SC5=-ScaUZOu8Ng@mail.gmail.com/, > > and it was referenced again in > > https://lore.kernel.org/lkml/20201028081123.GT2628@hirez.programming.kicks-ass.net/. > > > > Was it FUD when Ard sent it to you? > > He didn't say "this option is a little quirky". He simply quoted our > wiki entry for it, which says "use this only for debugging" (just like > the user documentation btw). The FAQ also goes on to explain the > attribute is very hard to use, it is not obvious at all what flags you > can and cannot set, it's a user interface disaster. It explains what is > bad with it, it doesn't just say "ooh I don't understand it, do not use > it". (It does say "no one really understands it, do not use it", there > is that ;-) ) Are we splitting hairs here? I want both toolchains to be successful; though maybe next time I see something like this patch/0day report go by, I'll just keep my mouth shut and we can deal with the runtime bugs later? -- Thanks, ~Nick Desaulniers From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============0045366968005964828==" MIME-Version: 1.0 From: Nick Desaulniers To: kbuild-all@lists.01.org Subject: Re: [RFC][PATCH 21/24] x86/entry: Disable stack-protector for IST entry C handlers Date: Fri, 13 Nov 2020 16:48:41 -0800 Message-ID: In-Reply-To: <20201114004318.GY2672@gate.crashing.org> List-Id: --===============0045366968005964828== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Fri, Nov 13, 2020 at 4:45 PM Segher Boessenkool wrote: > > On Fri, Nov 13, 2020 at 04:11:41PM -0800, Nick Desaulniers wrote: > > On Fri, Nov 13, 2020 at 3:49 PM Segher Boessenkool > > wrote: > > > On Fri, Nov 13, 2020 at 10:59:26AM -0800, Nick Desaulniers wrote: > > > > The `optimize` attribute is both non-portable across toolchains (he= nce > > > > this warning) > > > > > > Like *all* GCC extensions. > > > > > > > and a little quirky in GCC. > > > > > > How so? Don't spread FUD please, say what *is* wrong, then people can > > > decide for themselves whether they want it or not. > > > > Spread FUD? Ard literally sent TO YOU: > > https://lore.kernel.org/lkml/CAMj1kXHxX+u5-cN0v3SLdqZTSiKsWsFOvc2SC5=3D= -ScaUZOu8Ng(a)mail.gmail.com/, > > and it was referenced again in > > https://lore.kernel.org/lkml/20201028081123.GT2628(a)hirez.programming.= kicks-ass.net/. > > > > Was it FUD when Ard sent it to you? > > He didn't say "this option is a little quirky". He simply quoted our > wiki entry for it, which says "use this only for debugging" (just like > the user documentation btw). The FAQ also goes on to explain the > attribute is very hard to use, it is not obvious at all what flags you > can and cannot set, it's a user interface disaster. It explains what is > bad with it, it doesn't just say "ooh I don't understand it, do not use > it". (It does say "no one really understands it, do not use it", there > is that ;-) ) Are we splitting hairs here? I want both toolchains to be successful; though maybe next time I see something like this patch/0day report go by, I'll just keep my mouth shut and we can deal with the runtime bugs later? -- = Thanks, ~Nick Desaulniers --===============0045366968005964828==--