Message ID | 20230130135354.27674-1-kirill.shutemov@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp2190283wrn; Mon, 30 Jan 2023 05:56:46 -0800 (PST) X-Google-Smtp-Source: AMrXdXtEju0ZwsRItaFG1Ov8KZsdGGEcuhG9VpPBwB56z8kIbqrxSzWkzT5I1FCY0uKYE8qAEB+H X-Received: by 2002:a17:907:76b0:b0:7c0:d609:6f9b with SMTP id jw16-20020a17090776b000b007c0d6096f9bmr41956554ejc.27.1675087006108; Mon, 30 Jan 2023 05:56:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675087006; cv=none; d=google.com; s=arc-20160816; b=UkQ+2hi2uIgcswqd3RZMeVzvwuSGdoFshb5X0HAL5lbXBG86ftxL8lEu7F5fV/J0eQ V5EqQBEs8X5EOY+YneqOFI1TKNIWHwBvOdD5dwcxyHTXP9AJr++/yPO8KbV/traK52Fe DthW9rCY931bN7t6vcjxFI0SO+lkQGqTJpOJ3wBR4xvitGKH6D0BP6YfifvdY5+IDzCC ePW3HswixsQPqawofUK/WRGSGl4v2wziOu9kkKhBQiyXelTGu9olWZu4+FCv8q2HeweC IV9rwUl9y7bmIQie8MXjk6BeTlvb5/jA70d/Eh0soTcjvhhrIfMS5wqZ3Vm7IcxMVQRy sqaA== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=i9X2KuVPq1KiicaGG7V2DSF0qBg3uFNVz2VOecS3IOI=; b=gVHy0FZGMhT5FUus02PDRvxJTx0Y3tKbp2J3Tw7wTUOBs6Df/l3hIrUulxb/QWSPg8 TgDAYjnd/FmpYN8oa44cjCJYRXFBo+iZy2IjJN1mSy2N+BFArVJYBeVThhEWvhhfjffj ndmkEsdwZkke34Iy6+hv02dWu7uppJvvKnaVdk6FD5zZxcTA9jpl/EERA04yGAhg+kGE bXhnrQF/3iFcc0nMLyNapF50/O78qPx4ByvziiL7490gQ2BS9f3KlSOJvAcHmeUSrQMe PfMsp2hwroOI/2PbRvYBVnin+zw8MbPaCUzKD02FutlGpBm9J82iEIsyU0QftUlYUA39 BMPQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=e6UeKpwK; 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=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id uk6-20020a170907ca0600b00881984b0f41si7906455ejc.291.2023.01.30.05.56.22; Mon, 30 Jan 2023 05:56:46 -0800 (PST) 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=@intel.com header.s=Intel header.b=e6UeKpwK; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236158AbjA3Nyo (ORCPT <rfc822;n2h9z4@gmail.com> + 99 others); Mon, 30 Jan 2023 08:54:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33436 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236373AbjA3Nyl (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 30 Jan 2023 08:54:41 -0500 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83F2C39296 for <linux-kernel@vger.kernel.org>; Mon, 30 Jan 2023 05:54:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1675086879; x=1706622879; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=4DEGDkL+yrEmQwnOAwQuSEcBBMrH3SBUNGZ0BQPN+/Y=; b=e6UeKpwKg7UBVMvT8vambUPfHpCitPPqI9md2jL1iobEUH7s4IxyErIT m0Ex5QNIVVlfTd15cKUxX/elJJNj1fBBB54Q1+MQI9CbOnyxvGq9R1PKc IKgNh9A8WKpAoqzkARWksEShpRdy+1u3cA03QryPFjujPIdweaZxOGlFE +qhjqYyYgm1+rmNS17aGqcSnJyFRZmrrmyXu8CDipT3qF1PqFNyctSVi8 riLyxD4QMUwDSnYeK+rFdVthm+dJRbJJ2GUzLf5Et/8ldK6BD6ZOI6bhz k6a0ANA01PdGNIEWSB9wjm5oOkAYh8xsyGqoLTlf0CgIX1q9L+CVxsckd A==; X-IronPort-AV: E=McAfee;i="6500,9779,10606"; a="307903829" X-IronPort-AV: E=Sophos;i="5.97,258,1669104000"; d="scan'208";a="307903829" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jan 2023 05:54:38 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10606"; a="696405603" X-IronPort-AV: E=Sophos;i="5.97,258,1669104000"; d="scan'208";a="696405603" Received: from dhirceax-mobl1.ger.corp.intel.com (HELO box.shutemov.name) ([10.252.33.6]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jan 2023 05:54:35 -0800 Received: by box.shutemov.name (Postfix, from userid 1000) id D4F4710DF7D; Mon, 30 Jan 2023 16:54:31 +0300 (+03) From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> To: Dave Hansen <dave.hansen@intel.com>, Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org> Cc: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>, Thomas Gleixner <tglx@linutronix.de>, Elena Reshetova <elena.reshetova@intel.com>, x86@kernel.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, kernel test robot <lkp@intel.com>, Peter Zijlstra <peterz@infradead.org> Subject: [PATCH] x86/tdx: Do not corrupt frame-pointer in __tdx_hypercall() Date: Mon, 30 Jan 2023 16:53:54 +0300 Message-Id: <20230130135354.27674-1-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.39.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756456032228704250?= X-GMAIL-MSGID: =?utf-8?q?1756456032228704250?= |
Series |
x86/tdx: Do not corrupt frame-pointer in __tdx_hypercall()
|
|
Commit Message
Kirill A. Shutemov
Jan. 30, 2023, 1:53 p.m. UTC
If compiled with CONFIG_FRAME_POINTER=y, objtool in not happy that
__tdx_hypercall() messes up RBP.
objtool: __tdx_hypercall+0x7f: return with modified stack frame
Rework the function to store TDX_HCALL_ flags on stack instead of RBP.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Fixes: c30c4b2555ba ("x86/tdx: Refactor __tdx_hypercall() to allow pass down more arguments")
Link: https://lore.kernel.org/all/202301290255.buUBs99R-lkp@intel.com
Reported-by: kernel test robot <lkp@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
---
The patch is against tip/x86/tdx. tip/sched/core removes
TDX_HCALL_ISSUE_STI. The trird hunk of the patch is not relevant
after that.
---
arch/x86/coco/tdx/tdcall.S | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
Comments
On Mon, Jan 30, 2023 at 04:53:54PM +0300, Kirill A. Shutemov wrote: > If compiled with CONFIG_FRAME_POINTER=y, objtool in not happy that > __tdx_hypercall() messes up RBP. > > objtool: __tdx_hypercall+0x7f: return with modified stack frame > > Rework the function to store TDX_HCALL_ flags on stack instead of RBP. > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > Fixes: c30c4b2555ba ("x86/tdx: Refactor __tdx_hypercall() to allow pass down more arguments") > Link: https://lore.kernel.org/all/202301290255.buUBs99R-lkp@intel.com > Reported-by: kernel test robot <lkp@intel.com> > Cc: Peter Zijlstra <peterz@infradead.org> > --- > > The patch is against tip/x86/tdx. tip/sched/core removes > TDX_HCALL_ISSUE_STI. The trird hunk of the patch is not relevant > after that. Right, this should work. But it does leave me wondering, should we perhaps strive to completely remove the flags thing and move to __tdx_hypercall() and __tdx_hypercall_ret() or something? That is, simply have two different functions, one with and one without return data. It should be trivial to generate that without actual code duplication.
On Mon, Jan 30, 2023 at 04:53:54PM +0300, Kirill A. Shutemov wrote: > If compiled with CONFIG_FRAME_POINTER=y, objtool in not happy that > __tdx_hypercall() messes up RBP. > > objtool: __tdx_hypercall+0x7f: return with modified stack frame > > Rework the function to store TDX_HCALL_ flags on stack instead of RBP. Also, on IRC you mentioned that per TDX spec, BP is a valid argument register too and you were going to raise this and get it fixed, TDX hypercalls must not use BP to pass data.
On Tue, Jan 31, 2023 at 09:34:12AM +0100, Peter Zijlstra wrote: > On Mon, Jan 30, 2023 at 04:53:54PM +0300, Kirill A. Shutemov wrote: > > If compiled with CONFIG_FRAME_POINTER=y, objtool in not happy that > > __tdx_hypercall() messes up RBP. > > > > objtool: __tdx_hypercall+0x7f: return with modified stack frame > > > > Rework the function to store TDX_HCALL_ flags on stack instead of RBP. > > Also, on IRC you mentioned that per TDX spec, BP is a valid argument > register too and you were going to raise this and get it fixed, TDX > hypercalls must not use BP to pass data. I've raised the question yesterday. No progress so far. It will take time to get it into the public spec.
On Tue, Jan 31, 2023 at 09:32:37AM +0100, Peter Zijlstra wrote: > On Mon, Jan 30, 2023 at 04:53:54PM +0300, Kirill A. Shutemov wrote: > > If compiled with CONFIG_FRAME_POINTER=y, objtool in not happy that Oops, just noticed a typo. s/in/is/ > > __tdx_hypercall() messes up RBP. > > > > objtool: __tdx_hypercall+0x7f: return with modified stack frame > > > > Rework the function to store TDX_HCALL_ flags on stack instead of RBP. > > > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> > > Fixes: c30c4b2555ba ("x86/tdx: Refactor __tdx_hypercall() to allow pass down more arguments") > > Link: https://lore.kernel.org/all/202301290255.buUBs99R-lkp@intel.com > > Reported-by: kernel test robot <lkp@intel.com> > > Cc: Peter Zijlstra <peterz@infradead.org> > > --- > > > > The patch is against tip/x86/tdx. tip/sched/core removes > > TDX_HCALL_ISSUE_STI. The trird hunk of the patch is not relevant > > after that. > > Right, this should work. But it does leave me wondering, should we > perhaps strive to completely remove the flags thing and move to > __tdx_hypercall() and __tdx_hypercall_ret() or something? That is, > simply have two different functions, one with and one without return > data. > > It should be trivial to generate that without actual code duplication. Yeah, that's doable. I will give it a try. I guess on top this one (plus sched/core changes) should be.
On Tue, Jan 31, 2023 at 11:39:01AM +0300, Kirill A. Shutemov wrote: > On Tue, Jan 31, 2023 at 09:34:12AM +0100, Peter Zijlstra wrote: > > On Mon, Jan 30, 2023 at 04:53:54PM +0300, Kirill A. Shutemov wrote: > > > If compiled with CONFIG_FRAME_POINTER=y, objtool in not happy that > > > __tdx_hypercall() messes up RBP. > > > > > > objtool: __tdx_hypercall+0x7f: return with modified stack frame > > > > > > Rework the function to store TDX_HCALL_ flags on stack instead of RBP. > > > > Also, on IRC you mentioned that per TDX spec, BP is a valid argument > > register too and you were going to raise this and get it fixed, TDX > > hypercalls must not use BP to pass data. > > I've raised the question yesterday. No progress so far. It will take time > to get it into the public spec. Sure, just making sure it's not forgotten about. Thanks!
diff --git a/arch/x86/coco/tdx/tdcall.S b/arch/x86/coco/tdx/tdcall.S index 5da06d1a9ba3..2bd436a4790d 100644 --- a/arch/x86/coco/tdx/tdcall.S +++ b/arch/x86/coco/tdx/tdcall.S @@ -131,11 +131,10 @@ SYM_FUNC_START(__tdx_hypercall) push %r13 push %r12 push %rbx - push %rbp /* Free RDI and RSI to be used as TDVMCALL arguments */ movq %rdi, %rax - movq %rsi, %rbp + push %rsi /* Copy hypercall registers from arg struct: */ movq TDX_HYPERCALL_r8(%rax), %r8 @@ -168,7 +167,7 @@ SYM_FUNC_START(__tdx_hypercall) * HLT operation indefinitely. Since this is the not the desired * result, conditionally call STI before TDCALL. */ - testq $TDX_HCALL_ISSUE_STI, %rbp + testq $TDX_HCALL_ISSUE_STI, 8(%rsp) jz .Lskip_sti sti .Lskip_sti: @@ -188,7 +187,7 @@ SYM_FUNC_START(__tdx_hypercall) pop %rax /* Copy hypercall result registers to arg struct if needed */ - testq $TDX_HCALL_HAS_OUTPUT, %rbp + testq $TDX_HCALL_HAS_OUTPUT, (%rsp) jz .Lout movq %r8, TDX_HYPERCALL_r8(%rax) @@ -218,11 +217,12 @@ SYM_FUNC_START(__tdx_hypercall) xor %r10d, %r10d xor %r11d, %r11d xor %rdi, %rdi - xor %rsi, %rsi xor %rdx, %rdx + /* Remove TDX_HCALL_* flags from the stack */ + pop %rsi + /* Restore callee-saved GPRs as mandated by the x86_64 ABI */ - pop %rbp pop %rbx pop %r12 pop %r13