From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by mx.groups.io with SMTP id smtpd.web11.2191.1631646068650118937 for ; Tue, 14 Sep 2021 12:01:08 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@google.com header.s=20210112 header.b=s4BJwpQy; spf=pass (domain: google.com, ip: 209.85.216.47, mailfrom: vannapurve@google.com) Received: by mail-pj1-f47.google.com with SMTP id t20so310389pju.5 for ; Tue, 14 Sep 2021 12:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2n+/UU+ZP0esOk7i3Ypb5X89ynCXa5Cbpub0rWpE/qs=; b=s4BJwpQyVyWH5CAsmHlTS6U2s853a0MFOdZACFqPVVvwrVzZ0radjz7Eedxe9CB2TY 12u4ioPKdpJmkp86xCq+zR32NtPB96nCBfvkjnMw7920kfV1LNoLyxXU75ccSWTkek/F iUKFlbJ4Yw8H4399chaQYpZLGvxz83H8vCriEW06VKhvAlLctKV8aN7tHwRJaHSygFIo 3XjiwZZeczW+lctUw32Yguh96ls8o5N3zeoPyv8xsnwyrlPLaqLhXpKFVciyEndvBGA4 mgwUN2o4flp4l5z3ps1I3hllFdmz9I3AdM8LqHr657AKnuTf2wJ8f4XotuTOn3TZN0tv BQ/Q== 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=2n+/UU+ZP0esOk7i3Ypb5X89ynCXa5Cbpub0rWpE/qs=; b=PkKe2sL0mgIC98PvhvxGDSuttzo8AZLyTGnWLf3A80pAd/NX1xKnDfxR1s4hGErxlH /5/Vu6wTIGHyowgERLgt5CKEX05eMnZsgtsW/xV2CADrcUr39jRNXXQAfnlg1xrPn1u0 O6t/Kr5pRtd1GsGCBoAMb89fU120tU73oZTlfvs8JakqgId8tulYH4ZH44kynBMUAnRo 4t9pp4Bjg6aFLGEXUsdDi4PY8olMpRRyLcMJkgoYyUPQmY+XxHGv/CymdHu8Sc/FoJjN DMfcAXW1Vp3YPWNgLIkOazIirUXZVHIDgXlRAshH3cv6SykZhpk6l4ddiqIGEAblM8ol QPXQ== X-Gm-Message-State: AOAM533UXgTeL0rLCPPZfkPQMk02bH5d5DGxn85AXvsfQTeN8TsF0h0S 3jWfSRgVrnxhV3zkTPRdw1QpODjIqfvA6FHxZcO5uHmwSQPzlA== X-Google-Smtp-Source: ABdhPJyUJGikMWJGLR+Wr8fDkqW9ReIr/+YKqRGM7DYQ+KAToeiOyYoDKYN57A+5Hdtkofknz/Pyb5B1fGbbn1kvBY8= X-Received: by 2002:a17:902:be0f:b0:13a:19b6:6870 with SMTP id r15-20020a170902be0f00b0013a19b66870mr16534691pls.64.1631646067549; Tue, 14 Sep 2021 12:01:07 -0700 (PDT) MIME-Version: 1.0 References: <2d085336-386b-8492-5f0e-ce9e0c49e8b6@amd.com> In-Reply-To: <2d085336-386b-8492-5f0e-ce9e0c49e8b6@amd.com> From: vannapurve@google.com Date: Wed, 15 Sep 2021 00:30:56 +0530 Message-ID: Subject: Re: [edk2-devel] [PATCH V6 1/1] OvmfPkg: Enable TDX in ResetVector To: devel@edk2.groups.io, Min Xu , brijesh.singh@amd.com Cc: Ard Biesheuvel , Jordan Justen , Gerd Hoffmann , Erdem Aktas , James Bottomley , Jiewen Yao , Tom Lendacky Content-Type: multipart/alternative; boundary="00000000000041d9e105cbf93405" --00000000000041d9e105cbf93405 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Min, Brijesh, Regarding: > diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm > ... > +%ifdef ARCH_IA32 > nop > nop > jmp EarlyBspInitReal16 > >+%else >+ >+ smsw ax We are having intermittent VM crashes with running this code in AMD-SEV enabled VMs. As per the AMD64 manual section 15.8.1, executing "smsw" instruction doesn't result in bit 63 being set in EXITINFO1 and KVM ends up emulating "smsw" instruction by trying to read encrypted guest VM memory as per the code . Since KVM tries to make sense of different random cipher texts in different boots, it seems to intermittently result in visible issues. Is this expected behavior or do we miss some configuration or patches that are recommended by AMD? Regards, Vishal On Tue, Sep 14, 2021 at 4:54 PM Brijesh Singh via groups.io wrote: > Hi Min, > > A quick question below. > > On 9/14/21 3:50 AM, Min Xu wrote: > > RFC=EF=BC=9A > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fbugzi= lla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3429&data=3D04%7C01%7Cbrijesh.s= ingh%40amd.com%7C2cca2f0a7fb44084da2b08d9775cb220%7C3dd8961fe4884e608e11a82= d994e183d%7C0%7C0%7C637672062275443867%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w= LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3D4= zfuIDvTGDNCt%2BD3u7uUR0n6hHDzv%2FI8NkqoUJhsx8Y%3D&reserved=3D0 > > > > Intel's Trust Domain Extensions (Intel TDX) refers to an Intel technolo= gy > > that extends Virtual Machines Extensions (VMX) and Multi-Key Total Memo= ry > > Encryption (MKTME) with a new kind of virutal machines guest called a > > Trust Domain (TD). A TD is desinged to run in a CPU mode that protects > the > > confidentiality of TD memory contents and the TD's CPU state from other > > software, including the hosting Virtual-Machine Monitor (VMM), unless > > explicitly shared by the TD itself. > > > > Note: Intel TDX is only available on X64, so the Tdx related changes ar= e > > in X64 path. In IA32 path, there may be null stub to make the build > > success. > > > > This patch includes below major changes. > > > > 1. Definition of BFV & CFV > > Tdx Virtual Firmware (TDVF) includes one Firmware Volume (FV) known > > as the Boot Firmware Volume (BFV). The FV format is defined in the > > UEFI Platform Initialization (PI) spec. BFV includes all TDVF component= s > > required during boot. > > > > TDVF also include a configuration firmware volume (CFV) that is separat= ed > > from the BFV. The reason is because the CFV is measured in RTMR, while > > the BFV is measured in MRTD. > > > > In practice BFV is the code part of Ovmf image (OVMF_CODE.fd). CFV is t= he > > vars part of Ovmf image (OVMF_VARS.fd). > > > > 2. PcdOvmfImageSizeInKb > > PcdOvmfImageSizeInKb indicates the size of Ovmf image. It is used to > > calculate the offset of TdxMetadata in ResetVectorVtf0.asm. > > In SEV-SNP v7 series, I implemented the metadata support. I did not see > a need for the PcdOvmfImageSizeInKB. Why do you need it? I think your > calculation below will not work if someone is using the OVMF_CODE.fd > instead of OVMF.fd. Have you tried booting with OVMF_CODE.fd ? > > thanks > > > > >=20 > > > --00000000000041d9e105cbf93405 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Min, Brijesh,

Regarding:
> diff --git a/Ovmf= Pkg/ResetVector/Ia16/ResetVectorVtf0.asm b/OvmfPkg/ResetVector/Ia16/ResetVe= ctorVtf0.asm
> ...
> +%ifdef ARCH_IA32
>=C2=A0 =C2=A0= =C2=A0nop
>=C2=A0 =C2=A0 =C2=A0nop
>=C2=A0 =C2=A0 =C2=A0jmp=C2= =A0 =C2=A0 =C2=A0EarlyBspInitReal16
>
>+%else
>+
>+= =C2=A0 =C2=A0=C2=A0smsw=C2= =A0 =C2=A0 ax

We are having= intermittent VM crashes with running this code in AMD-SEV enabled VMs. As = per the AMD64=C2=A0manual=C2=A0section 15.8.1, executing "s= msw" instruction=C2=A0doesn't result in bit 63 being set in EXITIN= FO1 and KVM ends up emulating "smsw" instruction by trying to rea= d encrypted guest VM memory as per the=C2=A0code. Since KVM tries to make sense of different random cipher te= xts in different boots, it seems to intermittently result in visible issues= .

Is this expected behavi= or or do we miss some configuration or patches that are recommended by AMD?=

Regards,
Vishal

On Tue, Sep 14, 2021 at 4:54 PM Brijesh Singh via groups.io <brijesh.singh=3Damd.com@groups.io> wrote:
Hi Min,

A quick question below.

On 9/14/21 3:50 AM, Min Xu wrote:
> RFC=EF=BC=9A https:= //nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fbugzilla.tian= ocore.org%2Fshow_bug.cgi%3Fid%3D3429&amp;data=3D04%7C01%7Cbrijesh.singh= %40amd.com%7C2cca2f0a7fb44084da2b08d9775cb220%7C3dd8961fe4884e608e11a82d994= e183d%7C0%7C0%7C637672062275443867%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw= MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3D4= zfuIDvTGDNCt%2BD3u7uUR0n6hHDzv%2FI8NkqoUJhsx8Y%3D&amp;reserved=3D0<= br> >
> Intel's Trust Domain Extensions (Intel TDX) refers to an Intel tec= hnology
> that extends Virtual Machines Extensions (VMX) and Multi-Key Total Mem= ory
> Encryption (MKTME) with a new kind of virutal machines guest called a<= br> > Trust Domain (TD). A TD is desinged to run in a CPU mode that protects= the
> confidentiality of TD memory contents and the TD's CPU state from = other
> software, including the hosting Virtual-Machine Monitor (VMM), unless<= br> > explicitly shared by the TD itself.
>
> Note: Intel TDX is only available on X64, so the Tdx related changes a= re
> in X64 path. In IA32 path, there may be null stub to make the build > success.
>
> This patch includes below major changes.
>
> 1. Definition of BFV & CFV
> Tdx Virtual Firmware (TDVF) includes one Firmware Volume (FV) known > as the Boot Firmware Volume (BFV). The FV format is defined in the
> UEFI Platform Initialization (PI) spec. BFV includes all TDVF componen= ts
> required during boot.
>
> TDVF also include a configuration firmware volume (CFV) that is separa= ted
> from the BFV. The reason is because the CFV is measured in RTMR, while=
> the BFV is measured in MRTD.
>
> In practice BFV is the code part of Ovmf image (OVMF_CODE.fd). CFV is = the
> vars part of Ovmf image (OVMF_VARS.fd).
>
> 2. PcdOvmfImageSizeInKb
> PcdOvmfImageSizeInKb indicates the size of Ovmf image. It is used to > calculate the offset of TdxMetadata in ResetVectorVtf0.asm.

In SEV-SNP v7 series, I implemented the metadata support. I did not see
a need for the PcdOvmfImageSizeInKB. Why do you need it? I think your
calculation below will not work if someone is using the OVMF_CODE.fd
instead of OVMF.fd. Have you tried booting with OVMF_CODE.fd ?

thanks







--00000000000041d9e105cbf93405--