wireguard-linux/drivers/firmware/efi/Makefile, branch jd/unified-crypt-queue

efi/libstub: Avoid linking libstub/lib-ksyms.o into vmlinux

2020-03-08T09:00:06Z

drivers/firmware/efi/libstub/Makefile builds a static library, which is not linked into the main vmlinux target in the ordinary way [arm64], or at all [ARM, x86]. Since commit: 7f2084fa55e6 ("[kbuild] handle exports in lib-y objects reliably") any Makefile using lib-y generates lib-ksyms.o which is linked into vmlinux. In this case, the following garbage object is linked into vmlinux. drivers/firmware/efi/libstub/lib-ksyms.o We do not want to follow the default linking rules for static libraries built under libstub/ so using subdir-y instead of obj-y is the correct way to descend into this directory. Signed-off-by: Masahiro Yamada Signed-off-by: Ard Biesheuvel [ardb: update commit log to clarify that arm64 deviates in this respect] Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20200305055047.6097-1-masahiroy@kernel.org Link: https://lore.kernel.org/r/20200308080859.21568-23-ardb@kernel.org

Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/core

2020-03-08T08:23:36Z

More EFI updates for v5.7 - Incorporate a stable branch with the EFI pieces of Hans's work on loading device firmware from EFI boot service memory regions Signed-off-by: Ingo Molnar

efi: Add embedded peripheral firmware support

2020-03-03T09:28:00Z

Just like with PCI options ROMs, which we save in the setup_efi_pci* functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself sometimes may contain data which is useful/necessary for peripheral drivers to have access to. Specifically the EFI code may contain an embedded copy of firmware which needs to be (re)loaded into the peripheral. Normally such firmware would be part of linux-firmware, but in some cases this is not feasible, for 2 reasons: 1) The firmware is customized for a specific use-case of the chipset / use with a specific hardware model, so we cannot have a single firmware file for the chipset. E.g. touchscreen controller firmwares are compiled specifically for the hardware model they are used with, as they are calibrated for a specific model digitizer. 2) Despite repeated attempts we have failed to get permission to redistribute the firmware. This is especially a problem with customized firmwares, these get created by the chip vendor for a specific ODM and the copyright may partially belong with the ODM, so the chip vendor cannot give a blanket permission to distribute these. This commit adds support for finding peripheral firmware embedded in the EFI code and makes the found firmware available through the new efi_get_embedded_fw() function. Support for loading these firmwares through the standard firmware loading mechanism is added in a follow-up commit in this patch-series. Note we check the EFI_BOOT_SERVICES_CODE for embedded firmware near the end of start_kernel(), just before calling rest_init(), this is on purpose because the typical EFI_BOOT_SERVICES_CODE memory-segment is too large for early_memremap(), so the check must be done after mm_init(). This relies on EFI_BOOT_SERVICES_CODE not being free-ed until efi_free_boot_services() is called, which means that this will only work on x86 for now. Reported-by: Dave Olsthoorn Suggested-by: Peter Jones Acked-by: Ard Biesheuvel Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20200115163554.101315-3-hdegoede@redhat.com Signed-off-by: Ard Biesheuvel

efi/arm: Move FDT param discovery code out of efi.c

2020-02-23T20:59:42Z

On ARM systems, we discover the UEFI system table address and memory map address from the /chosen node in the device tree, or in the Xen case, from a similar node under /hypervisor. Before making some functional changes to that code, move it into its own file that only gets built if CONFIG_EFI_PARAMS_FROM_FDT=y. Signed-off-by: Ard Biesheuvel

x86/efi: Add efi_fake_mem support for EFI_MEMORY_SP

2019-11-07T14:44:23Z

Given that EFI_MEMORY_SP is platform BIOS policy decision for marking memory ranges as "reserved for a specific purpose" there will inevitably be scenarios where the BIOS omits the attribute in situations where it is desired. Unlike other attributes if the OS wants to reserve this memory from the kernel the reservation needs to happen early in init. So early, in fact, that it needs to happen before e820__memblock_setup() which is a pre-requisite for efi_fake_memmap() that wants to allocate memory for the updated table. Introduce an x86 specific efi_fake_memmap_early() that can search for attempts to set EFI_MEMORY_SP via efi_fake_mem and update the e820 table accordingly. The KASLR code that scans the command line looking for user-directed memory reservations also needs to be updated to consider "efi_fake_mem=nn@ss:0x40000" requests. Acked-by: Ard Biesheuvel Reviewed-by: Dave Hansen Signed-off-by: Dan Williams Acked-by: Thomas Gleixner Signed-off-by: Rafael J. Wysocki

efi: Export Runtime Configuration Interface table to sysfs

2019-08-08T08:10:25Z

