Hi All, During the first half of 2018 I wrote a patch series to the Linux EFI and firmware-loader code, which allows loading peripheral firmware which is embedded/hidden inside the EFI firmware through the standard firmware-loading mechanism. The main motivation for this is to get the touchscreen to work OOTB on various cheap x86 tablets which come with a touchscreen controller which need to have device(model)-specific firmware loaded; and we have been unable to acquire permission to re-distribute this firmware-s in linux-firmware. This patch series works by extending the per model touchscreen data which we already built into the kernel in drivers/platform/x86/touchscreen_dmi.c with some extra info: a 8 byte header to search for, the lenght of the firmware image and a the expected hash of the firmware for that model. During boot, after setting up memory management (so that kmalloc work) and before calling all the various init functions such as subsys_init calls from rest_init, the EFI code does a DMI check and if the system in question is in the list of systems with EFI embedded fw which we want i tgoes over all EFI_BOOT_SERVICES_CODE sections searching for the described firmware. After 6 revisions this series stalled on the lack of a hash algorithm which can be used during early boot. The plan was to wait for the zinc crypto code to get used and use a hash algorithm from that, but that still has not happened, which is my main reason for sending out this email. For the last couple of revisions of the patch set I've been using a set of patches by Andy Lutomirski which make the sha256-generic code usable without calling crypto_alloc_shash() etc. Using crypto_alloc_shash() is not possible because that depends on crypto_register_shash having been called which is done as a subsys_initcall() and thus too late. I cannot move the efi_check_for_embedded_firmwares() call later for 2 reasons: 1) Some of the subsys_init calls may rely on some of the embedded firmwares 2) It needs to be one before efi_free_boot_services() gets called, which is not something which can safely / easily be moved to a later stage. So my question is, would it be possible for the patches from Andy (which I'm sending together with this email) to get merged so that there is a generic secure hash available before subsys_initcall() time; or do you (the crypto maintainers) have any other idea how to solve this? Note I'm open to changing to a different hash function, the hashes are embedded into drivers/platform/x86/touchscreen_dmi.c and I've access to dumps of all firmwares for which I want to initially add support so I can calculate another hash for the files. Regards, Hans
