On Fri, Nov 7, 2025 at 10:51 AM Lennart Poettering <[email protected]> wrote:
> On Fr, 07.11.25 10:34, Itxaka Serrano Garcia ( > [email protected]) wrote: > > > Is it not about using grub at all? It's about building and supporting > > systemd features that accomodate tpm2 devices for other bootloaders that > > conform to the specification? > > Like which one? > > The boot loader interface and the boot loader spec have not much to do > with the tpm logic though. It does not define which measurements are > supposed to be made by pre-boot environment. And quite frankly I am > quite uneasy about making that an API for other boot laoders at this > time. > > > Also mainly to build stuff separately, for example we build systemd-boot > in > > a different package that we build systemd, so on one we set > > bootloader=disabled as it doesn't make sense to build it together, the > less > > we build, the faster it goes :D > > It's not really what we optimize for though... > > > Even more, the systemd-pcrextend is also linked to the bootloader switch, > > which makes no sense to me, as its independent of the bootloader used as > > long as it conforms to the specification. For example, pcrlock is not > tied > > to the bootloader, which makes sense to me. > > As mentioned, pcrextend measures various things at boot into various > nvindexes we took possession off. i.e. [email protected], > systemd-pcrmachine.service, systemd-pcrphase*.service do that, they > all just wrap different ways systemd-pcrextend is called. > > if you do not buy into systemd-stub, we do not do those measurements > either, and hence turn it off at build time. > > The model is: either you want us to measure stuff or you don't want > that. If you do, enable systemd-stub + systemd-pcrextend and you > will. But doing this separately doesn#t make too much sense, because a > verified boot chain is a *chain*, not one random measurement. > > > I'm wondering if this was tied to it at the start and it's just a > > leftover? > > As I said, no: this is by intention. > > > I'm willing to send patches to remove those deps and instead depend on > > tpm2=enabled to enable those tpm2 related services to build based on that > > if its wanted. > > No, that's not acceptable, then we'd start measuring various things > into PCRs people might use differently. > > The thing is that there are only very few PCRs available, and unless > people opt into our view of the world, we shouldn't measure stuff to > them, colloding with peoples own uses. And the way you opt into our > view of the world is that you use systemd-stub, which is the hook for > all those measurements. > > Ok, this is okay, thakns for the info, i'll just carry local patches for that :) > > Just wondering though, it would be simple enough to have local patches to > > enable this, but I was wondering if this was something we wanted directly > > upstream on systemd :) > > Sorry, but I don't think you understand what the role of > systemd-pcrextend in systemd is: it's just a binary that is invoked by > systemd-pcrphase*.service, systemd-pcrmachine.service, > [email protected], as mentioned above. But those only make sense > if you have a full boot chain of measurements, i.e. the ones sd-stub > does. > > Lennart > > -- > Lennart Poettering, Berlin > Oh we do, its just that our building and booting stuff it's a bit out of the normal distros stuff for USI, so we have to accomodate this to our liking and build process. Thanks for the info! I'll carry those patches locally so we can keep building systemd and systemd-boot separately with all the needed pieces. Thanks for your time!
