[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <go4cg77ig4lwdic7irxoodatzgrpx2xrmcurzsdlligcrw2i4e@cnrbbjxdtjso>
Date: Fri, 17 May 2024 20:01:58 +0300
From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Sean Christopherson <seanjc@...gle.com>,
Juergen Gross <jgross@...e.com>, linux-kernel@...r.kernel.org, x86@...nel.org,
linux-coco@...ts.linux.dev, Dave Hansen <dave.hansen@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] x86/kvm/tdx: Save %rbp in TDX_MODULE_CALL
On Fri, May 17, 2024 at 09:34:56AM -0700, Dave Hansen wrote:
> On 5/17/24 09:12, Sean Christopherson wrote:
> >> There's a feature in TDX module 1.5 that prevents RBP modification across
> >> TDH.VP.ENTER SEAMCALL. See NO_RBP_MOD in TDX Module 1.5 ABI spec.
> > LOL, "feature". How was clobbering RBP not treated as a bug? I'm party joking,
> > but also quite serious.
>
> I'm on the same page. It would have been far simpler for all involved
> to retroactively say that modifying RBP is against the rules and any
> module that does it is buggy. Get a new module if yours is buggy.
>
> I _believe_ the intent was to support guest/host combinations that used
> RBP for whatever reason. But I'm not sure such a combination exists or
> ever existed in practice.
There's a bug in EDK2. It specifies RBP in mask of registers to pass to
VMM. NO_RBP_MOD breaks it :/
--
Kiryl Shutsemau / Kirill A. Shutemov
Powered by blists - more mailing lists