linux-kernel - Re: [RFCv2 0/9] UEFI emulator for kexec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF+s44SQtRxZz=2eSJ-xP44ORLqvq0doEQ8qrw+1RaKFhoje8w@mail.gmail.com>
Date: Thu, 22 Aug 2024 22:29:31 +0800
From: Pingfan Liu <piliu@...hat.com>
To: Lennart Poettering <mzxreary@...inter.de>
Cc: Ard Biesheuvel <ardb@...nel.org>, Jan Hendrik Farr <kernel@...rr.cc>, Philipp Rudo <prudo@...hat.com>, 
	Jarkko Sakkinen <jarkko@...nel.org>, Eric Biederman <ebiederm@...ssion.com>, Baoquan He <bhe@...hat.com>, 
	Dave Young <dyoung@...hat.com>, Mark Rutland <mark.rutland@....com>, Will Deacon <will@...nel.org>, 
	Catalin Marinas <catalin.marinas@....com>, kexec@...ts.infradead.org, 
	linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFCv2 0/9] UEFI emulator for kexec

On Thu, Aug 22, 2024 at 4:23 PM Lennart Poettering <mzxreary@...inter.de> wrote:
>
> On Do, 22.08.24 13:42, Pingfan Liu (piliu@...hat.com) wrote:
>
>  > On Wed, Aug 21, 2024 at 10:27 PM Lennart Poettering
> > <mzxreary@...inter.de> wrote:
> > >
> > > On Mo, 19.08.24 22:53, Pingfan Liu (piliu@...hat.com) 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