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. > 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
