From: Alexey Dobriyan <adobriyan@gmail.com>
To: Thomas Garnier <thgarnie@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v8 06/11] x86/CPU: Adapt assembly for PIE support
Date: Tue, 9 Jul 2019 21:39:21 +0300 [thread overview]
Message-ID: <20190709183921.GA27282@avx2> (raw)
In-Reply-To: <CAJcbSZELSRbcfPqE9DuBidM8stxY2DdjseSZgM_pCS1L3FEpcA@mail.gmail.com>
On Mon, Jul 08, 2019 at 12:35:13PM -0700, Thomas Garnier wrote:
> On Mon, Jul 8, 2019 at 12:09 PM Alexey Dobriyan <adobriyan@gmail.com> wrote:
> >
> > Thomas Garnier wrote:
> > > - "pushq $1f\n\t"
> > > + "movabsq $1f, %q0\n\t"
> > > + "pushq %q0\n\t"
> > > "iretq\n\t"
> > > UNWIND_HINT_RESTORE
> > > "1:"
> >
> > Fake PIE. True PIE looks like this:
>
> I used movabsq in couple assembly changes where the memory context is
> unclear and relative reference might lead to issues. It happened on
> early boot and hibernation save/restore paths. Do you think a relative
> reference in this function will always be accurate?
As long as iretq target is not too far it should be OK.
I'm not really sure which issues can pop up.
IRETQ is 64-bit only, RIP-relative addressing is 64-bit only.
Assembler (hopefully) will error compilation if target is too far.
And it is shorter than movabsq.
> > ffffffff81022d70 <do_sync_core>:
> > ffffffff81022d70: 8c d0 mov eax,ss
> > ffffffff81022d72: 50 push rax
> > ffffffff81022d73: 54 push rsp
> > ffffffff81022d74: 48 83 04 24 08 add QWORD PTR [rsp],0x8
> > ffffffff81022d79: 9c pushf
> > ffffffff81022d7a: 8c c8 mov eax,cs
> > ffffffff81022d7c: 50 push rax
> > ffffffff81022d7d: ===> 48 8d 05 03 00 00 00 lea rax,[rip+0x3] # ffffffff81022d87 <do_sync_core+0x17>
> > ffffffff81022d84: 50 push rax
> > ffffffff81022d85: 48 cf iretq
> > ffffffff81022d87: c3 ret
> >
> > Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> >
> > --- a/arch/x86/include/asm/processor.h
> > +++ b/arch/x86/include/asm/processor.h
> > @@ -710,7 +710,8 @@ static inline void sync_core(void)
> > "pushfq\n\t"
> > "mov %%cs, %0\n\t"
> > "pushq %q0\n\t"
> > - "pushq $1f\n\t"
> > + "leaq 1f(%%rip), %q0\n\t"
> > + "pushq %q0\n\t"
> > "iretq\n\t"
> > UNWIND_HINT_RESTORE
> > "1:"
next prev parent reply other threads:[~2019-07-09 18:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-08 19:09 [PATCH v8 06/11] x86/CPU: Adapt assembly for PIE support Alexey Dobriyan
2019-07-08 19:35 ` Thomas Garnier
2019-07-09 18:39 ` Alexey Dobriyan [this message]
2019-07-09 18:47 ` Thomas Garnier
-- strict thread matches above, loose matches on Subject: below --
2019-07-08 17:48 [PATCH v8 00/11] x86: PIE support to extend KASLR randomization Thomas Garnier
2019-07-08 17:48 ` [PATCH v8 06/11] x86/CPU: Adapt assembly for PIE support Thomas Garnier
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=20190709183921.GA27282@avx2 \
--to=adobriyan@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=thgarnie@chromium.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