Date   

Re: Enable debug prints to be seen on runtime?

Laszlo Ersek
 

On 05/21/20 22:23, mzktsn@gmail.com wrote:
Hello, i have recent compiled edk2 source for a specific board,
flashed the BIOS and everything worked correct.
I was wondering how to enable runtime
EDK2 DEBUG() prints on my board, and if it is possible to see the output using only my board's serial or
it is needing an external computer to be able to see the runtime print-outs?
Something similar as one can see when using an OVMF emulation on qemu.
You need the following for runtime DEBUGs:

(a) hardware that is not touched by the OS in *any way* at runtime, and

(b) one of:

(b1) the serial hardware to be IO-port based, and a matching
SerialPortLib instance to be linked into your runtime drivers, or

(b2) the serial hardware to be MMIO based, and a matching SerialPortLib
instance that registers the MMIO register block for runtime mapping
(similarly to MarkIoMemoryRangeForRuntimeAccess() in OvmfPkg), and also
reacts to SetVirtualAddressMap.

In the case of QEMU, it's (a) + (b1); the QEMU debug console is not
touched by the OS, and it is a plain IO port, which is not affected by
paging.

The IO port(s) in (b1), and the MMIO reg block in (b2), are board-specific.

Thanks,
Laszlo


Enable debug prints to be seen on runtime?

mzktsn@...
 

Hello, i have recent compiled edk2 source for a specific board,
flashed the BIOS and everything worked correct.
I was wondering how to enable runtime
EDK2 DEBUG() prints on my board, and if it is possible to see the output using only my board's serial or
it is needing an external computer to be able to see the runtime print-outs?
Something similar as one can see when using an OVMF emulation on qemu.

Thanks.


I want to know when bug 2215 will be fixed

wenyi,xie
 

Hello,I want to know when bug2215 will be fixed. And will this fix merge into release 202005?
bug2215 DxeImageVerificationHandler integer overflow leads to endless loop


Re: Using PKCS7 API in PEI Phase

Guomin Jiang
 

Is is important to check the implement, Can you make sure that there are same between PEI and DXE?

Below is the definition and implement about d2i_PKCS7, can you study first?
DECLARE_ASN1_FUNCTIONS(PKCS7)
IMPLEMENT_ASN1_FUNCTIONS(PKCS7)

I am busy recently until August, so I can only give you the key point.

From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Sukerkar, Amol N
Sent: Thursday, April 30, 2020 6:01 AM
To: discuss@edk2.groups.io
Cc: Sukerkar, Amol N <amol.n.sukerkar@intel.com>
Subject: [edk2-discuss] Using PKCS7 API in PEI Phase

Hello,

I am trying to use PKCS7 verification mechanism in PEI phase. Calling d2i_PKCS7 returns NULL in PEI phase (Cache As RAM). However, d2i_PKCS7 is successful when called in DXE phase.

Any idea what might be the issue?

Thanks,
Amol


Re: Memory Leaks observed in PCI IO Protocol

Laszlo Ersek
 

On 05/20/20 10:37, Sandeep Dhanvada wrote:
Hi,

I am using edk2(commit id: 0f1946b) with X64 ARCH, GCC49 toolchain and using PCI IO Protocol functions for memory Allocation/Map and Free/Unmap.

As per our NIC driver requirement, there is a need of 1600 bytes(MTU) of allocated memory for 6KB depth of descriptors pre-allocated at initialization and freed at unload. I am observing memory leak while continuously performing load and unload iterations of driver from UEFI Shell.

I simulated this in OVMF with PCI passthrough and observed leaks in this case also. Attached is the SampleDriver which uses PCI IO Protocol which Allocates and Maps memory while initialization and will Free and Unmap in unload path. In OVMF case, 12KB memory is leaked after every load unload iteration of Sample Driver.

Not sure if this expected behavior or indeed a memory leak.
The test program you have included suffers from both resource leaks and
double-free's. That means undefined behavior. See below.




pci_io_template_driver.patch


diff --git a/MdeModulePkg/Application/SampleDriver/SampleDriver.c b/MdeModulePkg/Application/SampleDriver/SampleDriver.c
new file mode 100755
index 0000000..a5a4db2
--- /dev/null
+++ b/MdeModulePkg/Application/SampleDriver/SampleDriver.c
@@ -0,0 +1,226 @@
+#include <Uefi.h>
+#include <Protocol/DriverBinding.h>
+#include <Protocol/ComponentName2.h>
+#include <Protocol/ComponentName.h>
+#include <Protocol/PciIo.h>
+#include <Library/UefiLib.h>
+#include <Library/UefiBootServicesTableLib.h>
+#include <Library/MemoryAllocationLib.h>
+#include <Library/DebugLib.h>
+#include <Library/BaseLib.h>
+#include <Uefi/UefiBaseType.h>
+
+#define VERSION 0x10
+
+EFI_STATUS
+EFIAPI
+Supported(
+ IN EFI_DRIVER_BINDING_PROTOCOL *This,
+ IN EFI_HANDLE ControllerHandle,
+ IN EFI_DEVICE_PATH_PROTOCOL *RemainingDevicePath OPTIONAL
+ )
+{
+ EFI_PCI_IO_PROTOCOL *PciIo = NULL;
+ EFI_STATUS Status = gBS->HandleProtocol(ControllerHandle,
+ &gEfiPciIoProtocolGuid,
+ (VOID **) &PciIo);
+
+ if (EFI_ERROR(Status))
+ return EFI_UNSUPPORTED;
+
+ return EFI_SUCCESS;
+}
Your test driver claims to support (i.e., claims the ability to drive)
any PCI device whatsoever (any handle with a PciIo protocol interface on
it). But:

