[RFC 0/3] Making a secure hash function avaiable during early boot?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux