Changes in Makefile

c077711f - arm64: Detect if in a realm and set RIPAS RAM

Thu, 17 Oct 2024 13:14:25 +0000

arm64: Detect if in a realm and set RIPAS RAMDetect that the VM is a realm guest by the presence of the RSIinterface. This is done after PSCI has been initialised so that we cancheck the SMCCC conduit before making any RSI calls.If in a realm then iterate over all memory ensuring that it is marked asRIPAS RAM. The loader is required to do this for us, however if somememory is missed this will cause the guest to receive a hard to debugexternal abort at some random point in the future. So for abelt-and-braces approach set all memory to RIPAS RAM. Any failure hereimplies that the RAM regions passed to Linux are incorrect so panic()promptly to make the situation clear.Reviewed-by: Gavin Shan Reviewed-by: Catalin Marinas Signed-off-by: Suzuki K Poulose Co-developed-by: Steven Price Signed-off-by: Steven Price Link: https://lore.kernel.org/r/20241017131434.40935-3-steven.price@arm.comSigned-off-by: Catalin Marinas List of files: /linux-6.15/arch/arm64/kernel/Makefile

99e7a8ad - arm64: cpuidle: Move ACPI specific code into drivers/acpi/arm64/

Wed, 05 Jun 2024 13:14:57 +0000

arm64: cpuidle: Move ACPI specific code into drivers/acpi/arm64/The ACPI cpuidle LPI FFH code can be moved out of arm64 arch code asit just uses SMCCC. Move all the ACPI cpuidle LPI FFH code intodrivers/acpi/arm64/cpuidle.cSigned-off-by: Sudeep Holla Acked-by: Catalin Marinas Acked-by: Hanjun Guo Link: https://lore.kernel.org/r/20240605131458.3341095-3-sudeep.holla@arm.comSigned-off-by: Catalin Marinas List of files: /linux-6.15/arch/arm64/kernel/Makefile

443cbaf9 - crash: split vmcoreinfo exporting code out from crash_core.c

Wed, 24 Jan 2024 05:12:42 +0000

crash: split vmcoreinfo exporting code out from crash_core.cNow move the relevant codes into separate files:kernel/crash_reserve.c, include/linux/crash_reserve.h.And add config item CRASH_RESERVE to control its enabling.And also update the old ifdeffery of CONFIG_CRASH_CORE, including of and config item dependency on CRASH_COREaccordingly.And also do renaming as follows: - arch/xxx/kernel/{crash_core.c => vmcore_info.c}because they are only related to vmcoreinfo exporting on x86, arm64,riscv.And also Remove config item CRASH_CORE, and rely on CONFIG_KEXEC_CORE todecide if build in crash_core.c.[yang.lee@linux.alibaba.com: remove duplicated include in vmcore_info.c] Link: https://lkml.kernel.org/r/20240126005744.16561-1-yang.lee@linux.alibaba.comLink: https://lkml.kernel.org/r/20240124051254.67105-3-bhe@redhat.comSigned-off-by: Baoquan He Signed-off-by: Yang Li Acked-by: Hari Bathini Cc: Al Viro Cc: Eric W. Biederman Cc: Pingfan Liu Cc: Klara Modin Cc: Michael Kelley Cc: Nathan Chancellor Cc: Stephen Rothwell Cc: Yang Li Signed-off-by: Andrew Morton List of files: /linux-6.15/arch/arm64/kernel/Makefile

8a6e40e1 - arm64: head: move dynamic shadow call stack patching into early C runtime

Wed, 14 Feb 2024 12:28:55 +0000

arm64: head: move dynamic shadow call stack patching into early C runtimeOnce we update the early kernel mapping code to only map the kernel oncewith the right permissions, we can no longer perform code patching viathis mapping.So move this code to an earlier stage of the boot, right after applyingthe relocations.Signed-off-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20240214122845.2033971-54-ardb+git@google.comSigned-off-by: Catalin Marinas List of files: /linux-6.15/arch/arm64/kernel/Makefile

e223a449 - arm64: idreg-override: Move to early mini C runtime

Wed, 14 Feb 2024 12:28:50 +0000

arm64: idreg-override: Move to early mini C runtimeWe will want to parse the ID register overrides even earlier, so that wecan take them into account before creating the kernel mapping. Somigrate the code and make it work in the context of the early C runtime.We will move the invocation to an earlier stage in a subsequent patch.Signed-off-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20240214122845.2033971-49-ardb+git@google.comSigned-off-by: Catalin Marinas List of files: /linux-6.15/arch/arm64/kernel/Makefile