System firmware advertises the address of the 'Runtime Configuration Interface table version 2 (RCI2)' via an EFI Configuration Table entry. This code retrieves the RCI2 table from the address and exports it to sysfs as a binary attribute 'rci2' under /sys/firmware/efi/tables directory. The approach adopted is similar to the attribute 'DMI' under /sys/firmware/dmi/tables. RCI2 table contains BIOS HII in XML format and is used to populate BIOS setup page in Dell EMC OpenManage Server Administrator tool. The BIOS setup page contains BIOS tokens which can be configured. Signed-off-by: Narendra K Reviewed-by: Mario Limonciello Signed-off-by: Ard Biesheuvel

efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation

2019-02-04T07:27:30Z

Move the x86 EFI earlyprintk implementation to a shared location under drivers/firmware and tweak it slightly so we can expose it as an earlycon implementation (which is generic) rather than earlyprintk (which is only implemented for a few architectures) This also involves switching to write-combine mappings by default (which is required on ARM since device mappings lack memory semantics, and so memcpy/memset may not be used on them), and adding support for shared memory framebuffers on cache coherent non-x86 systems (which do not tolerate mismatched attributes). Note that 32-bit ARM does not populate its struct screen_info early enough for earlycon=efifb to work, so it is disabled there. Signed-off-by: Ard Biesheuvel Reviewed-by: Alexander Graf Cc: AKASHI Takahiro Cc: Bjorn Andersson Cc: Borislav Petkov Cc: Heinrich Schuchardt Cc: Jeffrey Hugo Cc: Lee Jones Cc: Leif Lindholm Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Jones Cc: Peter Zijlstra Cc: Sai Praneeth Prakhya Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20190202094119.13230-10-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar

efi: Decode IA32/X64 Processor Error Section

2018-05-14T06:57:47Z

Recognize the IA32/X64 Processor Error Section. Do the section decoding in a new "cper-x86.c" file and add this to the Makefile depending on a new "UEFI_CPER_X86" config option. Print the Local APIC ID and CPUID info from the Processor Error Record. The "Processor Error Info" and "Processor Context" fields will be decoded in following patches. Based on UEFI 2.7 Table 252. Processor Error Record. Signed-off-by: Yazen Ghannam Signed-off-by: Ard Biesheuvel Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180504060003.19618-5-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar

Merge branch 'next-tpm' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security

2018-01-31T21:12:31Z

Pull tpm updates from James Morris: - reduce polling delays in tpm_tis - support retrieving TPM 2.0 Event Log through EFI before ExitBootServices - replace tpm-rng.c with a hwrng device managed by the driver for each TPM device - TPM resource manager synthesizes TPM_RC_COMMAND_CODE response instead of returning -EINVAL for unknown TPM commands. This makes user space more sound. - CLKRUN fixes: * Keep #CLKRUN disable through the entier TPM command/response flow * Check whether #CLKRUN is enabled before disabling and enabling it again because enabling it breaks PS/2 devices on a system where it is disabled * 'next-tpm' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: tpm: remove unused variables tpm: remove unused data fields from I2C and OF device ID tables tpm: only attempt to disable the LPC CLKRUN if is already enabled tpm: follow coding style for variable declaration in tpm_tis_core_init() tpm: delete the TPM_TIS_CLK_ENABLE flag tpm: Update MAINTAINERS for Jason Gunthorpe tpm: Keep CLKRUN enabled throughout the duration of transmit_cmd() tpm_tis: Move ilb_base_addr to tpm_tis_data tpm2-cmd: allow more attempts for selftest execution tpm: return a TPM_RC_COMMAND_CODE response if command is not implemented tpm: Move Linux RNG connection to hwrng tpm: use struct tpm_chip for tpm_chip_find_get() tpm: parse TPM event logs based on EFI table efi: call get_event_log before ExitBootServices tpm: add event log format version tpm: rename event log provider files tpm: move tpm_eventlog.h outside of drivers folder tpm: use tpm_msleep() value as max delay tpm: reduce tpm polling delay in tpm_tis_core tpm: move wait_for_tpm_stat() to respective driver files

efi: call get_event_log before ExitBootServices

2018-01-08T10:58:35Z

With TPM 2.0 specification, the event logs may only be accessible by calling an EFI Boot Service. Modify the EFI stub to copy the log area to a new Linux-specific EFI configuration table so it remains accessible once booted. When calling this service, it is possible to specify the expected format of the logs: TPM 1.2 (SHA1) or TPM 2.0 ("Crypto Agile"). For now, only the first format is retrieved. Signed-off-by: Thiebaud Weksteen Reviewed-by: Javier Martinez Canillas Tested-by: Javier Martinez Canillas Tested-by: Jarkko Sakkinen Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen