From: "Dov Murik" <dovmurik@linux.ibm.com>
To: Laszlo Ersek <lersek@redhat.com>,
devel@edk2.groups.io, Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Tobin Feldman-Fitzthum <tobin@linux.ibm.com>,
Tobin Feldman-Fitzthum <tobin@ibm.com>,
Jim Cadden <jcadden@ibm.com>,
James Bottomley <jejb@linux.ibm.com>,
Hubertus Franke <frankeh@us.ibm.com>,
Jordan Justen <jordan.l.justen@intel.com>,
Ashish Kalra <ashish.kalra@amd.com>,
Brijesh Singh <brijesh.singh@amd.com>,
Erdem Aktas <erdemaktas@google.com>,
Jiewen Yao <jiewen.yao@intel.com>, Min Xu <min.m.xu@intel.com>,
Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [edk2-devel] [PATCH v1 0/8] Measured SEV boot with kernel/initrd/cmdline
Date: Tue, 8 Jun 2021 12:57:00 +0300 [thread overview]
Message-ID: <b2694ad8-59b7-5931-0dd7-12a7188ec266@linux.ibm.com> (raw)
In-Reply-To: <ff44d976-a246-782a-ec28-af96772f52b6@redhat.com>
On 04/06/2021 14:26, Laszlo Ersek wrote:
> On 06/04/21 12:30, Dov Murik wrote:
>
...
>>
>>> [Ard, please see this one question:]
>>>
>>> - A major complication for hashing all three of: kernel, initrd,
>>> cmdline, is that the *fetching* of this triplet is split between two
>>> places. (Well, it is split between *three* places in fact, but I'm
>>> going to ignore LinuxInitrdDynamicShellCommand for now, because the
>>> AmdSevX64 platform sets BUILD_SHELL to FALSE for production.)
>>>
>>> The kernel and the initrd are fetched in QemuKernelLoaderFsDxe, but
>>> the command line is fetched in (both) QemuLoadImageLib instances.
>>> This requires that all these modules be littered with hashing as
>>> well, which I find *really bad*. Even if we factor out the actual
>>> logic, I strongly dislike having *just hooks* for hashing in multiple
>>> modules.
>>>
>>> Now, please refer to efc52d67e157 ("OvmfPkg/QemuKernelLoaderFsDxe:
>>> don't expose kernel command line", 2020-03-05). If we first
>>>
>>> (a) reverted that commit, and
>>>
>>> (b) modified *both* QemuLoadImageLib instances, to load the kernel
>>> command line from the *synthetic filesystem* (rather than directly
>>> from fw_cfg),
>>>
>>> then we could centralize the hashing to just QemuKernelLoaderFsDxe.
>>>
>>> Ard -- what's your thought on this?
>>>
>>
>> I understand there's agreement here, and that both this suggested
>> change (use the synthetic filesystem) and my patch series (add hash
>> verification) touch the same code areas. How do you envision this
>> process in the mailing list? Seperate patch serieses with dependency?
>> One long patch series with both changes? What goes first?
>
> Good point. I do have a kind of patch order laid out in my mind, but I
> didn't think of whether we should have the patches in one patch series,
> or in two "waves".
>
> OK, let's go with two patch sets.
>
> In the first set, we should just focus on the above steps (a) and (b).
> Step (a) shouldn't be too hard. In step (b), you'd modify both
> QemuLoadImageLib instances (two separate patches), replacing the
> QemuFwCfgLib APIs for fetching the cmdline with
> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and EFI_FILE_PROTOCOL APIs.
>
> Speaking from memory, the synthetic filesystem has a unique device path,
> so the first step would be calling gBS->LocateDevicePath(), for finding
> SimpleFs on the unique device path. Once you have the SimpleFs
> interface, you can call OpenVolume, then open the "cmdline" file using
> the EFI_FILE_PROTOCOL output by OpenVolume.
>
> Once we merge this series (basically just three patches), there is no
> QemuFwCfgLib dependency left in either QemuLoadImageLib instance, I
> reckon.
I started working on that, and managed to remove all QemuFwCfg* calls in
the main path of QemuLoadKernelImage (so far working on
X86QemuLoadImageLib.c). That works fine: I read the content of the
"cmdline" synthetic file, and I check the size of the synthetic "initrd"
file. I used Library/FileHandleLib.h; I hope that's fine.
However, there's another path (which I don't reach with my test setup),
which is the call to QemuLoadLegacyImage, which has a lot of calls to
QemuFwCfg* in its body.
Am I expected to change that legacy path as well?
Or is it in a "it's working don't touch" state?
If I modify this, how do I test it?
Thanks for the guidance,
-Dov
next prev parent reply other threads:[~2021-06-08 9:57 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-25 5:31 [PATCH v1 0/8] Measured SEV boot with kernel/initrd/cmdline Dov Murik
2021-05-25 5:31 ` [PATCH v1 1/8] OvmfPkg/AmdSev/SecretDxe: fix header comment to generic naming Dov Murik
2021-05-25 5:31 ` [PATCH v1 2/8] OvmfPkg: PlatformBootManagerLibGrub: Allow executing kernel via fw_cfg Dov Murik
2021-05-25 5:31 ` [PATCH v1 3/8] OvmfPkg/AmdSev: add a page to the MEMFD for firmware config hashes Dov Murik
2021-05-25 5:31 ` [PATCH v1 4/8] OvmfPkg/QemuKernelLoaderFsDxe: Add ability to verify loaded items Dov Murik
2021-05-25 5:31 ` [PATCH v1 5/8] OvmfPkg/AmdSev: Add library to find encrypted hashes for the FwCfg device Dov Murik
2021-05-25 5:31 ` [PATCH v1 6/8] OvmfPkg/AmdSev: Add firmware file plugin to verifier Dov Murik
2021-05-25 5:31 ` [PATCH v1 7/8] OvmfPkg: GenericQemuLoadImageLib: Allow verifying fw_cfg command line Dov Murik
2021-05-25 5:31 ` [PATCH v1 8/8] OvmfPkg/AmdSev: add SevQemuLoadImageLib Dov Murik
2021-05-25 13:07 ` [edk2-devel] [PATCH v1 0/8] Measured SEV boot with kernel/initrd/cmdline Dov Murik
2021-05-25 15:48 ` Brijesh Singh
2021-05-25 20:08 ` [edk2-devel] " Dov Murik
2021-05-25 20:33 ` Lendacky, Thomas
2021-05-25 23:15 ` James Bottomley
2021-05-25 23:37 ` Brijesh Singh
2021-05-26 6:21 ` Dov Murik
2021-05-27 9:41 ` Laszlo Ersek
2021-06-01 12:11 ` Laszlo Ersek
2021-06-01 13:20 ` Ard Biesheuvel
2021-06-01 16:13 ` Laszlo Ersek
2021-06-02 18:10 ` James Bottomley
2021-06-03 8:28 ` Laszlo Ersek
2021-06-04 10:30 ` Dov Murik
2021-06-04 11:26 ` Laszlo Ersek
2021-06-06 13:21 ` Dov Murik
2021-06-07 13:33 ` Laszlo Ersek
2021-06-08 9:57 ` Dov Murik [this message]
2021-06-08 10:59 ` Laszlo Ersek
2021-06-08 12:09 ` Dov Murik
2021-06-08 15:59 ` Laszlo Ersek
2021-06-09 12:25 ` Dov Murik
2021-06-09 13:54 ` Laszlo Ersek
2021-06-10 9:15 ` 回复: " gaoliming
2021-06-14 7:33 ` Dov Murik
2021-06-08 12:49 ` Ard Biesheuvel
2021-06-08 16:00 ` 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=b2694ad8-59b7-5931-0dd7-12a7188ec266@linux.ibm.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