From: Borislav Petkov <bp@alien8.de>
To: Andy Lutomirski <luto@amacapital.net>
Cc: X86 ML <x86@kernel.org>, Jiri Kosina <jkosina@suse.cz>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] x86/vdso: Remove retpoline flags
Date: Wed, 31 Jan 2018 18:05:55 +0100 [thread overview]
Message-ID: <20180131170555.f6aboqitcvmgvhso@pd.tnic> (raw)
In-Reply-To: <CALCETrVsZWL7ZDnGMyoN8V4mmL5NO+SARQBV1U2OzrVscMsoig@mail.gmail.com>
On Wed, Jan 31, 2018 at 08:35:30AM -0800, Andy Lutomirski wrote:
> Hmm. I'm okay with this, but I'd also be okay doing nothing and
> figuring out WTF happened if an upstream kernel fails to build like
> this.
Oh sure, I'm sending it only as an FYI to show that something like this
*might* happen so that we're aware. I've taken it into our trees where
the 3.0 vdso code generates an indirect call to the thunk:
.loc 1 41 0
movq -10489696, %rax # MEM[(const struct vsyscall_gtod_data *)-10489728B].clock.vread, MEM[(const struct vsyscall_gtod_data *)-10489728B].clock.vread
call __x86_indirect_thunk_rax
Without the retpoline flags, the code looks like this:
170: 4c 8b 34 25 88 f0 5f mov 0xffffffffff5ff088,%r14
177: ff
178: 44 8b 2c 25 90 f0 5f mov 0xffffffffff5ff090,%r13d
17f: ff
180: ff 14 25 a0 f0 5f ff callq *0xffffffffff5ff0a0 <---
187: 4c 8b 0c 25 a8 f0 5f mov 0xffffffffff5ff0a8,%r9
18e: ff
18f: 4c 8b 04 25 b0 f0 5f mov 0xffffffffff5ff0b0,%r8
which is:
movl -10489712, %r12d # MEM[(const struct vsyscall_gtod_data *)-10489728B].wall_time_nsec,
.LVL46:
.LBB125:
.LBB126:
.loc 1 41 0
call *-10489696 # MEM[(const struct vsyscall_gtod_data *)-10489728B].clock.vread <---
.LVL47:
movq -10489688, %r9 # MEM[(const struct vsyscall_gtod_data *)-10489728B].clock.cycle_last, D.23457
movq -10489680, %r8 # MEM[(const struct vsyscall_gtod_data *)-10489728B].clock.mask, D.23457
notrace static inline long vgetns(void)
{
long v;
cycles_t (*vread)(void);
vread = gtod->clock.vread;
v = (vread() - gtod->clock.cycle_last) & gtod->clock.mask;
^^^^^^^^^^^^
so it has been converted to an absolute memory reference in that CALL -
nothing funky through a register.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
prev parent reply other threads:[~2018-01-31 17:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-31 16:33 Borislav Petkov
2018-01-31 16:35 ` Andy Lutomirski
2018-01-31 17:05 ` Borislav Petkov [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=20180131170555.f6aboqitcvmgvhso@pd.tnic \
--to=bp@alien8.de \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--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
all inboxes | Powered by JetHome®