+
+EFI_PCI_IO_PROTOCOL *PciIo;
+VOID *PciBuf[SIZE_2KB * 3];
+VOID *Mapping[SIZE_2KB * 3];
+UINTN pages[SIZE_2KB * 3];
+EFI_PHYSICAL_ADDRESS DmaAddr[SIZE_2KB * 3];
you gave all of these objects static storage duration. Then,

+
+EFI_STATUS
+EFIAPI
+Start(
+ IN EFI_DRIVER_BINDING_PROTOCOL *This,
+ IN EFI_HANDLE ControllerHandle,
+ IN EFI_DEVICE_PATH_PROTOCOL *RemainingDevicePath OPTIONAL
+ )
+{
+ UINTN i = 0;
+ EFI_STATUS Status = gBS->OpenProtocol(ControllerHandle,
+ &gEfiPciIoProtocolGuid,
+ (VOID **) &PciIo,
+ This->DriverBindingHandle,
+ ControllerHandle,
+ EFI_OPEN_PROTOCOL_BY_DRIVER);
+ if (EFI_ERROR(Status))
+ return Status;
your driver will bind any handle with a PciIo that is not yet
open-by-a-driver. And then,

+ for (i=0; i < (SIZE_2KB*3) ; i++)
+ {
+ pages[i] = EFI_SIZE_TO_PAGES(1600);
+ Status = PciIo->AllocateBuffer(PciIo, 0,
+ EfiBootServicesData,
+ pages[i],
+ &PciBuf[i], 0);
+ UINTN MappedSize = 1600;
+ Status = PciIo->Map(PciIo, EfiPciIoOperationBusMasterCommonBuffer,
+ PciBuf[i], &MappedSize, &DmaAddr[i], &Mapping[i]);
+ }
the 2nd, 3rd, 4th etc time this loop runs (for the 2nd, 3rd, 4th ...
handle that Start() binds), you leak previously allocated resources,
namely those referenced in PciBuf and Mapping.

+ return EFI_SUCCESS;
+}
+
+EFI_STATUS
+EFIAPI
+Stop(
+ IN EFI_DRIVER_BINDING_PROTOCOL *This,
+ IN EFI_HANDLE ControllerHandle,
+ IN UINTN NumberOfChildren,
+ IN EFI_HANDLE *ChildHandleBuffer OPTIONAL
+ )
+{
+ UINTN i = 0;
+ AsciiPrint("Unload PCI test Driver\n");
+ for (i=0; i < (SIZE_2KB*3) ; i++)
+ {
+ PciIo->Unmap(PciIo, Mapping[i]);
+ PciIo->FreeBuffer(PciIo, pages[i], PciBuf[i]);
+ }
And the 2nd, 3rd, 4th etc time this loop runs (for the 2nd, 3rd, 4th...
handle that Stop() unbinds), the Unmap() and FreeBuffer() calls attempt
to release garbage (already released resources).

General hint: whenever in doubt about resource lifecycles, debug-log the
address(es) returned on the allocation path, and debug-log the
address(es) freed on the release path. Equipped with such a text file,
you can use "sort" or other utilities to couple alloc & free actions,
and to detect mismatches.

Thanks
Laszlo

+
+ return gBS->CloseProtocol(ControllerHandle,
+ &gEfiPciIoProtocolGuid,
+ This->DriverBindingHandle,
+ ControllerHandle);
+}
+
+EFI_DRIVER_BINDING_PROTOCOL gDriverBinding = {
+ Supported,
+ Start,
+ Stop,
+ VERSION,
+ NULL,
+ NULL
+};
+
+EFI_STATUS
+EFIAPI
+GetDriverName (
+ IN EFI_COMPONENT_NAME2_PROTOCOL *This,
+ IN CHAR8 *Language,
+ OUT CHAR16 **DriverName
+ )
+{
+ StrCpyS(*DriverName, 14, L"Sample Driver");
+ return EFI_SUCCESS;
+}
+
+EFI_STATUS
+EFIAPI
+GetControllerName(
+ IN EFI_COMPONENT_NAME2_PROTOCOL *This,
+ IN EFI_HANDLE ControllerHandle,
+ IN EFI_HANDLE ChildHandle OPTIONAL,
+ IN CHAR8 *Language,
+ OUT CHAR16 **ControllerName
+ )
+{
+ return EFI_SUCCESS;
+}
+
+GLOBAL_REMOVE_IF_UNREFERENCED
+EFI_COMPONENT_NAME_PROTOCOL gComponentName = {
+ (EFI_COMPONENT_NAME_GET_DRIVER_NAME) GetDriverName,
+ (EFI_COMPONENT_NAME_GET_CONTROLLER_NAME) GetControllerName,
+ "eng"
+};
+
+GLOBAL_REMOVE_IF_UNREFERENCED
+EFI_COMPONENT_NAME2_PROTOCOL gComponentName2 = {
+ GetDriverName,
+ GetControllerName,
+ "en"
+};
+
+EFI_STATUS EFIAPI
+Unload (
+ IN EFI_HANDLE ImageHandle
+ )
+{
+ EFI_STATUS Status;
+ EFI_HANDLE *HandleBuffer;
+ UINTN HandleCount;
+ UINTN Index;
+
+
+ //
+ // Retrieve array of all handles in the handle database
+ //
+ Status = gBS->LocateHandleBuffer (
+ AllHandles,
+ NULL,
+ NULL,
+ &HandleCount,
+ &HandleBuffer
+ );
+ if (EFI_ERROR (Status)) {
+ return Status;
+ }
+
+ //
+ // Disconnect the current driver from handles in the handle database
+ //
+ for (Index = 0;
+ Index < HandleCount; Index++) {
+ Status = gBS->DisconnectController (
+ HandleBuffer[Index],
+ gImageHandle,
+ NULL
+ );
+ }
+
+ //
+ // Free the array of handles
+ //
+ FreePool (HandleBuffer);
+
+ //
+ // Uninstall protocols installed in the driver entry point
+ //
+ Status = EfiLibUninstallDriverBindingComponentName2 (
+ &gDriverBinding,
+ &gComponentName,
+ &gComponentName2
+ );
+ if (EFI_ERROR (Status)) {
+ return Status;
+ }
+
+ //
+ // Do any additional cleanup that is required for this driver
+ //
+
+ return EFI_SUCCESS;
+}
+
+EFI_STATUS
+EFIAPI
+EntryPoint (
+ IN EFI_HANDLE ImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ EFI_STATUS Status;
+
+ //
+ // Install driver model protocol(s).
+ //
+ Status = EfiLibInstallDriverBindingComponentName2 (
+ ImageHandle, // ImageHandle
+ SystemTable, // SystemTable
+ &gDriverBinding, // DriverBinding
+ ImageHandle, // DriverBindingHandle
+ &gComponentName, // ComponentName
+ &gComponentName2 // ComponentName2
+ );
+ ASSERT_EFI_ERROR (Status);
+
+ return Status;
+}
diff --git a/MdeModulePkg/Application/SampleDriver/SampleDriver.inf b/MdeModulePkg/Application/SampleDriver/SampleDriver.inf
new file mode 100755
index 0000000..cf34e05
--- /dev/null
+++ b/MdeModulePkg/Application/SampleDriver/SampleDriver.inf
@@ -0,0 +1,24 @@
+[Defines]
+ INF_VERSION = 0x00010005
+ BASE_NAME = TestPciIoDriver
+ FILE_GUID = DA87D340-15C0-4824-9BF3-D52286674BEF
+ MODULE_TYPE = UEFI_DRIVER
+ VERSION_STRING = 1.0
+ ENTRY_POINT = EntryPoint
+ UNLOAD_IMAGE = Unload
+
+[Sources]
+ SampleDriver.c
+
+[Packages]
+ MdePkg/MdePkg.dec
+
+[Protocols]
+ gEfiPciIoProtocolGuid
+
+[LibraryClasses]
+ UefiDriverEntryPoint
+ UefiBootServicesTableLib
+ UefiLib
+ DebugLib
+ MemoryAllocationLib
diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 25aea3e..7e78335 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -205,6 +205,7 @@
[Components]
MdeModulePkg/Application/HelloWorld/HelloWorld.inf
MdeModulePkg/Application/DumpDynPcd/DumpDynPcd.inf
+ MdeModulePkg/Application/SampleDriver/SampleDriver.inf
MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.inf

MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf


Re: [RFC/Discussion]: StandAloneMM in OP-TEE

Sahil Malhotra
 

Hi Ard,

Thanks for taking out time to review the proposal.

Please find my comments inline with *[Sahil]*

I'd prefer a separate MmCommunicationOpteeDxe driver, and an updated
OpteeLib that can be used both at boot time and at runtime.
*[Sahil] - Thanks for your input, will work accordingly and send an RFC
soon.*

So I would assume such an approach would permit any standalone MM driver
to be incorporated into the secure side payload, and be invoked using
MmCommunicate as usual?
*[Sahil] - Yes, you are right.*

Regards,
Sahil Malhotra

On Mon, 18 May 2020 at 14:27, Ard Biesheuvel <ard.biesheuvel@arm.com> wrote:

On 5/18/20 10:53 AM, Ilias Apalodimas wrote:
+cc Ard


On Thu, 14 May 2020 at 17:57, Sahil Malhotra <sahil.malhotra@linaro.org
<mailto:sahil.malhotra@linaro.org>> wrote:

Hi All,


We are working on enabling the Secure Storage of Variables for
Secure UEFI.

Let me give you a brief idea of what we are doing.

We need StandAlone Management Mode to run in the Secure Environment.

For that in EDK2 we already have the MmCommunicationDxe Runtime
Driver which communicates with StMM running in Secure Partition in
Secure World.

