From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web10.9025.1599119965578221408 for ; Thu, 03 Sep 2020 00:59:26 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=dXJ+Bf/9; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1599119964; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=G8ZiW6Othl0nqvuipvnYG1JL+5PWhWkmuGu+Bs0Bb2Y=; b=dXJ+Bf/9khN0yDK704ImX3/n42YYeq5XSJImcC3tgVPakV5XSEl28cKUlU5Fknt+R86VpW xYurcksVRRwfQxTn1og+4QJ5WJcaTW2HfNcaNa4mGzjSDjELOjD0AWB3DAPOARyK3ZIQLd v+mqGI1EgY1XRfa7vJzQ4f8cmysaHGI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-299-zMoStrRyNaqFLKGL7M3jSw-1; Thu, 03 Sep 2020 03:59:22 -0400 X-MC-Unique: zMoStrRyNaqFLKGL7M3jSw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7B91481CAFF; Thu, 3 Sep 2020 07:59:21 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-168.ams2.redhat.com [10.36.112.168]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8341219C71; Thu, 3 Sep 2020 07:59:20 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg/MpInitLib: Add check for CR3/GDT/IDT. To: "Dong, Eric" , "devel@edk2.groups.io" Cc: "Ni, Ray" References: <20200902004353.1515-1-eric.dong@intel.com> <75a0a10e-f303-304e-0a36-628a79116284@redhat.com> From: "Laszlo Ersek" Message-ID: <7d864273-b2f0-9899-5661-e70202b92941@redhat.com> Date: Thu, 3 Sep 2020 09:59:19 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0.002 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US On 09/03/20 03:47, Dong, Eric wrote: > Hi Laszlo, > > Thanks for your detail review and good comments, add my reply in > below. > > This issue was reported by tester. They use a shell application to do > the test. In the test, it first moves the page table to above 4G range > then calls StartUpThisAp to let AP run the test procedure. The system > will hang during the test. > > Add more comments in below inline. Thanks. Let me summarize my understanding: (1) During normal boot, and normal MP services PPI usage, and normal MP services protocol usage, there is no issue. (2) Right now, we have not identified the exact edk2 core modules and locations that are responsible for allocating the IDT / GDT / page tables. Nonetheless, the allocations are all placed in the 32-bit address space, and so there is no problem with AP startup, during normal usage (see point (1)). (3) There is a UEFI shell application that isn't more closely identified in this discussion. It first moves at least one of the IDT / GDT / page tables above 4GB, and then calls some member functions of the MP services protocol. This causes a hang, experienced during the execution of the UEFI shell application. (4) The present patch recognizes the issue in FillExchangeInfoData(), and returns an error. In the relevant use case (UEFI shell application), this causes the called MP services protocol member function to fail, synchronously. This means the application still doesn't work, but there is no hang at least. Is my understanding correct? If it is, then I have the following comments: - Please file a TianoCore BZ for this issue, and capture the use case in it (= UEFI shell application that changes the IDT / GDT / page tables base). Please feel free to copy parts of the above description, if you think that's useful. - I'm quite doubtful that the use case is valid, in the first place. A UEFI application is supposed to consume the services described in the UEFI specification. Messing with the page tables is something that a UEFI application should *not* do, in my opinion. Such page table manipulation is expected to interfere with various DXE drivers in the platform firmware. - Another comment on the UEFI shell application, and the present patch, is that their *combination* will still break ExitBootServices(). Assume that the patch is applied, and the UEFI shell application is invoked. The application now fails gracefully, and exits. Then we attempt to boot an OS (this is a valid thing to do). Because the application moved the IDT / GDT / page tables "out of range", MpInitChangeApLoopCallback() will do the wrong thing. - Most importantly: in MpInitLib, there is a *large* amount of call sites, and a large number of call paths that lead to WakeUpAP(), and ultimately to FillExchangeInfoData(). This means that changing the return type of FillExchangeInfoData() from VOID to EFI_STATUS has a "ripple effect" -- many call paths would have to deal with error checking, error propagation, and resource release (!!!) along those error paths. - For example, your current patch leaks resources in WakeUpAP(), when FillExchangeInfoData() fails -- see AllocateResetVector() and AllocateSevEsAPMemory(). - For another example, your current patch does not handle several WakeUpAP() call sites, such as the ones in ResetProcessorToIdleState() and CheckAllAPs(). Whereas in reality, from the applications point of view, we only need the MP services protocol member functions to fail cleanly. Therefore we should address this problem *early*; that is, *much less deep* in the call stack. I suggest the following: - introduce a feature PCD (default value FALSE) - modify the following functions in MpInitLib: - MpInitLibGetNumberOfProcessors - MpInitLibGetProcessorInfo - MpInitLibStartupAllAPs - MpInitLibStartupThisAP - MpInitLibSwitchBSP - MpInitLibEnableDisableAP - MpInitLibWhoAmI - each modified function should check the feature PCD *very early*. If the PCD is true, then the function should pre-emptively verify the IDT / GDT / root page table location. If any one of those objects is outside of the 32-bit address space, then the function should fail immediately. - We need to consider the event handlers in DxeMpInitLib: - CheckApsStatus() is not a problem, because the above short-circuits in the public MpInitLib functions will guarantee that "mStopCheckAllApsStatus" is always TRUE. - For exit-boot-services and legacy-boot, we need to modify MpInitChangeApLoopCallback() however. MpInitChangeApLoopCallback() should do the same as the above-listed functions (check the PCD, check the IDT / GDT / root page table), and if one of them is above 4GB, then MpInitChangeApLoopCallback() should hang *hard* -- call CpuDeadLoop() --, even in RELEASE builds. This is because the UEFI application in question makes OS boot impossible, so we should stop the system as early as we realize that. - Of course, I suggest a helper function to encapsulate the PCD check, and the GDT / IDT / CR3 checks. This will let most platforms ignore the special UEFI shell application use case (which I do feel is invalid). In addition, platforms that do want to handle this use case, can set the PCD to TRUE for the CpuDxe module *only* (so that CpuMpPei is not penalized). Finally, this approach keeps the code clean; long call paths to FillExchangeInfoData() are not made more complex. Thanks Laszlo