public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ard Biesheuvel" <ard.biesheuvel@linaro.org>
To: devel@edk2.groups.io
Cc: lersek@redhat.com, Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: [PATCH v3 08/14] OvmfPkg/QemuKernelLoaderFsDxe: add support for the kernel setup block
Date: Thu,  5 Mar 2020 14:46:01 +0100	[thread overview]
Message-ID: <20200305134607.20125-9-ard.biesheuvel@linaro.org> (raw)
In-Reply-To: <20200305134607.20125-1-ard.biesheuvel@linaro.org>

On x86, the kernel image consists of a setup block and the actual kernel,
and QEMU presents these as separate blobs, whereas on disk (and in terms
of PE/COFF image signing), they consist of a single image.

So add support to our FS loader driver to expose files via the abstract
file system that consist of up to two concatenated blobs, and redefine
the kernel file so it consists of the setup and kernel blobs, on every
architecture (on non-x86, the setup block is simply 0 bytes and is
therefore ignored implicitly)

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
---
 OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c | 74 ++++++++++++++------
 1 file changed, 53 insertions(+), 21 deletions(-)

diff --git a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c b/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
index dc86a48af378..8ccb1983170c 100644
--- a/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
+++ b/OvmfPkg/QemuKernelLoaderFsDxe/QemuKernelLoaderFsDxe.c
@@ -34,16 +34,29 @@ typedef enum {
 } KERNEL_BLOB_TYPE;
 
 typedef struct {
-  FIRMWARE_CONFIG_ITEM CONST SizeKey;
-  FIRMWARE_CONFIG_ITEM CONST DataKey;
-  CONST CHAR16 *       CONST Name;
-  UINT32                     Size;
-  UINT8                      *Data;
+  CONST CHAR16                  Name[8];
+  struct {
+    FIRMWARE_CONFIG_ITEM CONST  SizeKey;
+    FIRMWARE_CONFIG_ITEM CONST  DataKey;
+    UINT32                      Size;
+  }                             FwCfgItem[2];
+  UINT32                        Size;
+  UINT8                         *Data;
 } KERNEL_BLOB;
 
 STATIC KERNEL_BLOB mKernelBlob[KernelBlobTypeMax] = {
-  { QemuFwCfgItemKernelSize,      QemuFwCfgItemKernelData,      L"kernel"  },
-  { QemuFwCfgItemInitrdSize,      QemuFwCfgItemInitrdData,      L"initrd"  },
+  {
+    L"kernel",
+    {
+      { QemuFwCfgItemKernelSetupSize, QemuFwCfgItemKernelSetupData, },
+      { QemuFwCfgItemKernelSize,      QemuFwCfgItemKernelData,      },
+    }
+  }, {
+    L"initrd",
+    {
+      { QemuFwCfgItemInitrdSize,      QemuFwCfgItemInitrdData,      },
+    }
+  }
 };
 
 STATIC UINT64 mTotalBlobBytes;
