[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200918222531.GD7443@duo.ucw.cz>
Date: Sat, 19 Sep 2020 00:25:31 +0200
From: Pavel Machek <pavel@...x.de>
To: Roman Kiryanov <rkir@...gle.com>
Cc: Borislav Petkov <bp@...en8.de>, rjw@...ysocki.net,
Thomas Gleixner <tglx@...utronix.de>, mingo@...hat.com,
x86@...nel.org, linux-pm@...r.kernel.org,
Greg KH <gregkh@...uxfoundation.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Alistair Delva <adelva@...gle.com>,
Haitao Shan <hshan@...gle.com>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arch: x86: power: cpu: init %gs before
__restore_processor_state (clang)
On Tue 2020-09-15 11:36:13, Roman Kiryanov wrote:
> On Tue, Sep 15, 2020 at 11:27 AM Borislav Petkov <bp@...en8.de> wrote:
> > > I believe the kernel makes a questionable assumption on how clang
> > > uses registers (gs will not be used if stack protection is disabled).
> > > Both kernel and clang behaves unfortunate here.
> >
> > If the kernel is at fault here and this same thing happens with GCC,
> > sure, but this is a clang-specific fix.
>
> This is fair. Unfortunately I am not an x86 asm expert. I expect the proper
> fix should land into arch/x86/kernel/acpi/wakeup_64.S to init %gs
> (maybe some more registers) before "jmp restore_processor_state".
That would certainly be nicer / more acceptable solution than patch
being proposed here.
Code was written with assumption compiler random C code would not use
%gs. If that's no longer true, fixing it in wakeup_64.S _with comments
explaining what goes on_ might be solution.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)
Powered by blists - more mailing lists