But this driver is based on SPM (Secure Partition Manager) running
in the ATF.

As we are aware that ATF can run either in SPM mode or SPD mode,
Both are mutually exclusive.

So we cannot have both the StMM running in Secure Partition as well
as OP-TEE or any other Secure OS running in Secure World.

On many systems, there are many other secure operations needed to be
done that can be done by Secure OS only.

So in these systems we need to make the StMM and Secure OS work
together.

As part of doing this only, we have created a kind of Secure
Partition within OP-TEE in which StMM can work as a kind of TA, and
other TAs cannot interfere with the working of this Secure
Partition.

Other TAs can run in parallel to StMM on top of OP-TEE, We can get
the work done by StMM by OP-TEE SMC calls only.

It will be like this as shown in the below image.

Secure World

+-----------------------------------------------------------+

| +-----------------------+ +------------------------+ |

| | | | +--------------------+ | |

| | | | | | | |

| | Trusted Application | | | | | |

| | | | | | | |

| | | | | StMM | | |

| +-----------------------+ | | | | |

| | | | | |

| | | | | |

| | +--------------------+ | |

| | | |

| OP-TEE | | |

| | | |

| | Secure Partition | |

| | | |

| | | |

| | | |

| +------------------------+ |

+-----------------------------------------------------------+

So with this approach of running StMM in an exclusive secure
partition with OP-TEE, StMM and TAs can work together.

In this way StMM binary which is compiled is also
environment-agnostic, Same StMM binary can work whether it is
running as part of OP-TEE or Standalone in Secure Word.

If OP-TEE is responsible for running StMM, firmware implementations,
like U-Boot, can use it to store UEFI variables.


Now for implementing the whole system of Secure Variable Storage for
Secure UEFI.

We need to make changes in MmCommunicationDxe Runtime Driver and
OpteeLib

Let's discuss one by one the changes:

* MmCommunicationDxe – Currently it is based on SPM SMC calls that
get landed into ATF and do the required work.
o Now since StMM is running as part of OP-TEE, we need to
change these into OP-TEE SMC calls.
* OpteeLib – Currently OpteeLib cannot be used with the Runtime
Drivers.
o We need to change its configuration so that it can be used
with a Runtime Driver.

So for making these changes we have following approaches:

* MmCommunicationDxe
o We can have the code for SPM SMC calling and OPTEE SMC
calling in the same driver under some compile time flags,
but it will make the code nasty.
o Another approach can be writing a new driver under the name
of MmCommunicationOpteeDxe in ArmPkg/Drivers/.
* OpteeLib
o We can make necessary changes to make it work with Runtime
Driver.
o Other approach we can make Runtime Driver of Optee also in
ArmPkg/Drivers/

So please review the mail and approaches for making the changes and
let us know your views.

I'd prefer a separate MmCommunicationOpteeDxe driver, and an updated
OpteeLib that can be used both at boot time and at runtime.

So I would assume such an approach would permit any standalone MM driver
to be incorporated into the secure side payload, and be invoked using
MmCommunicate as usual?

One of the things we may need it for is capsule update.


Memory Leaks observed in PCI IO Protocol

Sandeep Dhanvada
 

Hi,

I am using edk2(commit id: 0f1946b) with X64 ARCH, GCC49 toolchain and using PCI IO Protocol functions for memory Allocation/Map and Free/Unmap.

As per our NIC driver requirement, there is a need of 1600 bytes(MTU) of allocated memory for 6KB depth of descriptors pre-allocated at initialization and freed at unload. I am observing memory leak while continuously performing load and unload iterations of driver from UEFI Shell.

I simulated this in OVMF with PCI passthrough and observed leaks in this case also. Attached is the SampleDriver which uses PCI IO Protocol which Allocates and Maps memory while initialization and will Free and Unmap in unload path. In OVMF case, 12KB memory is leaked after every load unload iteration of Sample Driver.

Not sure if this expected behavior or indeed a memory leak.


Re: OVMF build with Cometlake Intel Platform

Laszlo Ersek
 

(CC Alex, Gerd)

On 05/15/20 13:26, Olivier wrote:
Hi all,

I'm looking for some help to understand the boot process of a VM with OVMF.

Context:
I'm setting a iGPU passthrough on laptops:
- I got a success with an Acer Swift (Kabylake i5-7200U). The iGPU is passthrough and I have a display on the laptop screen eDP1 and HDMI
- I got half of a success on XPS 13 7390 (i7-10510U). The iGPU is passthrough and I get a display on HDMI but not on the laptop screen (eDP1) (black screen, not TTY or anything).
The screen is connected: "connected" in /sys/bus/pci/devices/0000:00:02.0/drm/card0/card0-eDP-1/status
But the screen is disabled: "disabled" in /sys/bus/pci/devices/0000:00:02.0/drm/card0/card0-eDP-1/enabled
When I shutdown the VM (boot with OVMF), the iGPU goes back to the host but the laptop screen stays black (no TTY or anything).


