> There is the problem with the new bli module, that it requires the > part_gpt module to be loaded beforehand, but the module dependency list > for bli is emplty (see moddep.lst). > > The part_gpt module only exports one function, > grub_gpt_partition_map_iterate(). This is not used in the bli module. > However, if part_gpt is not loaded grub does not know how to work with > gpt formatted disks and these are not visible. > The bli module then can't use grub_device_open(), grub_disk_open(), etc. > to get the partition UUID of the ESP. > > Adding this dummy call to bli.c causes part_gpt to appear as a > dependency: > (void) grub_gpt_partition_map_iterate (NULL, NULL, NULL); > > Thanks, I understand the problem now.
Yeah, I had a similar problem when developing appended signature support: https://lists.gnu.org/archive/html/grub-devel/2020-10/msg00016.html +/* + * Force gcry_rsa to be a module dependency. + * + * If we use grub_crypto_pk_rsa, then then the gcry_rsa module won't be built + * in if you add 'appendedsig' to grub-install --modules. You would need to + * add 'gcry_rsa' too. That's confusing and seems suboptimal, especially when + * we only support RSA. + * + * Dynamic loading also causes some concerns. We can't load gcry_rsa from the + * the filesystem after we install the verifier - we won't be able to verify + * it without having it already present. We also shouldn't load it before we + * install the verifier, because that would mean it wouldn't be verified - an + * attacker could insert any code they wanted into the module. + * + * So instead, reference the internal symbol from gcry_rsa. That creates a + * direct dependency on gcry_rsa, so it will be built in when this module + * is built in. Being built in (assuming the core image is itself signed!) + * also resolves our concerns about loading from the filesystem. + */ +extern gcry_pk_spec_t _gcry_pubkey_spec_rsa; Offtopic, but one of my wild ideas for grub is that maybe it’s time to move towards allowing modules to be directly built in rather than the current system where “built in” modules are just stored in a different section of an elf binary and are still basically dynamically loaded. A more static binary would make more sense in an UEFI universe, especially for secure boot. We would probably need to bring in an explicit dependency specification and management system like Kconfig at the same time - which would solve your issue more cleanly. (It also makes building Rust support - which is what I _actually_ want to do - much easier.) Good luck with your work. Kind regards, Daniel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