@@ -850,12 +863,21 @@ FetchBlob (
   )
 {
   UINT32 Left;
+  UINTN  Idx;
+  UINT8  *ChunkData;
 
   //
   // Read blob size.
   //
-  QemuFwCfgSelectItem (Blob->SizeKey);
-  Blob->Size = QemuFwCfgRead32 ();
+  Blob->Size = 0;
+  for (Idx = 0; Idx < ARRAY_SIZE (Blob->FwCfgItem); Idx++) {
+    if (Blob->FwCfgItem[Idx].SizeKey == 0) {
+      break;
+    }
+    QemuFwCfgSelectItem (Blob->FwCfgItem[Idx].SizeKey);
+    Blob->FwCfgItem[Idx].Size = QemuFwCfgRead32 ();
+    Blob->Size += Blob->FwCfgItem[Idx].Size;
+  }
   if (Blob->Size == 0) {
     return EFI_SUCCESS;
   }
@@ -872,18 +894,28 @@ FetchBlob (
 
   DEBUG ((DEBUG_INFO, "%a: loading %Ld bytes for \"%s\"\n", __FUNCTION__,
     (INT64)Blob->Size, Blob->Name));
-  QemuFwCfgSelectItem (Blob->DataKey);
-
-  Left = Blob->Size;
-  do {
-    UINT32 Chunk;
-
-    Chunk = (Left < SIZE_1MB) ? Left : SIZE_1MB;
-    QemuFwCfgReadBytes (Chunk, Blob->Data + (Blob->Size - Left));
-    Left -= Chunk;
-    DEBUG ((DEBUG_VERBOSE, "%a: %Ld bytes remaining for \"%s\"\n",
-      __FUNCTION__, (INT64)Left, Blob->Name));
-  } while (Left > 0);
+
+  ChunkData = Blob->Data;
+  for (Idx = 0; Idx < ARRAY_SIZE (Blob->FwCfgItem); Idx++) {
+    if (Blob->FwCfgItem[Idx].DataKey == 0) {
+      break;
+    }
+    QemuFwCfgSelectItem (Blob->FwCfgItem[Idx].DataKey);
+
+    Left = Blob->FwCfgItem[Idx].Size;
+    while (Left > 0) {
+      UINT32 Chunk;
+
+      Chunk = (Left < SIZE_1MB) ? Left : SIZE_1MB;
+      QemuFwCfgReadBytes (Chunk, ChunkData + Blob->FwCfgItem[Idx].Size - Left);
+      Left -= Chunk;
+      DEBUG ((DEBUG_VERBOSE, "%a: %Ld bytes remaining for \"%s\" (%d)\n",
+        __FUNCTION__, (INT64)Left, Blob->Name, (INT32)Idx));
+    }
+
+    ChunkData += Blob->FwCfgItem[Idx].Size;
+  }
+
   return EFI_SUCCESS;
 }
 
-- 
2.17.1


  parent reply	other threads:[~2020-03-05 13:46 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-05 13:45 [PATCH v3 00/14] Ovmf: use LoadImage/StartImage for loading command line images Ard Biesheuvel
2020-03-05 13:45 ` [PATCH v3 01/14] OvmfPkg: add GUID for the QEMU kernel loader fs media device path Ard Biesheuvel
2020-03-05 13:45 ` [PATCH v3 02/14] OvmfPkg: export abstract QEMU blob filesystem in standalone driver Ard Biesheuvel
2020-03-05 13:45 ` [PATCH v3 03/14] OvmfPkg: introduce QemuLoadImageLib library class Ard Biesheuvel
2020-03-05 13:45 ` [PATCH v3 04/14] OvmfPkg: provide a generic implementation of QemuLoadImageLib Ard Biesheuvel
2020-03-05 13:45 ` [PATCH v3 05/14] ArmVirtPkg: incorporate the new QEMU kernel loader driver and library Ard Biesheuvel
2020-03-05 13:45 ` [PATCH v3 06/14] ArmVirtPkg/PlatformBootManagerLib: switch to separate QEMU loader Ard Biesheuvel
2020-03-05 13:46 ` [PATCH v3 07/14] OvmfPkg/QemuKernelLoaderFsDxe: don't expose kernel command line Ard Biesheuvel
2020-03-05 13:46 ` Ard Biesheuvel [this message]
2020-03-05 13:46 ` [PATCH v3 09/14] OvmfPkg: create protocol and GUID header for loaded x86 Linux kernels Ard Biesheuvel
2020-03-05 16:01   ` [edk2-devel] " Laszlo Ersek
2020-03-05 13:46 ` [PATCH v3 10/14] OvmfPkg: implement QEMU loader library for X86 with legacy fallback Ard Biesheuvel
2020-03-05 18:03   ` [edk2-devel] " Laszlo Ersek
2020-03-05 13:46 ` [PATCH v3 11/14] OvmfPkg: add new QEMU kernel image loader components Ard Biesheuvel
2020-03-05 13:46 ` [PATCH v3 12/14] OvmfPkg/PlatformBootManagerLib: switch to QemuLoadImageLib Ard Biesheuvel
2020-03-05 21:15   ` [edk2-devel] " Laszlo Ersek
2020-03-05 21:20     ` Ard Biesheuvel
2020-03-05 23:42       ` Laszlo Ersek
2020-03-05 13:46 ` [PATCH v3 13/14] OvmfPkg/QemuKernelLoaderFsDxe: add support for new Linux initrd device path Ard Biesheuvel
2020-03-05 13:46 ` [PATCH v3 14/14] OvmfPkg: use generic QEMU image loader for secure boot enabled builds Ard Biesheuvel
2020-06-09  9:51   ` [edk2-devel] " Laszlo Ersek
2020-06-09 10:45     ` Ard Biesheuvel
2020-06-10  9:22       ` Laszlo Ersek
2020-06-10  9:32         ` Ard Biesheuvel
2020-06-11 14:55           ` Laszlo Ersek
2020-06-11 15:05             ` Ard Biesheuvel
2020-06-11 18:13               ` Laszlo Ersek
2020-06-11 19:07                 ` Ard Biesheuvel
2020-03-06  2:01 ` [edk2-devel] [PATCH v3 00/14] Ovmf: use LoadImage/StartImage for loading command line images Bob Feng
2020-03-06  7:42   ` Ard Biesheuvel

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=20200305134607.20125-9-ard.biesheuvel@linaro.org \
    --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