[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200916081708.GK2674@hirez.programming.kicks-ass.net>
Date: Wed, 16 Sep 2020 10:17:08 +0200
From: peterz@...radead.org
To: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: Borislav Petkov <bp@...en8.de>, Roman Kiryanov <rkir@...gle.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Pavel Machek <pavel@....cz>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
linux-pm@...r.kernel.org, Greg KH <gregkh@...uxfoundation.org>,
Alistair Delva <adelva@...gle.com>,
Haitao Shan <hshan@...gle.com>,
lkml <linux-kernel@...r.kernel.org>,
Sami Tolvanen <samitolvanen@...gle.com>,
clang-built-linux <clang-built-linux@...glegroups.com>,
Martin Liška <mliska@...e.cz>
Subject: Re: [PATCH] arch: x86: power: cpu: init %gs before
__restore_processor_state (clang)
On Tue, Sep 15, 2020 at 12:51:47PM -0700, Nick Desaulniers wrote:
> It would be much nicer if we had the flexibility to disable stack
> protectors per function, rather than per translation unit. I'm going
> to encourage you to encourage your favorite compile vendor ("write to
> your senator") to support the function attribute
> __attribute__((no_stack_protector)) so that one day, we can use that
> to stop shipping crap like a9a3ed1eff360 ("x86: Fix early boot crash
> on gcc-10, third try").
I think we were all in favour of having that, not sure why it hasn't
happened yet. More important matters I suppose :/
Powered by blists - more mailing lists