Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1236064pxp; Thu, 17 Mar 2022 05:53:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxoHV9bp6eIDW/F9dadrNFvh6TTZfRA/WqTq5Y79dl5MAtSEM3s3DAZA7ufdG7+qUmIDJIY X-Received: by 2002:a17:903:2349:b0:153:9b0b:e481 with SMTP id c9-20020a170903234900b001539b0be481mr5097869plh.27.1647521636060; Thu, 17 Mar 2022 05:53:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647521636; cv=none; d=google.com; s=arc-20160816; b=oW0AHMM9LPvljhrLx8d/RjwqFalyK0s9PX6WWagPBvg7SG1SIkTrfcO+iUrCdgMCbI I5giSz2IYIKgJy1FmzLZUVnpqTP9Tnb919EjXxBtRaTVKxgglzNvxxj8BBq7y5rpOTk+ ZAVARTCcnsfS0IRHtlgmVOdxZOC4eQimkZwhUmFSxhw9hMh3bx5lFlZXnvpc/gQhe1aI umT9VdXQf8UywO9g3GWv0mTVfclnJ9rwzvKXyyt2h+qjpArKaj9Rv08cwpQmI1g6LMOe MAJeFwiixbAaDuyseHAEZQqp7lc/l9udUcHUy4kaNtVcO3MPAcow58R0tektTjTWRtHu MKNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=P3ZmMn1KaGWxf/LfBe/ecGMG/c1wdUNLz9y2FVgpg20=; b=ebaavyQTirWJUljObrSHSjXGbrZq6l3umKtmRkBqXyr4ga188WXhiJ9nOce3pTqsnf bFAWbA1vXPaiROq0e1sT1+mWthERlFE3Y4m1ddy38aWV86gpe7vBVeYm6grPuHPRFt1Z gTkvH7W6236CCfxhg76z38UV2lYzrfUuSKO/cyKSTqCi+6dcxg84N/I2kIzPwMmVGHsJ dkFOa9fu1a2xRxqPQSXxxfGwy9aGkNNAFZpcocZo6X+oY1MYf2CuumvgpOt4byF/SPza F98jcUJ2mVSh7O0f488qMFOtnEj98P4xrAAp6/Xbr0C97cRr2kCaTIjvjHCxOiV/xuYg UQiw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=laW1CWNV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g1-20020a63dd41000000b003816043efcfsi1967793pgj.452.2022.03.17.05.53.44; Thu, 17 Mar 2022 05:53:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=laW1CWNV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232753AbiCQKyA (ORCPT + 99 others); Thu, 17 Mar 2022 06:54:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231938AbiCQKx7 (ORCPT ); Thu, 17 Mar 2022 06:53:59 -0400 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E71761DFDC3; Thu, 17 Mar 2022 03:52:42 -0700 (PDT) Received: from zn.tnic (p200300ea971561b0329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9715:61b0:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 646241EC03AD; Thu, 17 Mar 2022 11:52:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1647514357; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=P3ZmMn1KaGWxf/LfBe/ecGMG/c1wdUNLz9y2FVgpg20=; b=laW1CWNVAha8zrGJGDRuywipSgVXY7W9p3AhKT0dB4y+Ehhok6AAXd05fygY4HXIAPCTBG vwRx+51hBBCzsdaXRhrLI2wRqPMoyW2V2B3NFrTOs4XOKC/S7H5KS5p9RSnnAr9Pndyp3T S8SyOWE0hTXe6UOcsuHvVFfrBLcgyDw= Date: Thu, 17 Mar 2022 11:52:33 +0100 From: Borislav Petkov To: Peter Zijlstra , Jamie Heilman Cc: linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, Paolo Bonzini , Sean Christopherson , kvm@vger.kernel.org Subject: [PATCH -v1.2] kvm/emulate: Fix SETcc emulation function offsets with SLS Message-ID: References: <20220316220201.GM8939@worktop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 17, 2022 at 10:37:56AM +0100, Borislav Petkov wrote: > Jamie, I'd appreciate testing this one too, pls, just in case. Here's a version against -rc8 - the previous one was against tip/master and had other contextual changes in it. --- From: Borislav Petkov The commit in Fixes started adding INT3 after RETs as a mitigation against straight-line speculation. The fastop SETcc implementation in kvm's insn emulator uses macro magic to generate all possible SETcc functions and to jump to them when emulating the respective instruction. However, it hardcodes the size and alignment of those functions to 4: a three-byte SETcc insn and a single-byte RET. BUT, with SLS, there's an INT3 that gets slapped after the RET, which brings the whole scheme out of alignment: 15: 0f 90 c0 seto %al 18: c3 ret 19: cc int3 1a: 0f 1f 00 nopl (%rax) 1d: 0f 91 c0 setno %al 20: c3 ret 21: cc int3 22: 0f 1f 00 nopl (%rax) 25: 0f 92 c0 setb %al 28: c3 ret 29: cc int3 and this explodes like this: int3: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 2435 Comm: qemu-system-x86 Not tainted 5.17.0-rc8-sls #1 Hardware name: Dell Inc. Precision WorkStation T3400 /0TP412, BIOS A14 04/30/2012 RIP: 0010:setc+0x5/0x8 [kvm] Code: 00 00 0f 1f 00 0f b6 05 43 24 06 00 c3 cc 0f 1f 80 00 00 00 00 0f 90 c0 c3 cc 0f 1f 00 0f 91 c0 c3 cc 0f 1f 00 0f 92 c0 c3 cc <0f> 1f 00 0f 93 c0 c3 cc 0f 1f 00 0f 94 c0 c3 cc 0f 1f 00 0f 95 c0 Call Trace: ? x86_emulate_insn [kvm] ? x86_emulate_instruction [kvm] ? vmx_handle_exit [kvm_intel] ? kvm_arch_vcpu_ioctl_run [kvm] ? kvm_vcpu_ioctl [kvm] ? __x64_sys_ioctl ? do_syscall_64+0x40/0xa0 ? entry_SYSCALL_64_after_hwframe+0x44/0xae Raise the alignment value when SLS is enabled and use a macro for that instead of hard-coding naked numbers. Fixes: e463a09af2f0 ("x86: Add straight-line-speculation mitigation") Reported-by: Jamie Heilman Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/YjGzJwjrvxg5YZ0Z@audible.transient.net --- arch/x86/kvm/emulate.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c index 5719d8cfdbd9..f321abb9a4a8 100644 --- a/arch/x86/kvm/emulate.c +++ b/arch/x86/kvm/emulate.c @@ -429,8 +429,11 @@ static int fastop(struct x86_emulate_ctxt *ctxt, fastop_t fop); FOP_END /* Special case for SETcc - 1 instruction per cc */ + +#define SETCC_ALIGN (4 * (1 + IS_ENABLED(CONFIG_SLS))) + #define FOP_SETCC(op) \ - ".align 4 \n\t" \ + ".align " __stringify(SETCC_ALIGN) " \n\t" \ ".type " #op ", @function \n\t" \ #op ": \n\t" \ #op " %al \n\t" \ @@ -1047,7 +1050,7 @@ static int em_bsr_c(struct x86_emulate_ctxt *ctxt) static __always_inline u8 test_cc(unsigned int condition, unsigned long flags) { u8 rc; - void (*fop)(void) = (void *)em_setcc + 4 * (condition & 0xf); + void (*fop)(void) = (void *)em_setcc + SETCC_ALIGN * (condition & 0xf); flags = (flags & EFLAGS_MASK) | X86_EFLAGS_IF; asm("push %[flags]; popf; " CALL_NOSPEC -- 2.29.2 -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette