public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Guo Dong" <guo.dong@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
	Laszlo Ersek <lersek@redhat.com>
Cc: "Dong, Eric" <eric.dong@intel.com>, "Ni, Ray" <ray.ni@intel.com>,
	"Kumar, Rahul1" <rahul1.kumar@intel.com>
Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg/CpuDxe: Fix boot error
Date: Thu, 10 Dec 2020 16:54:53 +0000	[thread overview]
Message-ID: <BYAPR11MB3622AE151C22681277C59C509ECB0@BYAPR11MB3622.namprd11.prod.outlook.com> (raw)
In-Reply-To: <d7d74e36-cabb-10e2-39db-a37ffab61076@amd.com>


> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Lendacky,
> Thomas
> Sent: Thursday, December 10, 2020 7:38 AM
> To: Laszlo Ersek <lersek@redhat.com>; devel@edk2.groups.io; Dong, Guo
> <guo.dong@intel.com>
> Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Kumar,
> Rahul1 <rahul1.kumar@intel.com>
> Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg/CpuDxe: Fix boot error
> 
> On 12/10/20 2:49 AM, Laszlo Ersek wrote:
> > On 12/09/20 21:02, Tom Lendacky wrote:
> >> On 12/2/20 3:38 PM, Guo Dong via groups.io wrote:
> >>> REF:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.t
> ianocore.org%2Fshow_bug.cgi%3Fid%3D3084&amp;data=04%7C01%7Cthomas.
> lendacky%40amd.com%7Ce2b6480c67df4f62e2ba08d89ce89aab%7C3dd8961fe
> 4884e608e11a82d994e183d%7C0%7C0%7C637431870560945022%7CUnknown
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> iLCJXVCI6Mn0%3D%7C1000&amp;sdata=OuvOcnWku0ct%2FHYebIVYoJ6vsqN%
> 2F56%2BMANNkvc%2BLW38%3D&amp;reserved=0
> >>>
> >>> When DXE drivers are dispatched above 4GB memory and
> >>> the system is already in 64bit mode, the address
> >>> setCodeSelectorLongJump in stack will be override
> >>> by parameter. so change to use 64bit address and
> >>> jump to qword address.
> >>
> >> This patch breaks AMD processors. AMD processors cannot do far jumps to
> >> 64-bit targets. Please see AMD APM Vol. 3 [1], JMP (Far), where it states:
> >>
> >> Target is a code segment — Control is transferred to the target CS:rIP. In
> >> this case, the target offset can only be a 16 or 32 bit value, depending
> >> on operand-size, and is zero-extended to 64 bits; 64-bit offsets are only
> >> available via call gates. No CPL change is allowed.
> >>
> >> [1]
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsupport.a
> md.com%2FTechDocs%2F24594.pdf&amp;data=04%7C01%7Cthomas.lendacky
> %40amd.com%7Ce2b6480c67df4f62e2ba08d89ce89aab%7C3dd8961fe4884e60
> 8e11a82d994e183d%7C0%7C0%7C637431870560945022%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C1000&amp;sdata=2rw8eZJNB5EgNR9JN87eWLgnHCYM0mWVJIp
> hSyrtmug%3D&amp;reserved=0
> >>
> >
> > Should we revert the patch, or predicate the change on something similar
> > to StandardSignatureIsAuthenticAMD()
> > [UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.c]? The CPUID check
> > could be open-coded in the assembly file. (Maybe there's a better
> > method, I'm not sure.)
> 
> I'm not sure what the best approach would be. Guo, thoughts?
> 

> If there aren't any plans to enable shadow stacks, I think you can
> accomplish the 64-bit support with a far ret instead of a far jmp. If
> shadow stack is enabled, then that becomes a problem when tracking stack
> usage through shadow stack.

[Guo] From my view point, it is not necessary to have these code for X64 since CS base
address would always use 0 in long mode. But I will leave this to package owner
to decide to remove it or not.
For now to support AMD case, maybe we could check rax value to decide to use
dword jump or qword jump. If high 4 bytes of rax is zero, dword jump will be used.
With this, it has exact same behavior when CpuDxe driver is dispatch below 4GB.

> 
> If more time is needed to figure it out, though, it is probably best to
> revert this in the mean time since I can't launch a VM (be it legacy or
> SEV) on the latest tree.

[Guo] If we agree the above change to check rax, I could create a patch today.
Let me know if having other comments.

> 
> Thanks,
> Tom
> 
> >
> > Thanks
> > Laszlo
> >
> >> Thanks,
> >> Tom
> >>
> >>>> Signed-off-by: Guo Dong <guo.dong@intel.com>
> >>> ---
> >>>   UefiCpuPkg/CpuDxe/X64/CpuAsm.nasm | 4 ++--
> >>>   1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/UefiCpuPkg/CpuDxe/X64/CpuAsm.nasm
> b/UefiCpuPkg/CpuDxe/X64/CpuAsm.nasm
> >>> index c3489bcc3e..6ad32b49f4 100644
> >>> --- a/UefiCpuPkg/CpuDxe/X64/CpuAsm.nasm
> >>> +++ b/UefiCpuPkg/CpuDxe/X64/CpuAsm.nasm
> >>> @@ -23,8 +23,8 @@ ASM_PFX(SetCodeSelector):
> >>>       sub     rsp, 0x10
> >>>       lea     rax, [setCodeSelectorLongJump]
> >>>       mov     [rsp], rax
> >>> -    mov     [rsp+4], cx
> >>> -    jmp     dword far [rsp]
> >>> +    mov     [rsp+8], cx
> >>> +    jmp     qword far [rsp]
> >>>   setCodeSelectorLongJump:
> >>>       add     rsp, 0x10
> >>>       ret
> >>>
> >>
> >
> 
> 
> 
> 


  reply	other threads:[~2020-12-10 16:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-02 21:38 [edk2-devel] [PATCH] UefiCpuPkg/CpuDxe: Fix boot error Guo Dong
2020-12-03  2:23 ` Ni, Ray
2020-12-03  7:08 ` Dong, Eric
2020-12-03 10:21 ` Laszlo Ersek
2020-12-08 21:39   ` Guo Dong
2020-12-09 20:02 ` Lendacky, Thomas
2020-12-10  8:49   ` Laszlo Ersek
2020-12-10 14:37     ` Lendacky, Thomas
2020-12-10 16:54       ` Guo Dong [this message]
2020-12-11  1:47         ` Ni, Ray
2020-12-11  3:11           ` Guo Dong
  -- strict thread matches above, loose matches on Subject: below --
2020-12-24 20:04 Guo Dong
2021-01-05  4:31 ` Michael D Kinney
2021-01-06  0:51   ` Guo Dong
2021-01-06  2:00     ` Michael D Kinney
2021-01-06 15:37       ` Laszlo Ersek
2021-01-06 14:25   ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BYAPR11MB3622AE151C22681277C59C509ECB0@BYAPR11MB3622.namprd11.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox