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>
2017-11-01 15:07:57 +01:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
2014-07-02 14:54:43 +02:00
|
|
|
#
|
|
|
|
|
# The stub may be linked into the kernel proper or into a separate boot binary,
|
|
|
|
|
# but in either case, it executes before the kernel does (with MMU disabled) so
|
|
|
|
|
# things like ftrace and stack-protector are likely to cause trouble if left
|
|
|
|
|
# enabled, even if doing so doesn't break the build.
|
|
|
|
|
#
|
2022-10-12 09:53:40 +02:00
|
|
|
|
|
|
|
|
# non-x86 reuses KBUILD_CFLAGS, x86 does not
|
|
|
|
|
cflags-y := $(KBUILD_CFLAGS)
|
|
|
|
|
|
2014-07-02 14:54:43 +02:00
|
|
|
cflags-$(CONFIG_X86_32) := -march=i386
|
2020-07-09 09:59:57 +03:00
|
|
|
cflags-$(CONFIG_X86_64) := -mcmodel=small
|
2025-01-21 18:11:34 -07:00
|
|
|
cflags-$(CONFIG_X86) += -m$(BITS) -D__KERNEL__ -std=gnu11 \
|
2014-07-02 14:54:43 +02:00
|
|
|
-fPIC -fno-strict-aliasing -mno-red-zone \
|
2018-11-29 18:12:26 +01:00
|
|
|
-mno-mmx -mno-sse -fshort-wchar \
|
|
|
|
|
-Wno-pointer-sign \
|
|
|
|
|
$(call cc-disable-warning, address-of-packed-member) \
|
2020-02-24 18:21:28 -05:00
|
|
|
$(call cc-disable-warning, gnu) \
|
2021-03-25 17:04:35 -07:00
|
|
|
-fno-asynchronous-unwind-tables \
|
|
|
|
|
$(CLANG_FLAGS)
|
2014-07-02 14:54:43 +02:00
|
|
|
|
2018-07-30 11:31:18 -07:00
|
|
|
# arm64 uses the full KBUILD_CFLAGS so it's necessary to explicitly
|
|
|
|
|
# disable the stackleak plugin
|
2025-07-17 16:25:06 -07:00
|
|
|
cflags-$(CONFIG_ARM64) += -fpie $(DISABLE_KSTACK_ERASE) \
|
2023-04-18 15:49:48 +02:00
|
|
|
-fno-unwind-tables -fno-asynchronous-unwind-tables
|
2022-10-11 15:27:45 +02:00
|
|
|
cflags-$(CONFIG_ARM) += -DEFI_HAVE_STRLEN -DEFI_HAVE_STRNLEN \
|
2022-10-11 18:21:52 +02:00
|
|
|
-DEFI_HAVE_MEMCHR -DEFI_HAVE_STRRCHR \
|
|
|
|
|
-DEFI_HAVE_STRCMP -fno-builtin -fpic \
|
2024-06-27 08:38:44 +01:00
|
|
|
$(call cc-option,-mno-single-pic-base) \
|
2025-07-17 16:25:06 -07:00
|
|
|
$(DISABLE_KSTACK_ERASE)
|
2024-06-24 07:53:16 +08:00
|
|
|
cflags-$(CONFIG_RISCV) += -fpic -DNO_ALTERNATIVE -mno-relax \
|
2025-07-17 16:25:06 -07:00
|
|
|
$(DISABLE_KSTACK_ERASE)
|
|
|
|
|
cflags-$(CONFIG_LOONGARCH) += -fpie $(DISABLE_KSTACK_ERASE)
|
2014-07-02 14:54:43 +02:00
|
|
|
|
efi/loongarch: libstub: remove dependency on flattened DT
LoongArch does not use FDT or DT natively [yet], and the only reason it
currently uses it is so that it can reuse the existing EFI stub code.
Overloading the DT with data passed between the EFI stub and the core
kernel has been a source of problems: there is the overlap between
information provided by EFI which DT can also provide (initrd base/size,
command line, memory descriptions), requiring us to reason about which
is which and what to prioritize. It has also resulted in ABI leaks,
i.e., internal ABI being promoted to external ABI inadvertently because
the bootloader can set the EFI stub's DT properties as well (e.g.,
"kaslr-seed"). This has become especially problematic with boot
environments that want to pretend that EFI boot is being done (to access
ACPI and SMBIOS tables, for instance) but have no ability to execute the
EFI stub, and so the environment that the EFI stub creates is emulated
[poorly, in some cases].
Another downside of treating DT like this is that the DT binary that the
kernel receives is different from the one created by the firmware, which
is undesirable in the context of secure and measured boot.
Given that LoongArch support in Linux is brand new, we can avoid these
pitfalls, and treat the DT strictly as a hardware description, and use a
separate handover method between the EFI stub and the kernel. Now that
initrd loading and passing the EFI memory map have been refactored into
pure EFI routines that use EFI configuration tables, the only thing we
need to pass directly is the kernel command line (even if we could pass
this via a config table as well, it is used extremely early, so passing
it directly is preferred in this case.)
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Huacai Chen <chenhuacai@loongson.cn>
2022-09-16 19:48:53 +02:00
|
|
|
cflags-$(CONFIG_EFI_PARAMS_FROM_FDT) += -I$(srctree)/scripts/dtc/libfdt
|
2015-10-08 20:02:04 +01:00
|
|
|
|
2022-10-12 09:53:40 +02:00
|
|
|
KBUILD_CFLAGS := $(subst $(CC_FLAGS_FTRACE),,$(cflags-y)) \
|
|
|
|
|
-Os -DDISABLE_BRANCH_PROFILING \
|
2020-07-31 16:07:46 -07:00
|
|
|
-include $(srctree)/include/linux/hidden.h \
|
2017-07-12 14:35:55 -07:00
|
|
|
-D__NO_FORTIFY \
|
2020-06-27 03:59:13 +09:00
|
|
|
-ffreestanding \
|
2020-06-27 03:59:12 +09:00
|
|
|
-fno-stack-protector \
|
2020-05-04 10:06:29 +02:00
|
|
|
$(call cc-option,-fno-addrsig) \
|
2018-08-21 21:56:04 -07:00
|
|
|
-D__DISABLE_EXPORTS
|
2014-07-02 14:54:43 +02:00
|
|
|
|
2022-08-22 19:20:33 +02:00
|
|
|
#
|
|
|
|
|
# struct randomization only makes sense for Linux internal types, which the EFI
|
|
|
|
|
# stub code never touches, so let's turn off struct randomization for the stub
|
|
|
|
|
# altogether
|
|
|
|
|
#
|
|
|
|
|
KBUILD_CFLAGS := $(filter-out $(RANDSTRUCT_CFLAGS), $(KBUILD_CFLAGS))
|
|
|
|
|
|
2020-04-27 09:00:18 -07:00
|
|
|
# remove SCS flags from all objects in this directory
|
|
|
|
|
KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_SCS), $(KBUILD_CFLAGS))
|
2022-09-08 14:54:43 -07:00
|
|
|
# disable CFI
|
|
|
|
|
KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_CFI), $(KBUILD_CFLAGS))
|
2020-12-11 10:46:29 -08:00
|
|
|
# disable LTO
|
|
|
|
|
KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_LTO), $(KBUILD_CFLAGS))
|
2020-04-27 09:00:18 -07:00
|
|
|
|
2024-06-03 16:37:50 +01:00
|
|
|
# The .data section would be renamed to .data.efistub, therefore, remove
|
|
|
|
|
# `-fdata-sections` flag from KBUILD_CFLAGS_KERNEL
|
|
|
|
|
KBUILD_CFLAGS_KERNEL := $(filter-out -fdata-sections, $(KBUILD_CFLAGS_KERNEL))
|
|
|
|
|
|
2025-01-07 18:16:59 +01:00
|
|
|
KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__
|
|
|
|
|
|
2019-11-06 08:06:13 +01:00
|
|
|
lib-y := efi-stub-helper.o gop.o secureboot.o tpm.o \
|
efi/libstub: Clean up command line parsing routine
We currently parse the command non-destructively, to avoid having to
allocate memory for a copy before passing it to the standard parsing
routines that are used by the core kernel, and which modify the input
to delineate the parsed tokens with NUL characters.
Instead, we call strstr() and strncmp() to go over the input multiple
times, and match prefixes rather than tokens, which implies that we
would match, e.g., 'nokaslrfoo' in the stub and disable KASLR, while
the kernel would disregard the option and run with KASLR enabled.
In order to avoid having to reason about whether and how this behavior
may be abused, let's clean up the parsing routines, and rebuild them
on top of the existing helpers.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-02-10 17:02:46 +01:00
|
|
|
file.o mem.o random.o randomalloc.o pci.o \
|
2020-03-27 16:09:40 +01:00
|
|
|
skip_spaces.o lib-cmdline.o lib-ctype.o \
|
2022-10-11 15:27:45 +02:00
|
|
|
alignedmem.o relocate.o printk.o vsprintf.o
|
2015-10-08 20:02:04 +01:00
|
|
|
|
efi/loongarch: libstub: remove dependency on flattened DT
LoongArch does not use FDT or DT natively [yet], and the only reason it
currently uses it is so that it can reuse the existing EFI stub code.
Overloading the DT with data passed between the EFI stub and the core
kernel has been a source of problems: there is the overlap between
information provided by EFI which DT can also provide (initrd base/size,
command line, memory descriptions), requiring us to reason about which
is which and what to prioritize. It has also resulted in ABI leaks,
i.e., internal ABI being promoted to external ABI inadvertently because
the bootloader can set the EFI stub's DT properties as well (e.g.,
"kaslr-seed"). This has become especially problematic with boot
environments that want to pretend that EFI boot is being done (to access
ACPI and SMBIOS tables, for instance) but have no ability to execute the
EFI stub, and so the environment that the EFI stub creates is emulated
[poorly, in some cases].
Another downside of treating DT like this is that the DT binary that the
kernel receives is different from the one created by the firmware, which
is undesirable in the context of secure and measured boot.
Given that LoongArch support in Linux is brand new, we can avoid these
pitfalls, and treat the DT strictly as a hardware description, and use a
separate handover method between the EFI stub and the kernel. Now that
initrd loading and passing the EFI memory map have been refactored into
pure EFI routines that use EFI configuration tables, the only thing we
need to pass directly is the kernel command line (even if we could pass
this via a config table as well, it is used extremely early, so passing
it directly is preferred in this case.)
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Huacai Chen <chenhuacai@loongson.cn>
2022-09-16 19:48:53 +02:00
|
|
|
# include the stub's libfdt dependencies from lib/ when needed
|
|
|
|
|
libfdt-deps := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c \
|
|
|
|
|
fdt_empty_tree.c fdt_sw.c
|
|
|
|
|
|
|
|
|
|
lib-$(CONFIG_EFI_PARAMS_FROM_FDT) += fdt.o \
|
|
|
|
|
$(patsubst %.c,lib-%.o,$(libfdt-deps))
|
2015-10-08 20:02:04 +01:00
|
|
|
|
|
|
|
|
$(obj)/lib-%.o: $(srctree)/lib/%.c FORCE
|
|
|
|
|
$(call if_changed_rule,cc_o_c)
|
|
|
|
|
|
2022-10-11 17:10:39 +02:00
|
|
|
lib-$(CONFIG_EFI_GENERIC_STUB) += efi-stub.o string.o intrinsics.o systable.o \
|
2022-10-12 12:55:11 +02:00
|
|
|
screen_info.o efi-stub-entry.o
|
2014-07-02 14:54:43 +02:00
|
|
|
|
2015-09-23 20:17:54 -07:00
|
|
|
lib-$(CONFIG_ARM) += arm32-stub.o
|
2023-07-22 14:38:48 +02:00
|
|
|
lib-$(CONFIG_ARM64) += kaslr.o arm64.o arm64-stub.o smbios.o
|
2024-07-01 09:35:33 +02:00
|
|
|
lib-$(CONFIG_X86) += x86-stub.o smbios.o
|
2023-08-07 18:27:13 +02:00
|
|
|
lib-$(CONFIG_X86_64) += x86-5lvl.o
|
2023-07-22 14:38:50 +02:00
|
|
|
lib-$(CONFIG_RISCV) += kaslr.o riscv.o riscv-stub.o
|
2022-10-13 12:39:37 +02:00
|
|
|
lib-$(CONFIG_LOONGARCH) += loongarch.o loongarch-stub.o
|
efi/loongarch: Add efistub booting support
This patch adds efistub booting support, which is the standard UEFI boot
protocol for LoongArch to use.
We use generic efistub, which means we can pass boot information (i.e.,
system table, memory map, kernel command line, initrd) via a light FDT
and drop a lot of non-standard code.
We use a flat mapping to map the efi runtime in the kernel's address
space. In efi, VA = PA; in kernel, VA = PA + PAGE_OFFSET. As a result,
flat mapping is not identity mapping, SetVirtualAddressMap() is still
needed for the efi runtime.
Tested-by: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
[ardb: change fpic to fpie as suggested by Xi Ruoyao]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-08-19 18:20:37 +08:00
|
|
|
|
2019-10-29 18:37:53 +01:00
|
|
|
CFLAGS_arm32-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
|
2015-10-23 16:48:14 +02:00
|
|
|
|
2024-11-20 20:36:03 +01:00
|
|
|
zboot-obj-y := zboot-decompress-gzip.o
|
|
|
|
|
CFLAGS_zboot-decompress-gzip.o += -I$(srctree)/lib/zlib_inflate
|
|
|
|
|
zboot-obj-$(CONFIG_KERNEL_ZSTD) := zboot-decompress-zstd.o lib-xxhash.o
|
|
|
|
|
CFLAGS_zboot-decompress-zstd.o += -I$(srctree)/lib/zstd
|
|
|
|
|
|
|
|
|
|
zboot-obj-$(CONFIG_RISCV) += lib-clz_ctz.o lib-ashldi3.o
|
2022-05-02 01:08:16 +02:00
|
|
|
lib-$(CONFIG_EFI_ZBOOT) += zboot.o $(zboot-obj-y)
|
|
|
|
|
|
2023-06-06 17:26:31 +03:00
|
|
|
lib-$(CONFIG_UNACCEPTED_MEMORY) += unaccepted_memory.o bitmap.o find.o
|
|
|
|
|
|
2025-06-03 03:11:41 +09:00
|
|
|
targets := $(lib-y)
|
2022-05-02 01:08:16 +02:00
|
|
|
lib-y := $(patsubst %.o,%.stub.o,$(lib-y))
|
|
|
|
|
|
2020-08-21 12:42:48 -07:00
|
|
|
# Even when -mbranch-protection=none is set, Clang will generate a
|
|
|
|
|
# .note.gnu.property for code-less object files (like lib/ctype.c),
|
|
|
|
|
# so work around this by explicitly removing the unwanted section.
|
2024-01-09 15:16:31 -07:00
|
|
|
# https://llvm.org/pr46480
|
2020-08-21 12:42:48 -07:00
|
|
|
STUBCOPY_FLAGS-y += --remove-section=.note.gnu.property
|
|
|
|
|
|
2020-04-16 11:12:26 -04:00
|
|
|
STUBCOPY_RELOC-$(CONFIG_X86_32) := R_386_32
|
|
|
|
|
STUBCOPY_RELOC-$(CONFIG_X86_64) := R_X86_64_64
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# ARM discards the .data section because it disallows r/w data in the
|
|
|
|
|
# decompressor. So move our .data to .data.efistub and .bss to .bss.efistub,
|
|
|
|
|
# which are preserved explicitly by the decompressor linker script.
|
|
|
|
|
#
|
|
|
|
|
STUBCOPY_FLAGS-$(CONFIG_ARM) += --rename-section .data=.data.efistub \
|
|
|
|
|
--rename-section .bss=.bss.efistub,load,alloc
|
|
|
|
|
STUBCOPY_RELOC-$(CONFIG_ARM) := R_ARM_ABS
|
|
|
|
|
|
2015-01-12 20:28:20 +00:00
|
|
|
#
|
|
|
|
|
# arm64 puts the stub in the kernel proper, which will unnecessarily retain all
|
|
|
|
|
# code indefinitely unless it is annotated as __init/__initdata/__initconst etc.
|
|
|
|
|
# So let's apply the __init annotations at the section level, by prefixing
|
|
|
|
|
# the section names directly. This will ensure that even all the inline string
|
|
|
|
|
# literals are covered.
|
2015-10-08 20:02:04 +01:00
|
|
|
# The fact that the stub and the kernel proper are essentially the same binary
|
|
|
|
|
# also means that we need to be extra careful to make sure that the stub does
|
|
|
|
|
# not rely on any absolute symbol references, considering that the virtual
|
|
|
|
|
# kernel mapping that the linker uses is not active yet when the stub is
|
|
|
|
|
# executing. So build all C dependencies of the EFI stub into libstub, and do
|
|
|
|
|
# a verification pass to see if any absolute relocations exist in any of the
|
|
|
|
|
# object files.
|
2015-01-12 20:28:20 +00:00
|
|
|
#
|
2015-10-08 20:02:04 +01:00
|
|
|
STUBCOPY_FLAGS-$(CONFIG_ARM64) += --prefix-alloc-sections=.init \
|
|
|
|
|
--prefix-symbols=__efistub_
|
2023-01-11 11:22:36 +01:00
|
|
|
STUBCOPY_RELOC-$(CONFIG_ARM64) := R_AARCH64_ABS
|
2015-10-08 20:02:04 +01:00
|
|
|
|
2020-09-17 15:37:14 -07:00
|
|
|
# For RISC-V, we don't need anything special other than arm64. Keep all the
|
|
|
|
|
# symbols in .init section and make sure that no absolute symbols references
|
2023-08-03 13:56:11 +08:00
|
|
|
# exist.
|
2020-09-17 15:37:14 -07:00
|
|
|
STUBCOPY_FLAGS-$(CONFIG_RISCV) += --prefix-alloc-sections=.init \
|
|
|
|
|
--prefix-symbols=__efistub_
|
2024-01-16 14:52:27 +01:00
|
|
|
STUBCOPY_RELOC-$(CONFIG_RISCV) := -E R_RISCV_HI20\|R_RISCV_$(BITS)\|R_RISCV_RELAX
|
2020-09-17 15:37:14 -07:00
|
|
|
|
efi/loongarch: Add efistub booting support
This patch adds efistub booting support, which is the standard UEFI boot
protocol for LoongArch to use.
We use generic efistub, which means we can pass boot information (i.e.,
system table, memory map, kernel command line, initrd) via a light FDT
and drop a lot of non-standard code.
We use a flat mapping to map the efi runtime in the kernel's address
space. In efi, VA = PA; in kernel, VA = PA + PAGE_OFFSET. As a result,
flat mapping is not identity mapping, SetVirtualAddressMap() is still
needed for the efi runtime.
Tested-by: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
[ardb: change fpic to fpie as suggested by Xi Ruoyao]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-08-19 18:20:37 +08:00
|
|
|
# For LoongArch, keep all the symbols in .init section and make sure that no
|
|
|
|
|
# absolute symbols references exist.
|
|
|
|
|
STUBCOPY_FLAGS-$(CONFIG_LOONGARCH) += --prefix-alloc-sections=.init \
|
|
|
|
|
--prefix-symbols=__efistub_
|
|
|
|
|
STUBCOPY_RELOC-$(CONFIG_LOONGARCH) := R_LARCH_MARK_LA
|
|
|
|
|
|
2015-10-08 20:02:04 +01:00
|
|
|
$(obj)/%.stub.o: $(obj)/%.o FORCE
|
|
|
|
|
$(call if_changed,stubcopy)
|
2015-01-12 20:28:20 +00:00
|
|
|
|
2017-01-31 13:21:42 +00:00
|
|
|
#
|
|
|
|
|
# Strip debug sections and some other sections that may legally contain
|
|
|
|
|
# absolute relocations, so that we can inspect the remaining sections for
|
|
|
|
|
# such relocations. If none are found, regenerate the output object, but
|
|
|
|
|
# this time, use objcopy and leave all sections in place.
|
|
|
|
|
#
|
2015-10-08 20:02:04 +01:00
|
|
|
quiet_cmd_stubcopy = STUBCPY $@
|
2019-03-28 20:34:25 +01:00
|
|
|
cmd_stubcopy = \
|
2019-03-28 20:34:29 +01:00
|
|
|
$(STRIP) --strip-debug -o $@ $<; \
|
2019-03-28 20:34:25 +01:00
|
|
|
if $(OBJDUMP) -r $@ | grep $(STUBCOPY_RELOC-y); then \
|
|
|
|
|
echo "$@: absolute symbol references not allowed in the EFI stub" >&2; \
|
|
|
|
|
/bin/false; \
|
|
|
|
|
fi; \
|
|
|
|
|
$(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@
|