From: Peter Zijlstra <peterz@infradead.org>
To: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
x86@kernel.org, stable@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Naresh Kamboju <naresh.kamboju@linaro.org>,
Borislav Petkov <bp@suse.de>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Linux Kernel Functional Testing <lkft@linaro.org>
Subject: Re: [PATCH] x86/kvm: fix FASTOP_SIZE when return thunks are enabled
Date: Thu, 14 Jul 2022 11:52:49 +0200 [thread overview]
Message-ID: <Ys/ncSnSFEST4fgL@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20220713171241.184026-1-cascardo@canonical.com>
On Wed, Jul 13, 2022 at 02:12:41PM -0300, Thadeu Lima de Souza Cascardo wrote:
> The return thunk call makes the fastop functions larger, just like IBT
> does. Consider a 16-byte FASTOP_SIZE when CONFIG_RETHUNK is enabled.
>
> Otherwise, functions will be incorrectly aligned and when computing their
> position for differently sized operators, they will executed in the middle
> or end of a function, which may as well be an int3, leading to a crash
> like:
Bah.. I did the SETcc stuff, but then forgot about the FASTOP :/
af2e140f3420 ("x86/kvm: Fix SETcc emulation for return thunks")
> Fixes: aa3d480315ba ("x86: Use return-thunk in asm code")
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
> Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Josh Poimboeuf <jpoimboe@kernel.org>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
> ---
> arch/x86/kvm/emulate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
> index db96bf7d1122..d779eea1052e 100644
> --- a/arch/x86/kvm/emulate.c
> +++ b/arch/x86/kvm/emulate.c
> @@ -190,7 +190,7 @@
> #define X16(x...) X8(x), X8(x)
>
> #define NR_FASTOP (ilog2(sizeof(ulong)) + 1)
> -#define FASTOP_SIZE (8 * (1 + HAS_KERNEL_IBT))
> +#define FASTOP_SIZE (8 * (1 + (HAS_KERNEL_IBT | IS_ENABLED(CONFIG_RETHUNK))))
Would it make sense to do something like this instead?
---
arch/x86/kvm/emulate.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index db96bf7d1122..b4305d2dcc51 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -189,8 +189,12 @@
#define X8(x...) X4(x), X4(x)
#define X16(x...) X8(x), X8(x)
-#define NR_FASTOP (ilog2(sizeof(ulong)) + 1)
-#define FASTOP_SIZE (8 * (1 + HAS_KERNEL_IBT))
+#define NR_FASTOP (ilog2(sizeof(ulong)) + 1)
+#define RET_LENGTH (1 + (4 * IS_ENABLED(CONFIG_RETHUNK)) + \
+ IS_ENABLED(CONFIG_SLS))
+#define FASTOP_LENGTH (7 + ENDBR_INSN_SIZE + RET_LENGTH)
+#define FASTOP_SIZE (8 << ((FASTOP_LENGTH > 8) & 1) << ((FASTOP_LENGTH > 16) & 1))
+static_assert(FASTOP_LENGTH <= FASTOP_SIZE);
struct opcode {
u64 flags;
@@ -442,8 +446,6 @@ static int fastop(struct x86_emulate_ctxt *ctxt, fastop_t fop);
* RET | JMP __x86_return_thunk [1,5 bytes; CONFIG_RETHUNK]
* INT3 [1 byte; CONFIG_SLS]
*/
-#define RET_LENGTH (1 + (4 * IS_ENABLED(CONFIG_RETHUNK)) + \
- IS_ENABLED(CONFIG_SLS))
#define SETCC_LENGTH (ENDBR_INSN_SIZE + 3 + RET_LENGTH)
#define SETCC_ALIGN (4 << ((SETCC_LENGTH > 4) & 1) << ((SETCC_LENGTH > 8) & 1))
static_assert(SETCC_LENGTH <= SETCC_ALIGN);
next prev parent reply other threads:[~2022-07-14 9:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-13 17:12 [PATCH] x86/kvm: fix FASTOP_SIZE when return thunks are enabled Thadeu Lima de Souza Cascardo
2022-07-14 9:52 ` Peter Zijlstra [this message]
2022-07-14 11:36 ` Paolo Bonzini
2022-07-14 11:48 ` Greg Kroah-Hartman
2022-07-14 11:54 ` Borislav Petkov
2022-07-14 16:15 ` Naresh Kamboju
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=Ys/ncSnSFEST4fgL@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bp@suse.de \
--cc=cascardo@canonical.com \
--cc=gregkh@linuxfoundation.org \
--cc=jpoimboe@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkft@linaro.org \
--cc=naresh.kamboju@linaro.org \
--cc=pbonzini@redhat.com \
--cc=stable@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.