My hypothesis is that the iGPU is not "booted" correctly as QEMU uses a generic ROM/vBIOS, that would work for a Kabylake iGPU but not correctly for a Cometlake one (the iGPU passthrough still works though).

The vBIOS being part of the BIOS, my idea was to build OVMF with the Cometlake platform found at https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel.

However, I'm a bit lost now. I've built the platform following the instructions at https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel and I can build OVMF too. But is it possible to set the platform for OVMF as the Intel Cometlake platform? I haven't find anything about that in the wiki.

Does even my idea have a chance to resolve my issue? I have to say that I don't know at all this area of IT and I'm confused about how to solve this problem.
The integrated GPU on the laptop is not an actual, discrete PCI device,
therefore assigning it with VFIO takes horrible hacks, some of which are
guest firmware level hacks. There is no support for that in upstream
OVMF, and that's intentional. See for example
<https://bugzilla.tianocore.org/show_bug.cgi?id=935>.

You can also find several discussions in the
<https://www.redhat.com/archives/vfio-users/> mailing list archive, and
posts in Alex's blog at <https://vfio.blogspot.com/>.

Thanks,
Laszlo


OVMF build with Cometlake Intel Platform

Olivier
 

Hi all,

I'm looking for some help to understand the boot process of a VM with OVMF.

Context:
I'm setting a iGPU passthrough on laptops:
- I got a success with an Acer Swift (Kabylake i5-7200U). The iGPU is passthrough and I have a display on the laptop screen eDP1 and HDMI
- I got half of a success on XPS 13 7390 (i7-10510U). The iGPU is passthrough and I get a display on HDMI but not on the laptop screen (eDP1) (black screen, not TTY or anything).
The screen is connected: "connected" in /sys/bus/pci/devices/0000:00:02.0/drm/card0/card0-eDP-1/status
But the screen is disabled: "disabled" in /sys/bus/pci/devices/0000:00:02.0/drm/card0/card0-eDP-1/enabled
When I shutdown the VM (boot with OVMF), the iGPU goes back to the host but the laptop screen stays black (no TTY or anything).


My hypothesis is that the iGPU is not "booted" correctly as QEMU uses a generic ROM/vBIOS, that would work for a Kabylake iGPU but not correctly for a Cometlake one (the iGPU passthrough still works though).

The vBIOS being part of the BIOS, my idea was to build OVMF with the Cometlake platform found at https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel.

However, I'm a bit lost now. I've built the platform following the instructions at https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel and I can build OVMF too. But is it possible to set the platform for OVMF as the Intel Cometlake platform? I haven't find anything about that in the wiki.

Does even my idea have a chance to resolve my issue? I have to say that I don't know at all this area of IT and I'm confused about how to solve this problem.

Regards,

Olivier


Re: [RFC/Discussion]: StandAloneMM in OP-TEE

Sahil Malhotra
 

Sorry for garbled ASCII diagram, Attached the image here.

Thanks
Sahil


[RFC/Discussion]: StandAloneMM in OP-TEE

Sahil Malhotra
 

Hi All,


We are working on enabling the Secure Storage of Variables for Secure UEFI.

Let me give you a brief idea of what we are doing.



We need StandAlone Management Mode to run in the Secure Environment.

For that in EDK2 we already have the MmCommunicationDxe Runtime Driver
which communicates with StMM running in Secure Partition in Secure World.

But this driver is based on SPM (Secure Partition Manager) running in the
ATF.



As we are aware that ATF can run either in SPM mode or SPD mode, Both are
mutually exclusive.

So we cannot have both the StMM running in Secure Partition as well as
OP-TEE or any other Secure OS running in Secure World.



On many systems, there are many other secure operations needed to be done
that can be done by Secure OS only.

So in these systems we need to make the StMM and Secure OS work together.



As part of doing this only, we have created a kind of Secure Partition
within OP-TEE in which StMM can work as a kind of TA, and other TAs cannot
interfere with the working of this Secure Partition.

Other TAs can run in parallel to StMM on top of OP-TEE, We can get the work
done by StMM by OP-TEE SMC calls only.

It will be like this as shown in the below image.



Secure World

+-----------------------------------------------------------+

| +-----------------------+ +------------------------+ |

| | | | +--------------------+ | |

| | | | | | | |

| | Trusted Application | | | | | |

| | | | | | | |

| | | | | StMM | | |

| +-----------------------+ | | | | |

| | | | | |

| | | | | |

| | +--------------------+ | |

| | | |

| OP-TEE | | |

| | | |

| | Secure Partition | |

| | | |

| | | |

| | | |

| +------------------------+ |

+-----------------------------------------------------------+



So with this approach of running StMM in an exclusive secure partition with
OP-TEE, StMM and TAs can work together.

In this way StMM binary which is compiled is also environment-agnostic,
Same StMM binary can work whether it is running as part of OP-TEE or
Standalone in Secure Word.