734958ef - arm64: head: move relocation handling to C code

Wed, 14 Feb 2024 12:28:49 +0000

arm64: head: move relocation handling to C codeNow that we have a mini C runtime before the kernel mapping is up, wecan move the non-trivial relocation processing code out of head.S andreimplement it in C.Signed-off-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20240214122845.2033971-48-ardb+git@google.comSigned-off-by: Catalin Marinas List of files: /linux-6.15/arch/arm64/kernel/Makefile

d104a6fe - arm64: scs: Disable LTO for SCS patching code

Tue, 23 Jan 2024 13:30:55 +0000

arm64: scs: Disable LTO for SCS patching codeFull LTO takes the '-mbranch-protection=none' passed to the compilerwhen generating the dynamic shadow call stack patching code as a hint tostop emitting PAC instructions altogether. (Thin LTO appears unaffectedby this)Work around this by disabling LTO for the compilation unit, whichappears to convince the linker that it should still use PAC in the restof the kernel..Fixes: 3b619e22c460 ("arm64: implement dynamic shadow call stack for Clang")Signed-off-by: Ard Biesheuvel Reviewed-by: Kees Cook Reviewed-by: Sami Tolvanen Tested-by: Sami Tolvanen Link: https://lore.kernel.org/r/20240123133052.1417449-6-ardb+git@google.comSigned-off-by: Will Deacon List of files: /linux-6.15/arch/arm64/kernel/Makefile

2fa28abd - arm64: Revert "scs: Work around full LTO issue with dynamic SCS"

Tue, 23 Jan 2024 13:30:54 +0000

arm64: Revert "scs: Work around full LTO issue with dynamic SCS"This reverts commit 8c5a19cb17a71e ("arm64: scs: Work around full LTOissue with dynamic SCS"), which did not quite fix the issue as intended.Apparently, -fno-unwind-tables is ignored for the final full LTO linkwhen it is set on any of the objects, resulting in an early boot crashdue to the SCS patching code patching itself, and attempting to pop thereturn address from the shadow stack while the associated push was stilla PACIASP instruction when it executed.Reported-by: Sami Tolvanen Signed-off-by: Ard Biesheuvel Reviewed-by: Kees Cook Reviewed-by: Sami Tolvanen Tested-by: Sami Tolvanen Link: https://lore.kernel.org/r/20240123133052.1417449-5-ardb+git@google.comSigned-off-by: Will Deacon List of files: /linux-6.15/arch/arm64/kernel/Makefile

8c5a19cb - arm64: scs: Work around full LTO issue with dynamic SCS

Wed, 10 Jan 2024 13:26:20 +0000

arm64: scs: Work around full LTO issue with dynamic SCSFull LTO takes the '-mbranch-protection=none' passed to the compilerwhen generating the dynamic shadow call stack patching code as a hint tostop emitting PAC instructions altogether. (Thin LTO appears unaffectedby this)Work around this by stripping unwind tables from the object in question,which should be sufficient to prevent the patching code from attemptingto patch itself.Fixes: 3b619e22c460 ("arm64: implement dynamic shadow call stack for Clang")Signed-off-by: Ard Biesheuvel Reviewed-by: Sami Tolvanen Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20240110132619.258809-2-ardb+git@google.comSigned-off-by: Will Deacon List of files: /linux-6.15/arch/arm64/kernel/Makefile

94946f9e - arm64: add hw_nmi_get_sample_period for preparation of lockup detector

Fri, 19 May 2023 17:18:41 +0000

arm64: add hw_nmi_get_sample_period for preparation of lockup detectorSet safe maximum CPU frequency to 5 GHz in case a particular platformdoesn't implement cpufreq driver. Although, architecture doesn't put anyrestrictions on maximum frequency but 5 GHz seems to be safe maximum giventhe available Arm CPUs in the market which are clocked much less than 5GHz.On the other hand, we can't make it much higher as it would lead to alarge hard-lockup detection timeout on parts which are running slower (eg.1GHz on Developerbox) and doesn't possess a cpufreq driver.Link: https://lkml.kernel.org/r/20230519101840.v5.17.Ia9d02578e89c3f44d3cb12eec8b0176603c8ab2f@changeidCo-developed-by: Sumit Garg Signed-off-by: Sumit Garg Co-developed-by: Pingfan Liu Signed-off-by: Pingfan Liu Signed-off-by: Lecopzer Chen Signed-off-by: Douglas Anderson Cc: Andi Kleen Cc: Catalin Marinas Cc: Chen-Yu Tsai Cc: Christophe Leroy Cc: Colin Cross Cc: Daniel Thompson Cc: "David S. Miller" Cc: Guenter Roeck Cc: Ian Rogers Cc: Marc Zyngier Cc: Mark Rutland Cc: Masayoshi Mizuma Cc: Matthias Kaehlcke Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Petr Mladek Cc: Randy Dunlap Cc: "Ravi V. Shankar" Cc: Ricardo Neri Cc: Stephane Eranian Cc: Stephen Boyd Cc: Tzung-Bi Shih Cc: Will Deacon Signed-off-by: Andrew Morton List of files: /linux-6.15/arch/arm64/kernel/Makefile

ea3752ba - arm64: module: mandate MODULE_PLTS

Tue, 30 May 2023 11:03:27 +0000

arm64: module: mandate MODULE_PLTSContemporary kernels and modules can be relatively large, especiallywhen common debug options are enabled. Using GCC 12.1.0, a v6.3-rc7defconfig kernel is ~38M, and with PROVE_LOCKING + KASAN_INLINE enabledthis expands to ~117M. Shanker reports [1] that the NVIDIA GPU driveralone can consume 110M of module space in some configurations.Both KASLR and ARM64_ERRATUM_843419 select MODULE_PLTS, so anyonewanting a kernel to have KASLR or run on Cortex-A53 will haveMODULE_PLTS selected. This is the case in defconfig and distributionkernels (e.g. Debian, Android, etc).Practically speaking, this means we're very likely to need MODULE_PLTSand while it's almost guaranteed that MODULE_PLTS will be selected, itis possible to disable support, and we have to maintain some awkwardspecial cases for such unusual configurations.This patch removes the MODULE_PLTS config option, with the support codealways enabled if MODULES is selected. This results in a slightsimplification, and will allow for further improvement in subsequentpatches.For any config which currently selects MODULE_PLTS, there will be nofunctional change as a result of this patch.[1] https://lore.kernel.org/linux-arm-kernel/159ceeab-09af-3174-5058-445bc8dcf85b@nvidia.com/Signed-off-by: Mark Rutland Reviewed-by: Ard Biesheuvel Cc: Shanker Donthineni Cc: Will Deacon Tested-by: Shanker Donthineni Link: https://lore.kernel.org/r/20230530110328.2213762-6-mark.rutland@arm.comSigned-off-by: Catalin Marinas List of files: /linux-6.15/arch/arm64/kernel/Makefile

7755cec6 - arm64: perf: Move PMUv3 driver to drivers/perf

Fri, 17 Mar 2023 19:50:20 +0000

arm64: perf: Move PMUv3 driver to drivers/perfHaving the ARM PMUv3 driver sitting in arch/arm64/kernel is gettingin the way of being able to use perf on ARMv8 cores running a 32bitkernel, such as 32bit KVM guests.This patch moves it into drivers/perf/arm_pmuv3.c, with an includefile in include/linux/perf/arm_pmuv3.h. The only thing left inarch/arm64 is some mundane perf stuff.Signed-off-by: Marc Zyngier Signed-off-by: Zaid Al-Bassam Tested-by: Florian Fainelli Link: https://lore.kernel.org/r/20230317195027.3746949-2-zalbassam@google.comSigned-off-by: Will Deacon List of files: /linux-6.15/arch/arm64/kernel/Makefile

3b619e22 - arm64: implement dynamic shadow call stack for Clang

Thu, 27 Oct 2022 15:59:08 +0000

arm64: implement dynamic shadow call stack for ClangImplement dynamic shadow call stack support on Clang, by parsing theunwind tables at init time to locate all occurrences of PACIASP/AUTIASPinstructions, and replacing them with the shadow call stack push and popinstructions, respectively.This is useful because the overhead of the shadow call stack isdifficult to justify on hardware that implements pointer authentication(PAC), and given that the PAC instructions are executed as NOPs onhardware that doesn't, we can just replace them without breakinganything. As PACIASP/AUTIASP are guaranteed to be paired with respect tomanipulations of the return address, replacing them 1:1 with shadow callstack pushes and pops is guaranteed to result in the desired behavior.Signed-off-by: Ard Biesheuvel Reviewed-by: Sami Tolvanen Tested-by: Sami Tolvanen Link: https://lore.kernel.org/r/20221027155908.1940624-4-ardb@kernel.orgSigned-off-by: Will Deacon List of files: /linux-6.15/arch/arm64/kernel/Makefile

