On Thu, Aug 22, 2024 at 4:23 PM Lennart Poettering <mzxreary@xxxxxxxxxxx> wrote: > > On Do, 22.08.24 13:42, Pingfan Liu (piliu@xxxxxxxxxx) wrote: > > > On Wed, Aug 21, 2024 at 10:27 PM Lennart Poettering > > <mzxreary@xxxxxxxxxxx> wrote: > > > > > > On Mo, 19.08.24 22:53, Pingfan Liu (piliu@xxxxxxxxxx) wrote: > > > > > > > *** Background *** > > > > > > > > As more PE format kernel images are introduced, it post challenge to kexec to > > > > cope with the new format. > > > > > > > > In my attempt to add support for arm64 zboot image in the kernel [1], > > > > Ard suggested using an emulator to tackle this issue. Last year, when > > > > Jan tried to introduce UKI support in the kernel [2], Ard mentioned the > > > > emulator approach again [3] > > > > > > Hmm, systemd's systemd-stub code tries to load certain "side-car" > > > files placed next to the UKI, via the UEFI file system APIs. What's > > > your intention with the UEFI emulator regarding that? The sidecars are > > > somewhat important, because that's how we parameterize otherwise > > > strictly sealed, immutable UKIs. > > > > > IIUC, you are referring to UKI addons. > > Yeah, UKI addons, as well as credential files, and sysext/confext > DDIs. > > The addons are the most interesting btw, because we load them into > memory as PE files, and ask the UEFI to authenticate them. > > > > Hence, what's the story there? implement some form of fs driver (for > > > what fs precisely?) in the emulator too? > > > > > As for addon, that is a missing part in this series. I have overlooked > > this issue. Originally, I thought that there was no need to implement > > a disk driver and vfat file system, just preload them into memory, and > > finally present them through the uefi API. I will take a closer look > > at it and chew on it. > > It doesn't have to be VFAT btw. It just has to be something. For > example, it might suffice to take these files, pack them up as cpio or > so and pass them along with the UEFI execution. The UEFI emulator > would then have to expose them as a file system then. > > We are not talking of a bazillion of files here, it's mostly a > smallish number of sidecar files I'd expect. > > > > And regarding tpm? tpms require drivers and i guess at the moment uefi > > > emulator would run those aren't available anymore? but we really > > > should do a separator measurement then. (also there needs to be some > > > way to pass over measurement log of that measurement?) > > > > It is a pity that it is a common issue persistent with kexec-reboot > > kernel nowadays. > > I am not familiar with TPM and have no clear idea for the time being. > > (emulating Platform Configuration Registers ?). But since this > > emulator is held inside a linux kernel image, and the UKI's signature > > is checked during kexec_file_load. All of them are safe from > > modification, this security is not an urgent issue. > > Hmm, I'd really think about this with some priority. The measurement > stuff should not be an afterthought, it typically has major > implications on how you design your transitions, because measurements > of some component always need to happen *before* you pass control to > it, otherwise they are pointless. > At present, my emulator returns false to is_efi_secure_boot(), so systemd-stub does not care about the measurement, and moves on. Could you enlighten me about how systemd utilizes the measurement? I grepped 'TPM2_PCR_KERNEL_CONFIG', and saw the systemd-stub asks to extend PCR. But where is the value checked? I guess the systemd will hang if the check fails. Thanks, Pingfan