If OP-TEE is responsible for running StMM, firmware implementations, like
U-Boot, can use it to store UEFI variables.


Now for implementing the whole system of Secure Variable Storage for Secure
UEFI.



We need to make changes in MmCommunicationDxe Runtime Driver and OpteeLib

Let's discuss one by one the changes:

- MmCommunicationDxe – Currently it is based on SPM SMC calls that get
landed into ATF and do the required work.
- Now since StMM is running as part of OP-TEE, we need to change
these into OP-TEE SMC calls.
- OpteeLib – Currently OpteeLib cannot be used with the Runtime Drivers.
- We need to change its configuration so that it can be used with a
Runtime Driver.



So for making these changes we have following approaches:

- MmCommunicationDxe
- We can have the code for SPM SMC calling and OPTEE SMC calling in
the same driver under some compile time flags, but it will make the code
nasty.
- Another approach can be writing a new driver under the name of
MmCommunicationOpteeDxe in ArmPkg/Drivers/.
- OpteeLib
- We can make necessary changes to make it work with Runtime Driver.
- Other approach we can make Runtime Driver of Optee also in
ArmPkg/Drivers/



So please review the mail and approaches for making the changes and let us
know your views.


Regards,

Sahil Malhotra


Re: Clarification needed for PCI address translation

Pankaj Bansal
 

On Mon, 11 May 2020 at 05:36, Pankaj Bansal <pankaj.bansal@nxp.com> wrote:

But won't it?

There can be only two scenarios :
1. PCI address space coincides with CPU address space.
In this case host address = device address and translation = 0
2. PCI address space lies at some offset in CPU address space. Like the
example I mention in LX2160A
In this case host address = device address + translation, where translation >
0

Can there be a scenario where translation < 0 ? I don't think so
I don't see how this matters.

Translation uses unsigned 64-bit integer arithmetic, so if you need
the translation to go the other way, just subtract from
0x1_0000_0000_0000_0000.
That is what confuses me. Why is this convoluted logic needed altogether ?
Why can't we use direct translation values (instead of MAX_UINT64 + 1 - translation) ?

Regards,
Pankaj Bansal


Re: Clarification needed for PCI address translation

Pankaj Bansal
 

But won't it?

There can be only two scenarios :
1. PCI address space coincides with CPU address space.
In this case host address = device address and translation = 0
2. PCI address space lies at some offset in CPU address space. Like the example I mention in LX2160A
In this case host address = device address + translation, where translation > 0

Can there be a scenario where translation < 0 ? I don't think so

Regards,
Pankaj Bansal

-----Original Message-----
From: Ni, Ray <ray.ni@intel.com>
Sent: Monday, May 11, 2020 7:37 AM
To: Pankaj Bansal <pankaj.bansal@nxp.com>; Heyi Guo <heyi.guo@linaro.org>;
Yi Li <phoenix.liyi@huawei.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: discuss@edk2.groups.io
Subject: RE: Clarification needed for PCI address translation

I don't think the assumption is valid that host address be "always" greater than
device address.

-----Original Message-----
From: Pankaj Bansal <pankaj.bansal@nxp.com>
Sent: Sunday, May 10, 2020 12:10 PM
To: Heyi Guo <heyi.guo@linaro.org>; Yi Li <phoenix.liyi@huawei.com>; Ni,
Ray
<ray.ni@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: discuss@edk2.groups.io
Subject: Clarification needed for PCI address translation

Hi Heyi Guo et al,

I have a question about the patch that you submitted in edk2:

commit dc080d3b61e570e7a3163fc24afa6f8388d0c0bf
Author: Heyi Guo <heyi.guo@linaro.org>
Date: Thu Feb 8 11:13:27 2018 +0800

MdeModulePkg/PciBus: return CPU address for GetBarAttributes

According to UEFI spec 2.7, PciIo->GetBarAttributes should return host
address (CPU view ddress) rather than device address (PCI view
address), and
device address = host address + address translation offset,
so we subtract translation from device address before returning.

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
index fef3eceb7f62..62179eb44bbd 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
@@ -1972,6 +1972,10 @@ PciIoGetBarAttributes (
return EFI_UNSUPPORTED;
}
}
+
+ // According to UEFI spec 2.7, we need return host address for
+ // PciIo->GetBarAttributes, and host address = device address - translation.
+ Descriptor->AddrRangeMin -= Descriptor->AddrTranslationOffset;
}

return EFI_SUCCESS;

Now I have a question about this statement : "host address = device address -
translation"
Won't the host address be "always" greater than device address ?

As I see the PCI controller integration in out ARM64 based SOC (LX2160), the
PCI address space
of a controller starts at > 4 GB offset in HOST address space. E.g. :

Start address | End address | Size | Allocation
0x3600000 | 0x360FFFF | 64K | PCI controller registers
0x80000000 | 0xFFFFFFFF | 2GB | DDR
0x8000000000 | 0x87FFFFFFFF | 32GB | PCI Express