4ef80609 - arm64: efi: Move efi-entry.S into the libstub source directory

Mon, 17 Oct 2022 15:14:41 +0000

arm64: efi: Move efi-entry.S into the libstub source directoryWe will be sharing efi-entry.S with the zboot decompressor build, whichdoes not link against vmlinux directly. So move it into the libstubsource directory so we can include in the libstub static library.Signed-off-by: Ard Biesheuvel Acked-by: Catalin Marinas List of files: /linux-6.15/arch/arm64/kernel/Makefile

32164845 - kbuild: use obj-y instead extra-y for objects placed at the head

Sat, 24 Sep 2022 18:19:14 +0000

kbuild: use obj-y instead extra-y for objects placed at the headThe objects placed at the head of vmlinux need special treatments: - arch/$(SRCARCH)/Makefile adds them to head-y in order to place them before other archives in the linker command line. - arch/$(SRCARCH)/kernel/Makefile adds them to extra-y instead of obj-y to avoid them going into built-in.a.This commit gets rid of the latter.Create vmlinux.a to collect all the objects that are unconditionallylinked to vmlinux. The objects listed in head-y are moved to the headof vmlinux.a by using 'ar m'.With this, arch/$(SRCARCH)/kernel/Makefile can consistently use obj-yfor builtin objects.There is no *.o that is directly linked to vmlinux. Drop unneeded codein scripts/clang-tools/gen_compile_commands.py.$(AR) mPi needs 'T' to workaround the llvm-ar bug. The fix was suggestedby Nathan Chancellor [1].[1]: https://lore.kernel.org/llvm/YyjjT5gQ2hGMH0ni@dev-arch.thelio-3990X/Signed-off-by: Masahiro Yamada Tested-by: Nick Desaulniers Reviewed-by: Nicolas Schier List of files: /linux-6.15/arch/arm64/kernel/Makefile

3fc24ef3 - arm64: compat: Implement misalignment fixups for multiword loads

Fri, 01 Jul 2022 13:53:22 +0000

arm64: compat: Implement misalignment fixups for multiword loadsThe 32-bit ARM kernel implements fixups on behalf of user space whenusing LDM/STM or LDRD/STRD instructions on addresses that are not 32-bitaligned. This is not something that is supported by the architecture,but was done anyway to increase compatibility with user space software,which mostly targeted x86 at the time and did not care about alignedaccesses.This feature is one of the remaining impediments to being able to switchto 64-bit kernels on 64-bit capable hardware running 32-bit user space,so let's implement it for the arm64 compat layer as well.Note that the intent is to implement the exact same handling ofmisaligned multi-word loads and stores as the 32-bit kernel does,including what appears to be missing support for user space programsthat rely on SETEND to switch to a different byte order and back. Also,like the 32-bit ARM version, we rely on the faulting address reported bythe CPU to infer the memory address, instead of decoding the instructionfully to obtain this information.This implementation is taken from the 32-bit ARM tree, with all piecesremoved that deal with instructions other than LDRD/STRD and LDM/STM, orthat deal with alignment exceptions taken in kernel mode.Cc: debian-arm@lists.debian.orgCc: Vagrant Cascadian Cc: Riku Voipio Cc: Steve McIntyre Signed-off-by: Ard Biesheuvel Reviewed-by: Arnd Bergmann Link: https://lore.kernel.org/r/20220701135322.3025321-1-ardb@kernel.org[catalin.marinas@arm.com: change the option to 'default n']Signed-off-by: Catalin Marinas List of files: /linux-6.15/arch/arm64/kernel/Makefile

aacd149b - arm64: head: avoid relocating the kernel twice for KASLR

Fri, 24 Jun 2022 15:06:50 +0000

