From: Roman Kiryanov <rkir@google.com>
To: Pavel Machek <pavel@denx.de>
Cc: rjw@rjwysocki.net, Thomas Gleixner <tglx@linutronix.de>,
mingo@redhat.com, x86@kernel.org, linux-pm@vger.kernel.org,
Greg KH <gregkh@linuxfoundation.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Alistair Delva <adelva@google.com>,
Haitao Shan <hshan@google.com>
Subject: Re: [PATCH] arch: x86: power: cpu: init %gs before __restore_processor_state (clang)
Date: Tue, 15 Sep 2020 16:13:51 -0700 [thread overview]
Message-ID: <CAOGAQeow_EU-vhtBSXofdmj7Ys-=HcCBEkQ8riySk2MosNQyxA@mail.gmail.com> (raw)
In-Reply-To: <20200915221708.GA26453@duo.ucw.cz>
On Tue, Sep 15, 2020 at 3:17 PM Pavel Machek <pavel@denx.de> wrote:
> > When load_TR_desc and load_mm_ldt are inlined into
> > fix_processor_context due to LTO, they cause
> > fix_processor_context (or in this case __restore_processor_state,
> > as fix_processor_context was inlined into __restore_processor_state)
> > to access the stack canary through %gs, but before
> > __restore_processor_state has restored the previous value
> > of %gs properly. LLVM appears to be inlining functions with stack
> > protectors into functions compiled with -fno-stack-protector,
> > which is likely a bug in LLVM's inliner that needs to be fixed.
>
> That's rather ugly.
>
> Would it be easier to simply mark those functions as noinline or
> something like that?
Hi Pavel, thank you for looking.
Let's put it another way. Is it correct to assume %gs will not be
ever used by the compiler for its internal business if stack protection
is disabled? If this assumption is correct we should just fix the
compiler.
Regards,
Roman.
prev parent reply other threads:[~2020-09-15 23:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-15 17:26 [PATCH] arch: x86: power: cpu: init %gs before __restore_processor_state (clang) rkir
2020-09-15 17:46 ` Borislav Petkov
2020-09-15 17:57 ` Roman Kiryanov
2020-09-15 18:27 ` Borislav Petkov
2020-09-15 18:36 ` Roman Kiryanov
2020-09-15 18:52 ` Borislav Petkov
2020-09-15 18:55 ` Roman Kiryanov
2020-09-18 22:25 ` Pavel Machek
2020-09-21 23:28 ` Roman Kiryanov
2020-10-04 9:59 ` Pavel Machek
2020-09-15 18:00 ` Nick Desaulniers
2020-09-15 18:25 ` Borislav Petkov
2020-09-15 19:51 ` Nick Desaulniers
2020-09-15 20:20 ` Borislav Petkov
2020-09-15 21:49 ` Nick Desaulniers
2020-09-16 9:23 ` Borislav Petkov
2020-09-19 16:48 ` Pavel Machek
2020-09-16 8:17 ` peterz
2020-09-15 20:44 ` Arvind Sankar
2020-09-15 22:17 ` Pavel Machek
2020-09-15 22:21 ` Nick Desaulniers
2020-09-18 22:20 ` Pavel Machek
2020-09-15 23:13 ` Roman Kiryanov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOGAQeow_EU-vhtBSXofdmj7Ys-=HcCBEkQ8riySk2MosNQyxA@mail.gmail.com' \
--to=rkir@google.com \
--cc=adelva@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hshan@google.com \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=ndesaulniers@google.com \
--cc=pavel@denx.de \
--cc=rjw@rjwysocki.net \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).