Revision tags: v5.4.20 |
|
#
f7b85b33 |
| 14-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub/x86: Make loaded_image protocol handling mixed mode safe
Add the definitions and use the special wrapper so that the loaded_image UEFI protocol can be safely used from mixed mode.
Signe
efi/libstub/x86: Make loaded_image protocol handling mixed mode safe
Add the definitions and use the special wrapper so that the loaded_image UEFI protocol can be safely used from mixed mode.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.4.19, v5.4.18 |
|
#
79d3219d |
| 04-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Take noinitrd cmdline argument into account for devpath initrd
One of the advantages of using what basically amounts to a callback interface into the bootloader for loading the initrd i
efi/libstub: Take noinitrd cmdline argument into account for devpath initrd
One of the advantages of using what basically amounts to a callback interface into the bootloader for loading the initrd is that it provides a natural place for the bootloader or firmware to measure the initrd contents while they are being passed to the kernel.
Unfortunately, this is not a guarantee that the initrd will in fact be loaded and its /init invoked by the kernel, since the command line may contain the 'noinitrd' option, in which case the initrd is ignored, but this will not be reflected in the PCR that covers the initrd measurement.
This could be addressed by measuring the command line as well, and including that PCR in the attestation policy, but this locks down the command line completely, which may be too restrictive.
So let's take the noinitrd argument into account in the stub, too. This forces any PCR that covers the initrd to assume a different value when noinitrd is passed, allowing an attestation policy to disregard the command line if there is no need to take its measurement into account for other reasons.
As Peter points out, this would still require the agent that takes the measurements to measure a separator event into the PCR in question at ExitBootServices() time, to prevent replay attacks using the known measurement from the TPM log.
Cc: Peter Jones <pjones@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
ec93fc37 |
| 03-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Add support for loading the initrd from a device path
There are currently two ways to specify the initrd to be passed to the Linux kernel when booting via the EFI stub: - it can be pass
efi/libstub: Add support for loading the initrd from a device path
There are currently two ways to specify the initrd to be passed to the Linux kernel when booting via the EFI stub: - it can be passed as a initrd= command line option when doing a pure PE boot (as opposed to the EFI handover protocol that exists for x86) - otherwise, the bootloader or firmware can load the initrd into memory, and pass the address and size via the bootparams struct (x86) or device tree (ARM)
In the first case, we are limited to loading from the same file system that the kernel was loaded from, and it is also problematic in a trusted boot context, given that we cannot easily protect the command line from tampering without either adding complicated white/blacklisting of boot arguments or locking down the command line altogether.
In the second case, we force the bootloader to duplicate knowledge about the boot protocol which is already encoded in the stub, and which may be subject to change over time, e.g., bootparams struct definitions, memory allocation/alignment requirements for the placement of the initrd etc etc. In the ARM case, it also requires the bootloader to modify the hardware description provided by the firmware, as it is passed in the same file. On systems where the initrd is measured after loading, it creates a time window where the initrd contents might be manipulated in memory before handing over to the kernel.
Address these concerns by adding support for loading the initrd into memory by invoking the EFI LoadFile2 protocol installed on a vendor GUIDed device path that specifically designates a Linux initrd. This addresses the above concerns, by putting the EFI stub in charge of placement in memory and of passing the base and size to the kernel proper (via whatever means it desires) while still leaving it up to the firmware or bootloader to obtain the file contents, potentially from other file systems than the one the kernel itself was loaded from. On platforms that implement measured boot, it permits the firmware to take the measurement right before the kernel actually consumes the contents.
Acked-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
2931d526 |
| 10-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Make the LoadFile EFI protocol accessible
Add the protocol definitions, GUIDs and mixed mode glue so that the EFI loadfile protocol can be used from the stub. This will be used in a fut
efi/libstub: Make the LoadFile EFI protocol accessible
Add the protocol definitions, GUIDs and mixed mode glue so that the EFI loadfile protocol can be used from the stub. This will be used in a future patch to load the initrd.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
abd26868 |
| 10-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Expose LocateDevicePath boot service
We will be adding support for loading the initrd from a GUIDed device path in a subsequent patch, so update the prototype of the LocateDevicePath()
efi/libstub: Expose LocateDevicePath boot service
We will be adding support for loading the initrd from a GUIDed device path in a subsequent patch, so update the prototype of the LocateDevicePath() boot service to make it callable from our code.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
31f5e546 |
| 10-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Take soft and hard memory limits into account for initrd loading
On x86, the preferred load address of the initrd is still below 4 GB, even though in some cases, we can cope with an ini
efi/libstub: Take soft and hard memory limits into account for initrd loading
On x86, the preferred load address of the initrd is still below 4 GB, even though in some cases, we can cope with an initrd that is loaded above that.
To simplify the code, and to make it more straightforward to introduce other ways to load the initrd, pass the soft and hard memory limits at the same time, and let the code handling the initrd= command line option deal with this.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
9302c1bb |
| 10-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Rewrite file I/O routine
The file I/O routine that is used to load initrd or dtb files from the EFI system partition suffers from a few issues: - it converts the u8[] command line back
efi/libstub: Rewrite file I/O routine
The file I/O routine that is used to load initrd or dtb files from the EFI system partition suffers from a few issues: - it converts the u8[] command line back to a UTF-16 string, which is pointless since we only handle initrd or dtb arguments provided via the loaded image protocol anyway, which is where we got the UTF-16[] command line from in the first place when booting via the PE entry point, - in the far majority of cases, only a single initrd= option is present, but it optimizes for multiple options, by going over the command line twice, allocating heap buffers for dynamically sized arrays, etc. - the coding style is hard to follow, with few comments, and all logic including string parsing etc all combined in a single routine.
Let's fix this by rewriting most of it, based on the idea that in the case of multiple initrds, we can just allocate a new, bigger buffer and copy over the data before freeing the old one.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
5193a33d |
| 10-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Move file I/O support code into separate file
Split off the file I/O support code into a separate source file so it ends up in a separate object file in the static library, allowing the
efi/libstub: Move file I/O support code into separate file
Split off the file I/O support code into a separate source file so it ends up in a separate object file in the static library, allowing the linker to omit it if the routines are not used.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
b8717454 |
| 10-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Move get_dram_base() into arm-stub.c
get_dram_base() is only called from arm-stub.c so move it into the same source file as its caller.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
#
1e45bf73 |
| 10-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub/x86: Permit cmdline data to be allocated above 4 GB
We now support cmdline data that is located in memory that is not 32-bit addressable, so relax the allocation limit on systems where t
efi/libstub/x86: Permit cmdline data to be allocated above 4 GB
We now support cmdline data that is located in memory that is not 32-bit addressable, so relax the allocation limit on systems where this feature is enabled.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
8166ec09 |
| 10-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Move stub specific declarations into efistub.h
Move all the declarations that are only used in stub code from linux/efi.h to efistub.h which is only included locally.
Signed-off-by: Ar
efi/libstub: Move stub specific declarations into efistub.h
Move all the declarations that are only used in stub code from linux/efi.h to efistub.h which is only included locally.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
a46a290a |
| 10-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Use consistent type names for file I/O protocols
Align the naming of efi_file_io_interface_t and efi_file_handle_t with the UEFI spec, and call them efi_simple_file_system_protocol_t an
efi/libstub: Use consistent type names for file I/O protocols
Align the naming of efi_file_io_interface_t and efi_file_handle_t with the UEFI spec, and call them efi_simple_file_system_protocol_t and efi_file_protocol_t, respectively, using the same convention we use for all other type definitions that originate in the UEFI spec.
While at it, move the definitions to efistub.h, so they are only seen by code that needs them.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
c2d0b470 |
| 10-Feb-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub/x86: Incorporate eboot.c into libstub
Most of the EFI stub source files of all architectures reside under drivers/firmware/efi/libstub, where they share a Makefile with special CFLAGS an
efi/libstub/x86: Incorporate eboot.c into libstub
Most of the EFI stub source files of all architectures reside under drivers/firmware/efi/libstub, where they share a Makefile with special CFLAGS and an include file with declarations that are only relevant for stub code.
Currently, we carry a lot of stub specific stuff in linux/efi.h only because eboot.c in arch/x86 needs them as well. So let's move eboot.c into libstub/, and move the contents of eboot.h that we still care about into efistub.h
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7 |
|
#
7d4e323d |
| 24-Dec-2019 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Tidy up types and names of global cmdline variables
Drop leading underscores and use bool not int for true/false variables set on the command line.
Signed-off-by: Ard Biesheuvel <ardb@
efi/libstub: Tidy up types and names of global cmdline variables
Drop leading underscores and use bool not int for true/false variables set on the command line.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-25-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
#
966291f6 |
| 24-Dec-2019 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Rename efi_call_early/_runtime macros to be more intuitive
The macros efi_call_early and efi_call_runtime are used to call EFI boot services and runtime services, respectively. However,
efi/libstub: Rename efi_call_early/_runtime macros to be more intuitive
The macros efi_call_early and efi_call_runtime are used to call EFI boot services and runtime services, respectively. However, the naming is confusing, given that the early vs runtime distinction may suggest that these are used for calling the same set of services either early or late (== at runtime), while in reality, the sets of services they can be used with are completely disjoint, and efi_call_runtime is also only usable in 'early' code.
So do a global sweep to replace all occurrences with efi_bs_call or efi_rt_call, respectively, where BS and RT match the idiom used by the UEFI spec to refer to boot time or runtime services.
While at it, use 'func' as the macro parameter name for the function pointers, which is less likely to collide and cause weird build errors.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-24-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
#
cd33a5c1 |
| 24-Dec-2019 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Remove 'sys_table_arg' from all function prototypes
We have a helper efi_system_table() that gives us the address of the EFI system table in memory, so there is no longer point in passi
efi/libstub: Remove 'sys_table_arg' from all function prototypes
We have a helper efi_system_table() that gives us the address of the EFI system table in memory, so there is no longer point in passing it around from each function to the next.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-20-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
#
8173ec79 |
| 24-Dec-2019 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Drop sys_table_arg from printk routines
As a first step towards getting rid of the need to pass around a function parameter 'sys_table_arg' pointing to the EFI system table, remove the
efi/libstub: Drop sys_table_arg from printk routines
As a first step towards getting rid of the need to pass around a function parameter 'sys_table_arg' pointing to the EFI system table, remove the references to it in the printing code, which is represents the majority of the use cases.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-19-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
#
2fcdad2a |
| 24-Dec-2019 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Get rid of 'sys_table_arg' macro parameter
The efi_call macros on ARM have a dependency on a variable 'sys_table_arg' existing in the scope of the macro instantiation. Since this variab
efi/libstub: Get rid of 'sys_table_arg' macro parameter
The efi_call macros on ARM have a dependency on a variable 'sys_table_arg' existing in the scope of the macro instantiation. Since this variable always points to the same data structure, let's create a global getter for it and use that instead.
Note that the use of a global variable with external linkage is avoided, given the problems we had in the past with early processing of the GOT tables.
While at it, drop the redundant casts in the efi_table_attr and efi_call_proto macros.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arvind Sankar <nivedita@alum.mit.edu> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191224151025.32482-16-ardb@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
Revision tags: v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9 |
|
#
0d959814 |
| 06-Nov-2019 |
Dominik Brodowski <linux@dominikbrodowski.net> |
x86: efi/random: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table
Invoke the EFI_RNG_PROTOCOL protocol in the context of the x86 EFI stub, same as is done on arm/arm64 since commit 568bc4e87033 ("
x86: efi/random: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table
Invoke the EFI_RNG_PROTOCOL protocol in the context of the x86 EFI stub, same as is done on arm/arm64 since commit 568bc4e87033 ("efi/arm*/libstub: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table"). Within the stub, a Linux-specific RNG seed UEFI config table will be seeded. The EFI routines in the core kernel will pick that up later, yet still early during boot, to seed the kernel entropy pool. If CONFIG_RANDOM_TRUST_BOOTLOADER, entropy is credited for this seed.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8 |
|
#
82d736ac |
| 07-Jun-2019 |
Matthew Garrett <matthewgarrett@google.com> |
Abstract out support for locating an EFI config table
We want to grab a pointer to the TPM final events table, so abstract out the existing code for finding an FDT table and make it generic.
Signed
Abstract out support for locating an EFI config table
We want to grab a pointer to the TPM final events table, so abstract out the existing code for finding an FDT table and make it generic.
Signed-off-by: Matthew Garrett <mjg59@google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
show more ...
|
Revision tags: v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20 |
|
#
4e46c2a9 |
| 02-Feb-2019 |
Ard Biesheuvel <ard.biesheuvel@linaro.org> |
efi/arm/arm64: Allow SetVirtualAddressMap() to be omitted
The UEFI spec revision 2.7 errata A section 8.4 has the following to say about the virtual memory runtime services:
"This section contain
efi/arm/arm64: Allow SetVirtualAddressMap() to be omitted
The UEFI spec revision 2.7 errata A section 8.4 has the following to say about the virtual memory runtime services:
"This section contains function definitions for the virtual memory support that may be optionally used by an operating system at runtime. If an operating system chooses to make EFI runtime service calls in a virtual addressing mode instead of the flat physical mode, then the operating system must use the services in this section to switch the EFI runtime services from flat physical addressing to virtual addressing."
So it is pretty clear that calling SetVirtualAddressMap() is entirely optional, and so there is no point in doing so unless it achieves anything useful for us.
This is not the case for 64-bit ARM. The identity mapping used by the firmware is arbitrarily converted into another permutation of userland addresses (i.e., bits [63:48] cleared), and the runtime code could easily deal with the original layout in exactly the same way as it deals with the converted layout. However, due to constraints related to page size differences if the OS is not running with 4k pages, and related to systems that may expose the individual sections of PE/COFF runtime modules as different memory regions, creating the virtual layout is a bit fiddly, and requires us to sort the memory map and reason about adjacent regions with identical memory types etc etc.
So the obvious fix is to stop calling SetVirtualAddressMap() altogether on arm64 systems. However, to avoid surprises, which are notoriously hard to diagnose when it comes to OS<->firmware interactions, let's start by making it an opt-out feature, and implement support for the 'efi=novamap' kernel command line parameter on ARM and arm64 systems.
( Note that 32-bit ARM generally does require SetVirtualAddressMap() to be used, given that the physical memory map and the kernel virtual address map are not guaranteed to be non-overlapping like on arm64. However, having support for efi=novamap,noruntime on 32-bit ARM, combined with the recently proposed support for earlycon=efifb, is likely to be useful to diagnose boot issues on such systems if they have no accessible serial port. )
Tested-by: Jeffrey Hugo <jhugo@codeaurora.org> Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org> Cc: Alexander Graf <agraf@suse.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20190202094119.13230-8-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
#
ac9aff8e |
| 02-Feb-2019 |
Ingo Molnar <mingo@kernel.org> |
efi/fdt: Apply more cleanups
Apply a number of cleanups:
- Introduce fdt_setprop_*var() helper macros to simplify and shorten repetitive sequences - this also makes it less likely that the wron
efi/fdt: Apply more cleanups
Apply a number of cleanups:
- Introduce fdt_setprop_*var() helper macros to simplify and shorten repetitive sequences - this also makes it less likely that the wrong variable size is passed in. This change makes a lot of the property-setting calls single-line and easier to read.
- Harmonize comment style: capitalization, punctuation, whitespaces, etc.
- Fix some whitespace noise in the libstub Makefile which I happened to notice.
- Use the standard tabular initialization style:
- map.map = &runtime_map; - map.map_size = &map_size; - map.desc_size = &desc_size; - map.desc_ver = &desc_ver; - map.key_ptr = &mmap_key; - map.buff_size = &buff_size;
+ map.map = &runtime_map; + map.map_size = &map_size; + map.desc_size = &desc_size; + map.desc_ver = &desc_ver; + map.key_ptr = &mmap_key; + map.buff_size = &buff_size;
- Use tabular structure definition for better readability.
- Make all pr*() lines single-line, even if they marginally exceed 80 cols - this makes them visually less intrusive.
- Unbreak line breaks into single lines when the length exceeds 80 cols only marginally, for better readability.
- Move assignment closer to the actual usage site.
- Plus some other smaller cleanups, spelling fixes, etc.
No change in functionality intended.
[ ardb: move changes to upstream libfdt into local header. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org> Cc: Alexander Graf <agraf@suse.de> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Jones <pjones@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20190202094119.13230-6-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
Revision tags: v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9 |
|
#
c4db9c1e |
| 19-Jul-2018 |
Lukas Wunner <lukas@wunner.de> |
efi: Deduplicate efi_open_volume()
There's one ARM, one x86_32 and one x86_64 version of efi_open_volume() which can be folded into a single shared version by masking their differences with the efi_
efi: Deduplicate efi_open_volume()
There's one ARM, one x86_32 and one x86_64 version of efi_open_volume() which can be folded into a single shared version by masking their differences with the efi_call_proto() macro introduced by commit:
3552fdf29f01 ("efi: Allow bitness-agnostic protocol calls").
To be able to dereference the device_handle attribute from the efi_loaded_image_t table in an arch- and bitness-agnostic manner, introduce the efi_table_attr() macro (which already exists for x86) to arm and arm64.
No functional change intended.
Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20180720014726.24031-7-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
Revision tags: v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15, v4.13.16, v4.14 |
|
#
b2441318 |
| 01-Nov-2017 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine
License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license identifiers to apply.
- when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary:
SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became the concluded license(s).
- when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.
In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related.
Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v4.13.5, v4.13, v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9 |
|
#
eeff7d63 |
| 04-Apr-2017 |
Ard Biesheuvel <ard.biesheuvel@linaro.org> |
efi/libstub/arm/arm64: Disable debug prints on 'quiet' cmdline arg
The EFI stub currently prints a number of diagnostic messages that do not carry a lot of information. Since these prints are not co
efi/libstub/arm/arm64: Disable debug prints on 'quiet' cmdline arg
The EFI stub currently prints a number of diagnostic messages that do not carry a lot of information. Since these prints are not controlled by 'loglevel' or other command line parameters, and since they appear on the EFI framebuffer as well (if enabled), it would be nice if we could turn them off.
So let's add support for the 'quiet' command line parameter in the stub, and disable the non-error prints if it is passed.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: bhe@redhat.com Cc: bhsharma@redhat.com Cc: bp@alien8.de Cc: eugene@hp.com Cc: evgeny.kalugin@intel.com Cc: jhugo@codeaurora.org Cc: leif.lindholm@linaro.org Cc: linux-efi@vger.kernel.org Cc: roy.franz@cavium.com Cc: rruigrok@codeaurora.org Link: http://lkml.kernel.org/r/20170404160910.28115-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|