From: "Michael Kelley (LINUX)" <mikelley@microsoft.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: KY Srinivasan <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
"wei.liu@kernel.org" <wei.liu@kernel.org>,
Dexuan Cui <decui@microsoft.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"bp@alien8.de" <bp@alien8.de>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH 1/1] x86/hyperv: Disable IBT when hypercall page lacks ENDBR instruction
Date: Fri, 21 Jul 2023 14:00:35 +0000 [thread overview]
Message-ID: <BYAPR21MB168878CCD076762A1EA58635D73FA@BYAPR21MB1688.namprd21.prod.outlook.com> (raw)
In-Reply-To: <20230721075848.GA3630545@hirez.programming.kicks-ass.net>
From: Peter Zijlstra <peterz@infradead.org> Sent: Friday, July 21, 2023 12:59 AM
>
> On Fri, Jul 21, 2023 at 12:41:35AM +0000, Michael Kelley (LINUX) wrote:
>
> > > Other than that, this seems fairly straight forward. One thing I
> > > wondered about; wouldn't it be possible to re-write the indirect
> > > hypercall thingies to a direct call? I mean, once we have the hypercall
> > > page mapped, the address is known right?
> >
> > Yes, the address is known. It does not change across things like
> > hibernation. But the indirect call instruction is part of an inline assembly
> > sequence, so the call instructions that need re-writing are scattered
> > throughout the code. There's also the SEV-SNP case from the
> > latest version of Tianyu Lan's patch set [1] where vmmcall may be used
> > instead, based on your recent enhancement for nested ALTERNATIVE.
> > Re-writing seems like that's more complexity than warranted for a
> > mostly interim situation until the Hyper-V patch is available and
> > users install it.
>
> Well, we have a lot of infrastructure for this already. Specifically
> this is very like the paravirt patching.
>
> Also, direct calls are both faster and have less speculation issues, so
> it might still be worth looking at.
>
> The way to do something like this would be:
>
>
> asm volatile (" ANNOTATE_RETPOLINE_SAFE \n\t"
> "1: call *hv_hypercall_page \n\t"
> ".pushsection .hv_call_sites \n\t"
> ".long 1b - . \n\t"
> ".popsection \n\t");
>
>
> And then (see alternative.c for many other examples):
>
>
> patch_hypercalls()
> {
> s32 *s;
>
> for (s = __hv_call_sites_begin; s < __hv_call_sites_end; s++) {
> void *addr = (void *)s + *s;
> struct insn insn;
>
> ret = insn_decode_kernel(&insn, addr);
> if (WARN_ON_ONCE(ret < 0))
> continue;
>
> /*
> * indirect call: ff 15 disp32
> * direct call: 2e e8 disp32
> */
> if (insn.length == 6 &&
> insn.opcode.bytes[0] == 0xFF &&
> X86_MODRM_REG(insn.modrm.bytes[0]) == 2) {
>
> /* verify it was calling hy_hypercall_page */
> if (WARN_ON_ONCE(addr + 6 + insn.displacement.value != &hv_hypercall_page))
> continue;
>
> /*
> * write a CS padded direct call -- assumes the
> * hypercall page is in the 2G immediate range
> * of the kernel text
Probably not true -- the hypercall page has a vmalloc address.
> */
> addr[0] = 0x2e; /* CS prefix */
> addr[1] = CALL_INSN_OPCODE;
> (s32 *)&Addr[2] = *hv_hypercall_page - (addr + 6);
> }
> }
> }
>
>
> See, easy :-)
OK, worth looking into. This is a corner of the Linux kernel code that
I've never looked at before. I appreciate the pointers.
Hypercall sites also exist in loadable modules, so would need to hook
into module_finalize() as well. Processing a new section type looks
straightforward.
But altogether, this feels like more change than should go as a bug
fix to be backported to stable kernels. It's something to look at for a
future kernel release.
Michael
next prev parent reply other threads:[~2023-07-21 14:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-20 20:33 [PATCH 1/1] x86/hyperv: Disable IBT when hypercall page lacks ENDBR instruction Michael Kelley
2023-07-20 21:15 ` Peter Zijlstra
2023-07-21 0:41 ` Michael Kelley (LINUX)
2023-07-21 7:58 ` Peter Zijlstra
2023-07-21 14:00 ` Michael Kelley (LINUX) [this message]
2023-07-21 18:49 ` Peter Zijlstra
2023-07-21 14:05 ` Michael Kelley (LINUX)
2023-07-21 14:07 ` David Laight
2023-07-21 14:21 ` Michael Kelley (LINUX)
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=BYAPR21MB168878CCD076762A1EA58635D73FA@BYAPR21MB1688.namprd21.prod.outlook.com \
--to=mikelley@microsoft.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=wei.liu@kernel.org \
--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).