All the BAR allocations (IO/MEM32/MEM64) are done from 32 GB PCI express
space (i.e. 0x8000000000 - 0x87FFFFFFFF)
The corresponding PCI addresses for devices are in 32 GB range i.e. 0x0 -
0x7FFFFFFFF.
If I take translation = 0x8000000000, So for this case :

host address = device address + translation.

Regards,
Pankaj Bansal


Re: Clarification needed for PCI address translation

Ni, Ray
 

I don't think the assumption is valid that host address be "always" greater than device address.

-----Original Message-----
From: Pankaj Bansal <pankaj.bansal@nxp.com>
Sent: Sunday, May 10, 2020 12:10 PM
To: Heyi Guo <heyi.guo@linaro.org>; Yi Li <phoenix.liyi@huawei.com>; Ni, Ray
<ray.ni@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: discuss@edk2.groups.io
Subject: Clarification needed for PCI address translation

Hi Heyi Guo et al,

I have a question about the patch that you submitted in edk2:

commit dc080d3b61e570e7a3163fc24afa6f8388d0c0bf
Author: Heyi Guo <heyi.guo@linaro.org>
Date: Thu Feb 8 11:13:27 2018 +0800

MdeModulePkg/PciBus: return CPU address for GetBarAttributes

According to UEFI spec 2.7, PciIo->GetBarAttributes should return host
address (CPU view ddress) rather than device address (PCI view
address), and
device address = host address + address translation offset,
so we subtract translation from device address before returning.

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
index fef3eceb7f62..62179eb44bbd 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
@@ -1972,6 +1972,10 @@ PciIoGetBarAttributes (
return EFI_UNSUPPORTED;
}
}
+
+ // According to UEFI spec 2.7, we need return host address for
+ // PciIo->GetBarAttributes, and host address = device address - translation.
+ Descriptor->AddrRangeMin -= Descriptor->AddrTranslationOffset;
}

return EFI_SUCCESS;

Now I have a question about this statement : "host address = device address -
translation"
Won't the host address be "always" greater than device address ?

As I see the PCI controller integration in out ARM64 based SOC (LX2160), the
PCI address space
of a controller starts at > 4 GB offset in HOST address space. E.g. :

Start address | End address | Size | Allocation
0x3600000 | 0x360FFFF | 64K | PCI controller registers
0x80000000 | 0xFFFFFFFF | 2GB | DDR
0x8000000000 | 0x87FFFFFFFF | 32GB | PCI Express

All the BAR allocations (IO/MEM32/MEM64) are done from 32 GB PCI express
space (i.e. 0x8000000000 - 0x87FFFFFFFF)
The corresponding PCI addresses for devices are in 32 GB range i.e. 0x0 -
0x7FFFFFFFF.
If I take translation = 0x8000000000, So for this case :

host address = device address + translation.

Regards,
Pankaj Bansal


Re: TCP in an UEFI runtime driver

Laszlo Ersek
 

On 05/06/20 14:48, florian.hantke@fau.de wrote:

My idea is to implement an UEFI runtime driver that can receive a command via TCP during runtime, then runs a job and finally sends the result back via TCP.
I don't see how this could (usefully) work.

You say "UEFI runtime driver", which implies you would do the above with
the operating system running.

But if the OS is already running, then it owns the networking hardware.
Even if the OS does not have a driver for the NIC in question, the OS
certainly owns the "namespace" for the local endpoints of TCP
connections (namely the OS assigns the IP addresses and the port
numbers). I don't see how that could be co-ordinated between a UEFI
runtime driver and the OS.

Another issue would be packet reception. How would the driver notice
incoming packets? UEFI does not handle interrupts (it has no support for
interrupt-driven event loops), and there are no runtime services that
would let you construct a polling loop.

I'm not saying an "SMM rootkit with network connectivity" cannot be
written, but that's not exactly oriented towards cooperation with the OS.

Non-malicious UEFI network drivers are boot time only drivers, and they
have one purpose: enabling booting the OS (or OS bootloader) over the
network.

UNDI is a lower-level abstraction than UEFI. UEFI can use UNDI for
network connectivity (NetworkPkg/SnpDxe does that; it implements the
Simple Network Protocol on top of UNDI), but said "UEFI binding" of UNDI
is again boot time only.

Laszlo


Re: TCP in an UEFI runtime driver

Tim Lewis
 

Florian --

Making a runtime driver would be quite difficult, since almost all services are no longer available after ExitBootServices is called by the booting OS.

Perhaps a shell app would be more appropriate, since this runs in the pre-OS.

I'm not a QEMM expert, but I believe that it supports an emulated NIC driver that uses the host's NIC.

Tim

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of florian.hantke@fau.de
Sent: Wednesday, May 6, 2020 5:48 AM
To: discuss@edk2.groups.io
Subject: [edk2-discuss] TCP in an UEFI runtime driver

Hello everyone,

I am a student working on a project with EDK2 (and qemu), however I am quite new to this topic.