arm64: head: avoid relocating the kernel twice for KASLRCurrently, when KASLR is in effect, we set up the kernel virtual addressspace twice: the first time, the KASLR seed is looked up in the devicetree, and the kernel virtual mapping is torn down and recreated again,after which the relocations are applied a second time. The latter stepmeans that statically initialized global pointer variables will be resetto their initial values, and to ensure that BSS variables are not set tovalues based on the initial translation, they are cleared again as well.All of this is needed because we need the command line (taken from theDT) to tell us whether or not to randomize the virtual address spacebefore entering the kernel proper. However, this code has expandedlittle by little and now creates global state unrelated to the virtualrandomization of the kernel before the mapping is torn down and set upagain, and the BSS cleared for a second time. This has created someissues in the past, and it would be better to avoid this little dance ifpossible.So instead, let's use the temporary mapping of the device tree, andexecute the bare minimum of code to decide whether or not KASLR shouldbe enabled, and what the seed is. Only then, create the virtual kernelmapping, clear BSS, etc and proceed as normal. This avoids the issuesaround inconsistent global state due to BSS being cleared twice, and isgenerally more maintainable, as it permits us to defer all the remainingDT parsing and KASLR initialization to a later time.This means the relocation fixup code runs only a single time as well,allowing us to simplify the RELR handling code too, which is notidempotent and was therefore required to keep track of the offset thatwas applied the first time around.Note that this means we have to clone a pair of FDT library objects, sothat we can control how they are built - we need the stack protectorand other instrumentation disabled so that the code can tolerate beingcalled this early. Note that only the kernel page tables and thetemporary stack are mapped read-write at this point, which ensures thatthe early code does not modify any global state inadvertently.Signed-off-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20220624150651.1358849-21-ardb@kernel.orgSigned-off-by: Will Deacon List of files: /linux-6.15/arch/arm64/kernel/Makefile

802b9111 - arm64: kasan: do not instrument stacktrace.c

Mon, 23 May 2022 14:51:51 +0000

arm64: kasan: do not instrument stacktrace.cDisable KASAN instrumentation of arch/arm64/kernel/stacktrace.c.This speeds up Generic KASAN by 5-20%.As a side-effect, KASAN is now unable to detect bugs in the stack tracecollection code. This is taken as an acceptable downside.Also replace READ_ONCE_NOCHECK() with READ_ONCE() in stacktrace.c.As the file is now not instrumented, there is no need to use theNOCHECK version of READ_ONCE().Suggested-by: Mark Rutland Acked-by: Mark Rutland Signed-off-by: Andrey Konovalov Link: https://lore.kernel.org/r/c4c944a2a905e949760fbeb29258185087171708.1653317461.git.andreyknvl@google.comSigned-off-by: Will Deacon List of files: /linux-6.15/arch/arm64/kernel/Makefile

205f3991 - arm64: vdso: fix makefile dependency on vdso.so

Tue, 10 May 2022 10:27:21 +0000

arm64: vdso: fix makefile dependency on vdso.soThere is currently no dependency for vdso*-wrap.S on vdso*.so, which means thatyou can get a build that uses a stale vdso*-wrap.o.In commit a5b8ca97fbf8, the file that includes the vdso.so was moved and renamedfrom arch/arm64/kernel/vdso/vdso.S to arch/arm64/kernel/vdso-wrap.S, when thishappened the Makefile was not updated to force the dependcy on vdso.so.Fixes: a5b8ca97fbf8 ("arm64: do not descend to vdso directories twice")Signed-off-by: Joey Gouly Cc: Masahiro Yamada Cc: Vincenzo Frascino Cc: Catalin Marinas Cc: Will Deacon Link: https://lore.kernel.org/r/20220510102721.50811-1-joey.gouly@arm.comSigned-off-by: Will Deacon List of files: /linux-6.15/arch/arm64/kernel/Makefile

6dd8b1a0 - arm64: mte: Dump the MTE tags in the core file

Mon, 31 Jan 2022 16:54:55 +0000

arm64: mte: Dump the MTE tags in the core fileFor each vma mapped with PROT_MTE (the VM_MTE flag set), generate aPT_ARM_MEMTAG_MTE segment in the core file and dump the correspondingtags. The in-file size for such segments is 128 bytes per page.For pages in a VM_MTE vma which are not present in the user page tablesor don't have the PG_mte_tagged flag set (e.g. execute-only), just writezeros in the core file.An example of program headers for two vmas, one 2-page, the other 4-pagelong: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align ... LOAD 0x030000 0x0000ffff80034000 0x0000000000000000 0x000000 0x002000 RW 0x1000 LOAD 0x030000 0x0000ffff80036000 0x0000000000000000 0x004000 0x004000 RW 0x1000 ... LOPROC+0x1 0x05b000 0x0000ffff80034000 0x0000000000000000 0x000100 0x002000 0 LOPROC+0x1 0x05b100 0x0000ffff80036000 0x0000000000000000 0x000200 0x004000 0Signed-off-by: Catalin Marinas Acked-by: Luis Machado Reviewed-by: Mark Brown Link: https://lore.kernel.org/r/20220131165456.2160675-5-catalin.marinas@arm.comSigned-off-by: Will Deacon List of files: /linux-6.15/arch/arm64/kernel/Makefile