Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp711161imw; Thu, 14 Jul 2022 09:23:40 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vqM1NZoZ5lwKD9aXrK7LnfK92rQwec5656SImqK04qnGWKlVa9Df80tRmkgi/nbDhuyCQQ X-Received: by 2002:a63:194c:0:b0:408:a9d1:400c with SMTP id 12-20020a63194c000000b00408a9d1400cmr8388300pgz.559.1657815819969; Thu, 14 Jul 2022 09:23:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657815819; cv=none; d=google.com; s=arc-20160816; b=09K5xeRCStUAUjoo0oqEy2Er6/3nvM3REhrgTSsOv6IRw1My5+G7AwK/hQpE7b1o5+ d5NXBovI2+Pi7MJGrsFxrS9WaUvVVoa5cvZiNHaFLKiofepA2qcsdkco7EM2/J8K51SR 5MiDAGZzOUI+iz1xncizt2eTtU7ApUgfTvgQ4tegNz93VHnBbcUP0+rSidC+lOwve85U r8mWXQKIvM2Kmq37RB1jAcG+BwDzE28O22O89z30uRRFGnmVq9TeAblWxPjvUMIcHsGV YlJYoTW5IFHNilOlLdDuohg4zLJzejxUrJQyyZPrM4czDeupHV5KVc0j1RPmYrm1W3uO kC8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=govIWRa7qaOV2WIczJDqmAkYPYMG/67BzPW5XLlKyvc=; b=Rv4owlr9S6jaNOvzwPu1iojSmzUXGsKu37kUNIQPZ/m59yk0rWF4H5/UwCiwNoP+Zw b1GQMMiCbH2mr3yZBhgbkWttEi/vR6Zbp2Jq6Ydy/0NJ/++xrmh4lM4EcCrGkdxaOaWH CA+80RrvofvRN9Sm+5R307xn5hqnGnAQGVUalt05gutxJ+rA9NCGqUi+iUV0gH3YJweL bCaLJVsfuhHYfly0P8SN56rBOuJCpg3XsgWF8gME5b4VFu8pgVAtjcUV686bxxGGDZUs jreP0ZQSVr+HOwSu8/y3+VNDa7SaPO//7Xzmu6w5U259bAzknDjfQxQwya9MjDdgW9Ir Qwgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="wwHDSW/a"; 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=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y19-20020a056a00191300b00528cc4fc308si3111377pfi.268.2022.07.14.09.23.25; Thu, 14 Jul 2022 09:23:39 -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=@linaro.org header.s=google header.b="wwHDSW/a"; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238811AbiGNQPv (ORCPT + 99 others); Thu, 14 Jul 2022 12:15:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44758 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232196AbiGNQPs (ORCPT ); Thu, 14 Jul 2022 12:15:48 -0400 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7ED2E61732 for ; Thu, 14 Jul 2022 09:15:47 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id v12so3040786edc.10 for ; Thu, 14 Jul 2022 09:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=govIWRa7qaOV2WIczJDqmAkYPYMG/67BzPW5XLlKyvc=; b=wwHDSW/azHUQ/dXzI4ImC8W7hItZhAmo8R0SiTyuuX/fYrhKkvqv3mVUr49+xTpUby 9gn1VHxei66XkaRiu+VGyDuu4+GSld5MF8susPqmvURu8hnhGCXdUo/BSMSg3Tn4mab0 AKIfp2W1bZ2YyxjaxFIfgAd5n6K1A6LC7UBBV9i4Ugl4g4BRDBOaj0EhfiJZownauzkV D+G3ZVhCZ9g698PJnHdoBLJCRmrQ2gaHD6Xrnw+wNPHZ7OHRMzYFLtKfutecE6Ezemet ILPzTdfaIQqJnWCXVn8HJ1NVEnJ8gVhHdS4czxVUj2+zjzhKg/lV5mxsI1gQIL+KPwLY p/eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=govIWRa7qaOV2WIczJDqmAkYPYMG/67BzPW5XLlKyvc=; b=ZVyzia9I9xOh6MRghZS+m+DBCFoC0YKRB9wmjN9kZ4rzX7s86gckvRi8o+ATYwPEd1 tFbRShSCkWjVkrWgX8DHm8ykba6nAhc/XiWSXoklkQL0KroRkQDmzWFbgl+pKSfmCF26 NLoCuZtpwW939xJ1JbnYBcsr0Tte5hD3ey8+jYsGSK6y4CnulhPZ0QtGQDfccy1gPZYu zfZrrdvoS73hIOaHoDNfDjB+XX99F0ORfiW9/QZy3T39UJO3YEJ1JLKCkltJsb7Vzygp HuXepasCGJA4492H7+B+AkJpg06kNmxgf+H3FMWVViFTsTRF7uoLXQ9KPOmI0beKFoaB bTZA== X-Gm-Message-State: AJIora8yz0Vtj3pWiM/eBVRnJttoG0mWOcDuMhy47iQPxaZt1Q7FIgIw 9R2Y6x7Uj00D4dDPxQLKMohzZVO1DUb9YxrP9arBag== X-Received: by 2002:aa7:d5d7:0:b0:43a:6eda:464a with SMTP id d23-20020aa7d5d7000000b0043a6eda464amr13313083eds.193.1657815345955; Thu, 14 Jul 2022 09:15:45 -0700 (PDT) MIME-Version: 1.0 References: <20220713171241.184026-1-cascardo@canonical.com> <976510d2-c7ad-2108-27e0-4c3b82c210f1@redhat.com> In-Reply-To: <976510d2-c7ad-2108-27e0-4c3b82c210f1@redhat.com> From: Naresh Kamboju Date: Thu, 14 Jul 2022 21:45:34 +0530 Message-ID: Subject: Re: [PATCH] x86/kvm: fix FASTOP_SIZE when return thunks are enabled To: Paolo Bonzini Cc: Peter Zijlstra , Thadeu Lima de Souza Cascardo , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, stable@vger.kernel.org, Greg Kroah-Hartman , Borislav Petkov , Josh Poimboeuf , Linux Kernel Functional Testing Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, 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 Hi Paolo, On Thu, 14 Jul 2022 at 17:06, Paolo Bonzini wrote: > > On 7/14/22 11:52, Peter Zijlstra wrote: > > 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 > >> Cc: Peter Zijlstra (Intel) > >> Cc: Borislav Petkov > >> Cc: Josh Poimboeuf > >> Cc: Paolo Bonzini > >> Reported-by: Linux Kernel Functional Testing Tested-by: Linux Kernel Functional Testing > >> --- > >> 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? > > Yes, definitely. Applied with a small tweak to make FASTOP_LENGTH > more similar to SETCC_LENGTH: > > diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c > index db96bf7d1122..0a15b0fec6d9 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 (ENDBR_INSN_SIZE + 7 + 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); > > > Paolo Applied your patch and tested on top of the mainline kernel and tested kvm-unit-tests and reported kernel panic fixed. https://lkft.validation.linaro.org/scheduler/job/5284626 - Naresh