Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp4704682imw; Tue, 12 Jul 2022 12:44:05 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uasKw/wOt+Ecr0QAaF7HUILgRyzE30e0kUo5EyAzlkeCrzV8Tr0MYlzDPx4oHTdOVzHALH X-Received: by 2002:a05:6402:254c:b0:43a:9e77:3b29 with SMTP id l12-20020a056402254c00b0043a9e773b29mr33837434edb.356.1657655045615; Tue, 12 Jul 2022 12:44:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657655045; cv=none; d=google.com; s=arc-20160816; b=A22y4ExL2I1E0ZG7ueO85mgbw9E8aXuWfugVWIdbXCApaKEu+cRD7oRuLaalgjRJyR vVMu9vcsrxe2zBBykNwP17PE3wmjauwrWAXGuWA9xWthTBbyzgMGh8EfzKnDxMl0ts/Y svg1yEuUrppAgAarz4IBmoWjL0BIr4leUZVyGfw4E4caAb7pn7O5ghxHw0nSmLLz+SOx Ga4BK3IBtBJm+uvCvDzHKGQB2Td/dreOzqbwKf+YhBGZ5FOOGbv0+OLLaw3Y7Rk+W74n cgqw9RmcXNbBzeVbhQNf6uyH0bPeFT/KAmsMPb99yBPJQwh6RZYvMHvX9dC/5HIXEVVU zTDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=rvpuCdbexO3tioib/ZCRZCwoJWeFGHTZdDNmB6FHOo8=; b=TnoJtVC3z4tNmX8NuVxgzg1HL5PhqIag4VJ5XETV0oP+nj7mr0nhQz/KuAf7ipVxUw kmtq0M1eESi3lH7jx2wjIU6bXmP8+h/ebnsU/f+B+HFGZfT38tC0erKMDAqfqmk4lVAB YH4i1AP90INP8OM0QN7MyGEXz/p3tcVAfb+ecYeeQk+wd0Xz/1+qX5WaXK+ZjOhVrLj2 28uz1Vp7HOFPuWDJ2BeFUi6UpbHIFvIZQaAYSZkrOSY4TuvwzW97PFi8AmxqLU3uofxI Czc8F3BpbGkoTAAddc4O/gLeXE6cgta6EoXHG8/B7/CTvfp2c/0U0HLwZ/B6jYGoJw3o ugIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=YvfDheeq; 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=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n11-20020aa7c44b000000b0043a6e950e3asi14405441edr.212.2022.07.12.12.43.40; Tue, 12 Jul 2022 12:44:05 -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=@linuxfoundation.org header.s=korg header.b=YvfDheeq; 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=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234507AbiGLStv (ORCPT + 99 others); Tue, 12 Jul 2022 14:49:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45896 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234624AbiGLStX (ORCPT ); Tue, 12 Jul 2022 14:49:23 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D70BBF5C; Tue, 12 Jul 2022 11:43:51 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9EF9961AC7; Tue, 12 Jul 2022 18:43:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89A53C341C8; Tue, 12 Jul 2022 18:43:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1657651414; bh=NTrzfJvQ19VyAP61TafzQNav55FmjRegdN7rwksTswA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YvfDheeqFX2G24cd0mlr/ijF0rd6b1r0SZf1Zmn85Dhgr8stCzAS+MMDIEXZExGXQ kJVzk1LegN9jJNvbN7wH8VOhbXgSweFXLJAooVpJ51mMnbD2J4Eym8Tmwj+yJtn72L 1JtJUWr+lTsepFmXlfkOAC9+z+zFwLOs0rlS0QhQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jamie Heilman , Borislav Petkov , "Peter Zijlstra (Intel)" , Paolo Bonzini , Sasha Levin , Ben Hutchings Subject: [PATCH 5.10 068/130] kvm/emulate: Fix SETcc emulation function offsets with SLS Date: Tue, 12 Jul 2022 20:38:34 +0200 Message-Id: <20220712183249.603144005@linuxfoundation.org> X-Mailer: git-send-email 2.37.0 In-Reply-To: <20220712183246.394947160@linuxfoundation.org> References: <20220712183246.394947160@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, 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 From: Borislav Petkov commit fe83f5eae432ccc8e90082d6ed506d5233547473 upstream. 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 ? entry_SYSCALL_64_after_hwframe 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 Acked-by: Peter Zijlstra (Intel) Tested-by: Jamie Heilman Link: https://lore.kernel.org/r/YjGzJwjrvxg5YZ0Z@audible.transient.net [Add a comment and a bit of safety checking, since this is going to be changed again for IBT support. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman --- arch/x86/kvm/emulate.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) --- a/arch/x86/kvm/emulate.c +++ b/arch/x86/kvm/emulate.c @@ -428,8 +428,23 @@ static int fastop(struct x86_emulate_ctx FOP_END /* Special case for SETcc - 1 instruction per cc */ + +/* + * Depending on .config the SETcc functions look like: + * + * SETcc %al [3 bytes] + * RET [1 byte] + * INT3 [1 byte; CONFIG_SLS] + * + * Which gives possible sizes 4 or 5. When rounded up to the + * next power-of-two alignment they become 4 or 8. + */ +#define SETCC_LENGTH (4 + IS_ENABLED(CONFIG_SLS)) +#define SETCC_ALIGN (4 << IS_ENABLED(CONFIG_SLS)) +static_assert(SETCC_LENGTH <= SETCC_ALIGN); + #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" \ @@ -1055,7 +1070,7 @@ static int em_bsr_c(struct x86_emulate_c 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