My idea is to implement an UEFI runtime driver that can receive a command via TCP during runtime, then runs a job and finally sends the result back via TCP.
So far I implemented a simple runtime driver, but the network part is missing.
According to the docs [1], I need to implement the UNDI feature and interact with the emulated NIC [2].
The problem is, I cannot find any documentation or code, how I would implement it.
Do you know where I would find some good resources or examples?

Also, I am not sure, if my idea would work that way?
Can a UEFI driver receive TCP packages on a predefined port or can it only send packages?
If not, is there any other way I could trigger a job remotly during runtime so that my driver runs the job and sends the results via TCP?

Thank you for your help and excuse me if my questions are very low-level, but as I said, I am still new to this topic.

Best regards,
Florian Hantke

[1] https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/25_network_driver_design_guidelines
[2] https://github.com/tianocore/tianocore.github.io/wiki/EDKII-Network-Over-QEMU


Re: TCP in an UEFI runtime driver

florian.hantke@...
 

Thank you, I will check it out.
I only looked through the mian edk2 git, yet.

Best regards,
Florian Hantke


Re: TCP in an UEFI runtime driver

Wim Vervoorn <wvervoorn@...>
 

Have you looked at:

https://github.com/tianocore/edk2-libc


Best Regards,
Wim Vervoorn

-----Original Message-----
From: discuss@edk2.groups.io [mailto:discuss@edk2.groups.io] On Behalf Of florian.hantke@fau.de
Sent: Wednesday, May 6, 2020 2:48 PM
To: discuss@edk2.groups.io
Subject: [edk2-discuss] TCP in an UEFI runtime driver

Hello everyone,

I am a student working on a project with EDK2 (and qemu), however I am quite new to this topic.

My idea is to implement an UEFI runtime driver that can receive a command via TCP during runtime, then runs a job and finally sends the result back via TCP.
So far I implemented a simple runtime driver, but the network part is missing.
According to the docs [1], I need to implement the UNDI feature and interact with the emulated NIC [2].
The problem is, I cannot find any documentation or code, how I would implement it.
Do you know where I would find some good resources or examples?

Also, I am not sure, if my idea would work that way?
Can a UEFI driver receive TCP packages on a predefined port or can it only send packages?
If not, is there any other way I could trigger a job remotly during runtime so that my driver runs the job and sends the results via TCP?

Thank you for your help and excuse me if my questions are very low-level, but as I said, I am still new to this topic.

Best regards,
Florian Hantke

[1] https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/25_network_driver_design_guidelines
[2] https://github.com/tianocore/tianocore.github.io/wiki/EDKII-Network-Over-QEMU


TCP in an UEFI runtime driver

florian.hantke@...
 

Hello everyone,

I am a student working on a project with EDK2 (and qemu), however I am quite new to this topic.

My idea is to implement an UEFI runtime driver that can receive a command via TCP during runtime, then runs a job and finally sends the result back via TCP.
So far I implemented a simple runtime driver, but the network part is missing.
According to the docs [1], I need to implement the UNDI feature and interact with the emulated NIC [2].
The problem is, I cannot find any documentation or code, how I would implement it.
Do you know where I would find some good resources or examples?

Also, I am not sure, if my idea would work that way?
Can a UEFI driver receive TCP packages on a predefined port or can it only send packages?
If not, is there any other way I could trigger a job remotly during runtime so that my driver runs the job and sends the results via TCP?

Thank you for your help and excuse me if my questions are very low-level, but as I said, I am still new to this topic.

Best regards,
Florian Hantke

[1] https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/25_network_driver_design_guidelines
[2] https://github.com/tianocore/tianocore.github.io/wiki/EDKII-Network-Over-QEMU


Re: Is there a way to include a custom binary in EDK2 and load it in a UEFI driver?

Guomin Jiang
 

I am busy recently and won't spend time on the thread until July.

I suggest that you can search the source code and figure out how to use ReadFile() function, I think it is better that use ReadSection service to get the file content.

Best Regards
Guomin

-----Original Message-----
From: Laszlo Ersek <lersek@redhat.com>
Sent: Tuesday, May 5, 2020 11:45 PM
To: discuss@edk2.groups.io; mzktsn@gmail.com; Jiang, Guomin
<guomin.jiang@intel.com>
Subject: Re: [edk2-discuss] Is there a way to include a custom binary in EDK2
and load it in a UEFI driver?

On 04/30/20 19:02, mzktsn@gmail.com wrote:
Hello!

I have managed to insert a custom file into the Firmware Volume, but
then attempting to retrieve the original contents from a DXE_DRIVER,
only the first 4 bytes of the file are returned correct.

Used ReadFile() from EFI_FIRMWARE_VOLUME2_PROTOCOL succesfully
retrieves the 4 first bytes and the rest are modified.
The file size of the Buffer returned is correct by the way.

Am i missing something in the way to retrieve the file contents? Or
there is some processing that may alter the contents without noticing it?
I probably won't have much time to spend on this thread, but I'd suggest
posting a minimal / self-contained reproducer, complete with DSC / FDF / INF
file(s).

Independently, some of the functions in
"MdePkg/Include/Library/DxeServicesLib.h" might prove useful.

Laszlo

661 - 680 of 895