From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Thu, 26 Sep 2019 05:47:20 -0700 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ACDF53078A23; Thu, 26 Sep 2019 12:47:19 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-49.rdu2.redhat.com [10.10.120.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id A6B241001B20; Thu, 26 Sep 2019 12:47:18 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH 32/35] ShellPkg/UefiShellLib: clarify workaround for unfixable EdkShell bug From: "Laszlo Ersek" To: Jaben Carsey , Ray Ni , Zhichao Gao Cc: edk2-devel-groups-io Reply-To: devel@edk2.groups.io, lersek@redhat.com References: <20190917194935.24322-1-lersek@redhat.com> <20190917194935.24322-33-lersek@redhat.com> Message-ID: <4fc048a2-ccbd-7f32-a51b-bf065230d3f6@redhat.com> Date: Thu, 26 Sep 2019 14:47:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190917194935.24322-33-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Thu, 26 Sep 2019 12:47:19 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Jaben, Ray, Zhichao, can one of you guys please review this patch? Thanks Laszlo On 09/17/19 21:49, Laszlo Ersek wrote: > The EDK 1 Shell (available at ) > has a bug in its EFI_SHELL_ENVIRONMENT2.Execute() implementation that > edk2's UefiShellLib has no choice but to work around. > > Improve the explanation in the code. Also, document the implicit > EFI_HANDLE -> (EFI_HANDLE*) conversion, which happens implicitly after > dereferencing ParentHandle, with an explicit cast. > > In practice, this patch is a no-op. > > Cc: Jaben Carsey > Cc: Ray Ni > Cc: Zhichao Gao > Signed-off-by: Laszlo Ersek > --- > > Notes: > build-tested only > > ShellPkg/Library/UefiShellLib/UefiShellLib.c | 22 ++++++++++++++++++-- > 1 file changed, 20 insertions(+), 2 deletions(-) > > diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c b/ShellPkg/Library/UefiShellLib/UefiShellLib.c > index 835d0f88ca74..9f07a58eb23d 100644 > --- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c > +++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c > @@ -1291,9 +1291,27 @@ ShellExecute ( > if (mEfiShellEnvironment2 != NULL) { > // > // Call EFI Shell version. > - // Due to oddity in the EFI shell we want to dereference the ParentHandle here > // > - CmdStatus = (mEfiShellEnvironment2->Execute(*ParentHandle, > + // Due to an unfixable bug in the EdkShell implementation, we must > + // dereference "ParentHandle" here: > + // > + // 1. The EFI shell installs the EFI_SHELL_ENVIRONMENT2 protocol, > + // identified by gEfiShellEnvironment2Guid. > + // 2. The Execute() member function takes "ParentImageHandle" as first > + // parameter, with type (EFI_HANDLE*). > + // 3. In the EdkShell implementation, SEnvExecute() implements the > + // Execute() member function. It passes "ParentImageHandle" correctly to > + // SEnvDoExecute(). > + // 4. SEnvDoExecute() takes the (EFI_HANDLE*), and passes it directly -- > + // without de-referencing -- to the HandleProtocol() boot service. > + // 5. But HandleProtocol() takes an EFI_HANDLE. > + // > + // Therefore we must > + // - de-reference "ParentHandle" here, to mask the bug in > + // SEnvDoExecute(), and > + // - pass the resultant EFI_HANDLE as an (EFI_HANDLE*). > + // > + CmdStatus = (mEfiShellEnvironment2->Execute((EFI_HANDLE *)*ParentHandle, > CommandLine, > Output)); > // >