Changes in asm-offsets.c

31e9fa2b - arm: vdso: Switch to generic storage implementation

Tue, 04 Feb 2025 12:05:43 +0000

arm: vdso: Switch to generic storage implementationThe generic storage implementation provides the same features as thecustom one. However it can be shared between architectures, makingmaintenance easier.Co-developed-by: Nam Cao Signed-off-by: Nam Cao Signed-off-by: Thomas Weißschuh Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/20250204-vdso-store-rng-v3-11-13a4669dfc8c@linutronix.de List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

7af5b901 - ARM: 9358/2: Implement PAN for LPAE by TTBR0 page table walks disablement

Mon, 25 Mar 2024 07:31:13 +0000

ARM: 9358/2: Implement PAN for LPAE by TTBR0 page table walks disablementWith LPAE enabled, privileged no-access cannot be enforced using CPUdomains as such feature is not available. This patch implements PANby disabling TTBR0 page table walks while in kernel mode.The ARM architecture allows page table walks to be split between TTBR0and TTBR1. With LPAE enabled, the split is defined by a combination ofTTBCR T0SZ and T1SZ bits. Currently, an LPAE-enabled kernel uses TTBR0for user addresses and TTBR1 for kernel addresses with the VMSPLIT_2Gand VMSPLIT_3G configurations. The main advantage for the 3:1 split isthat TTBR1 is reduced to 2 levels, so potentially faster TLB refill(though usually the first level entries are already cached in the TLB).The PAN support on LPAE-enabled kernels uses TTBR0 when running in userspace or in kernel space during user access routines (TTBCR T0SZ andT1SZ are both 0). When running user accesses are disabled in kernelmode, TTBR0 page table walks are disabled by setting TTBCR.EPD0. TTBR1is used for kernel accesses (including loadable modules; anythingcovered by swapper_pg_dir) by reducing the TTBCR.T0SZ to the minimum(2^(32-7) = 32MB). To avoid user accesses potentially hitting stale TLBentries, the ASID is switched to 0 (reserved) by setting TTBCR.A1 andusing the ASID value in TTBR1. The difference from a non-PAN kernel isthat with the 3:1 memory split, TTBR1 always uses 3 levels of pagetables.As part of the change we are using preprocessor elif definied() clausesso balance these clauses by converting relevant precedingt ifdefclauses to if defined() clauses.Signed-off-by: Catalin Marinas Reviewed-by: Kees Cook Tested-by: Florian Fainelli Signed-off-by: Linus Walleij Signed-off-by: Russell King (Oracle) List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

a0d2fcd6 - vdso/ARM: Make union vdso_data_store available for all architectures

Mon, 19 Feb 2024 15:39:33 +0000

vdso/ARM: Make union vdso_data_store available for all architecturesThe vDSO data page "union vdso_data_store" is defined in an ARM specificheader file and also defined in several other places.Move the definition from the ARM header file into the generic vdso datapageheader to make it also usable for others and to prevent code duplication.Signed-off-by: Anna-Maria Behnsen Signed-off-by: Thomas Gleixner Reviewed-by: Vincenzo Frascino Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20240219153939.75719-5-anna-maria@linutronix.de List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

a9ff6961 - ARM: mm: Make virt_to_pfn() a static inline

Thu, 02 Jun 2022 08:18:32 +0000

ARM: mm: Make virt_to_pfn() a static inlineMaking virt_to_pfn() a static inline taking a strongly typed(const void *) makes the contract of a passing a pointer of thattype to the function explicit and exposes any misuse of themacro virt_to_pfn() acting polymorphic and accepting many typessuch as (void *), (unitptr_t) or (unsigned long) as argumentswithout warnings.Doing this is a bit intrusive: virt_to_pfn() requiresPHYS_PFN_OFFSET and PAGE_SHIFT to be defined, and this is defined in, so this must be included *before* .The use of macros were obscuring the unclear inclusion order here,as the macros would eventually be resolved, but a static inlinelike this cannot be compiled with unresolved macros.The naive solution to include at the top of does not work, because sometimesincludes at the end of itself, which would create aconfusing inclusion loop. So instead, take the approach to alwaysunconditionally include at the end of arch/arm uses explicitly in a lot of places,however it turns out that if we just unconditionally include into and switch all inclusions of to instead, we enforce the rightorder and will always have access to thedefinitions.Put an inclusion guard in place making it impossible to include explicitly.Link: https://lore.kernel.org/linux-mm/20220701160004.2ffff4e5ab59a55499f4c736@linux-foundation.org/Signed-off-by: Linus Walleij List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

6ee1e677 - ARM: kernel: Get rid of thread_info::used_cp[] array

Sun, 19 Mar 2023 22:55:14 +0000

ARM: kernel: Get rid of thread_info::used_cp[] arrayWe keep track of which coprocessor triggered a fault in the used_cp[]array in thread_info, but this data is never used anywhere. So let'sremove it.Linus did some digging and found out that the last user of this fieldwas removed in commit bb1a773d5b6b ("kill unused dump_fpu() instances").Reviewed-by: Linus Walleij Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

62b95a7b - ARM: 9282/1: vfp: Manipulate task VFP state with softirqs disabled

Thu, 22 Dec 2022 17:49:51 +0000

ARM: 9282/1: vfp: Manipulate task VFP state with softirqs disabledIn a subsequent patch, we will relax the kernel mode NEON policy, andpermit kernel mode NEON to be used not only from task context, as ispermitted today, but also from softirq context.Given that softirqs may trigger over the back of any IRQ unless they areexplicitly disabled, we need to address the resulting races in the VFPstate handling, by disabling softirq processing in two distinct butrelated cases:- kernel mode NEON will leave the FPU disabled after it completes, so any kernel code sequence that enables the FPU and subsequently accesses its registers needs to disable softirqs until it completes;- kernel_neon_begin() will preserve the userland VFP state in memory, and if it interrupts the ordinary VFP state preserve sequence, the latter will resume execution with the VFP registers corrupted, and happily continue saving them to memory.Given that disabling softirqs also disables preemption, we can replacethe existing preempt_disable/enable occurrences in the VFP statehandling asm code with new macros that dis/enable softirqs instead.In the VFP state handling C code, add local_bh_disable/enable() callsin those places where the VFP state is preserved.One thing to keep in mind is that, once we allow NEON use in softirqcontext, the result of any such interruption is that the FPEXC_EN bit inthe FPEXC register will be cleared, and vfp_current_hw_state[cpu] willbe NULL. This means that any sequence that [conditionally] clearsFPEXC_EN and/or sets vfp_current_hw_state[cpu] to NULL does not need torun with softirqs disabled, as the result will be the same. Furthermore,the handling of THREAD_NOTIFY_SWITCH is guaranteed to run with IRQsdisabled, and so it does not need protection from softirq interruptionseither.Tested-by: Martin Willi Reviewed-by: Linus Walleij Signed-off-by: Ard Biesheuvel Signed-off-by: Russell King (Oracle) List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

9c46929e - ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems

Wed, 24 Nov 2021 13:08:11 +0000

ARM: implement THREAD_INFO_IN_TASK for uniprocessor systemsOn UP systems, only a single task can be 'current' at the same time,which means we can use a global variable to track it. This means we canalso enable THREAD_INFO_IN_TASK for those systems, as in that case,thread_info is accessed via current rather than the other way around,removing the need to store thread_info at the base of the task stack.This, in turn, permits us to enable IRQ stacks and vmap'ed stacks on UPsystems as well.To partially mitigate the performance overhead of this arrangement, usea ADD/ADD/LDR sequence with the appropriate PC-relative grouprelocations to load the value of current when needed. This means thataccessing current will still only require a single load as before,avoiding the need for a literal to carry the address of the globalvariable in each function. However, accessing thread_info will nowrequire this load as well.Acked-by: Linus Walleij Acked-by: Nicolas Pitre Signed-off-by: Ard Biesheuvel Tested-by: Marc Zyngier Tested-by: Vladimir Murzin # ARMv7M List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

18ed1c01 - ARM: smp: Enable THREAD_INFO_IN_TASK

Sat, 18 Sep 2021 08:44:38 +0000

ARM: smp: Enable THREAD_INFO_IN_TASKNow that we no longer rely on thread_info living at the base of the taskstack to be able to access the 'current' pointer, we can wire up thegeneric support for moving thread_info into the task struct itself.Note that this requires us to update the cpu field in thread_infoexplicitly, now that the core code no longer does so. Ideally, we wouldswitch the percpu code to access the cpu field in task_struct instead,but this unleashes #include circular dependency hell.Co-developed-by: Keith Packard Signed-off-by: Keith Packard Signed-off-by: Ard Biesheuvel Reviewed-by: Linus Walleij Tested-by: Amit Daniel Kachhap List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

dfbdcda2 - gcc-plugins: arm-ssp: Prepare for THREAD_INFO_IN_TASK support

Sat, 18 Sep 2021 08:44:34 +0000

gcc-plugins: arm-ssp: Prepare for THREAD_INFO_IN_TASK supportWe will be enabling THREAD_INFO_IN_TASK support for ARM, which meansthat we can no longer load the stack canary value by masking the stackpointer and taking the copy that lives in thread_info. Instead, we willbe able to load it from the task_struct directly, by using the TPIDRUROregister which will hold the current task pointer whenTHREAD_INFO_IN_TASK is in effect. This is much more straight-forward,and allows us to declutter this code a bit while at it.Note that this means that ARMv6 (non-v6K) SMP systems can no longer usethis feature, but those are quite rare to begin with, so this is areasonable trade off.Reviewed-by: Kees Cook Signed-off-by: Ard Biesheuvel Reviewed-by: Linus Walleij Tested-by: Amit Daniel Kachhap List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

8ac6f5d7 - ARM: 9113/1: uaccess: remove set_fs() implementation

Wed, 11 Aug 2021 07:30:26 +0000

ARM: 9113/1: uaccess: remove set_fs() implementationThere are no remaining callers of set_fs(), so just remove italong with all associated code that operates onthread_info->addr_limit.There are still further optimizations that can be done:- In get_user(), the address check could be moved entirely into the out of line code, rather than passing a constant as an argument,- I assume the DACR handling can be simplified as we now only change it during user access when CONFIG_CPU_SW_DOMAIN_PAN is set, but not during set_fs().Acked-by: Christoph Hellwig Signed-off-by: Arnd Bergmann Signed-off-by: Russell King (Oracle) List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

4e57a4dd - ARM: 9107/1: syscall: always store thread_info->abi_syscall

Wed, 11 Aug 2021 07:30:21 +0000

ARM: 9107/1: syscall: always store thread_info->abi_syscallThe system call number is used in a a couple of places, in particularptrace, seccomp and /proc//syscall.The last one apparently never worked reliably on ARM for tasks that arenot currently getting traced.Storing the syscall number in the normal entry path makes it work,as well as allowing us to see if the current system call is for OABIcompat mode, which is the next thing I want to hook into.Since the thread_info->syscall field is not just the number any more, itis now renamed to abi_syscall. In kernels that enable both OABI and EABI,the upper bits of this field encode 0x900000 (__NR_OABI_SYSCALL_BASE)for OABI tasks, while normal EABI tasks do not set the upper bits. Thismakes it possible to implement the in_oabi_syscall() helper later.All other users of thread_info->syscall go through the syscall_get_nr()helper, which in turn filters out the ABI bits.Note that the ABI information is lost with PTRACE_SET_SYSCALL, so onecannot set the internal number to a particular version, but this wasalready the case. We could change it to let gdb encode the ABI type alongwith the syscall in a CONFIG_OABI_COMPAT-enabled kernel, but that itselfwould be a (backwards-compatible) ABI change, so I don't do it here.Acked-by: Christoph Hellwig Signed-off-by: Arnd Bergmann Signed-off-by: Russell King (Oracle) List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

12c3dca2 - ARM: ep93xx: remove MaverickCrunch support

Sat, 27 Feb 2021 12:40:09 +0000

ARM: ep93xx: remove MaverickCrunch supportThe MaverickCrunch support for ep93xx never made it into glibc andwas removed from gcc in its 4.8 release in 2012. It is now one ofthe last parts of arch/arm/ that fails to build with the clangintegrated assembler, which is unlikely to ever want to support it.The two alternatives are to force the use of binutils/gas whenbuilding the crunch support, or to remove it entirely.According to Hartley Sweeten: "Martin Guy did a lot of work trying to get the maverick crunch working but I was never able to successfully use it for anything. It "kind" of works but depending on the EP93xx silicon revision there are still a number of hardware bugs that either give imprecise or garbage results. I have no problem with removing the kernel support for the maverick crunch."Unless someone else comes up with a good reason to keep it around,remove it now. This touches mostly the ep93xx platform, but removesa bit of code from ARM common ptrace and signal frame handling as well.If there are remaining users of MaverickCrunch, they can use LTSkernels for at least another five years before kernel support ends.Link: https://lore.kernel.org/linux-arm-kernel/20210802141245.1146772-1-arnd@kernel.org/Link: https://lore.kernel.org/linux-arm-kernel/20210226164345.3889993-1-arnd@kernel.org/Link: https://github.com/ClangBuiltLinux/linux/issues/1272Link: https://gcc.gnu.org/legacy-ml/gcc/2008-03/msg01063.htmlCc: "Martin Guy" Signed-off-by: Arnd Bergmann List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

57ac5166 - ARM: 9075/1: kernel: Fix interrupted SMC calls

Wed, 14 Apr 2021 03:41:16 +0000

ARM: 9075/1: kernel: Fix interrupted SMC callsOn Qualcomm ARM32 platforms, the SMC call can return before it hascompleted. If this occurs, the call can be restarted, but it requiresusing the returned session ID value from the interrupted SMC call.The ARM32 SMCC code already has the provision to add platform specificquirks for things like this. So let's make use of it and add theQualcomm specific quirk (ARM_SMCCC_QUIRK_QCOM_A6) used by the QCOM_SCMdriver.This change is similar to the below one added for ARM64 a while ago:commit 82bcd087029f ("firmware: qcom: scm: Fix interrupted SCM calls")Without this change, the Qualcomm ARM32 platforms like SDX55 will return-EINVAL for SMC calls used for modem firmware loading and validation.Signed-off-by: Manivannan Sadhasivam Reviewed-by: Bjorn Andersson Signed-off-by: Russell King List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

4d62e81b - ARM: kexec: fix oops after TLB are invalidated

Mon, 01 Feb 2021 19:40:01 +0000

ARM: kexec: fix oops after TLB are invalidatedGiancarlo Ferrari reports the following oops while trying to use kexec: Unable to handle kernel paging request at virtual address 80112f38 pgd = fd7ef03e [80112f38] *pgd=0001141e(bad) Internal error: Oops: 80d [#1] PREEMPT SMP ARM ...This is caused by machine_kexec() trying to set the kernel text to beread/write, so it can poke values into the relocation code beforecopying it - and an interrupt occuring which changes the page tables.The subsequent writes then hit read-only sections that trigger adata abort resulting in the above oops.Fix this by copying the relocation code, and then writing the variablesinto the destination, thereby avoiding the need to make the kernel textread/write.Reported-by: Giancarlo Ferrari Tested-by: Giancarlo Ferrari Signed-off-by: Russell King List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

6ec4476a - Raise gcc version requirement to 4.9

Wed, 08 Jul 2020 17:48:35 +0000

Raise gcc version requirement to 4.9I realize that we fairly recently raised it to 4.8, but the fact is, 4.9is a much better minimum version to target.We have a number of workarounds for actual bugs in pre-4.9 gcc versions(including things like internal compiler errors on ARM), but we alsohave some syntactic workarounds for lacking features.In particular, raising the minimum to 4.9 means that we can now justassume _Generic() exists, which is likely the much better replacementfor a lot of very convoluted built-time magic with conditionals onsizeof and/or __builtin_choose_expr() with same_type() etc.Using _Generic also means that you will need to have a very recentversion of 'sparse', but thats easy to build yourself, and much less ofa hassle than some old gcc version can be.The latest (in a long string) of reasons for minimum compiler versionupgrades was commit 5435f73d5c4a ("efi/x86: Fix build with gcc 4").Ard points out that RHEL 7 uses gcc-4.8, but the people who stay back onold RHEL versions persumably also don't build their own kernels anyway.And maybe they should cross-built or just have a little side affair witha newer compiler?Acked-by: Ard Biesheuvel Acked-by: Peter Zijlstra Signed-off-by: Linus Torvalds List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

541ad015 - arm: Remove 32bit KVM host support

Fri, 24 Jan 2020 22:42:15 +0000

arm: Remove 32bit KVM host supportThat's it. Remove all references to KVM itself, and documentthat although it is no more, the ABI between SVC and HYP stillexists.Signed-off-by: Marc Zyngier Acked-by: Olof Johansson Acked-by: Arnd Bergmann Acked-by: Will Deacon Acked-by: Vladimir Murzin Acked-by: Catalin Marinas Acked-by: Linus Walleij Acked-by: Christoffer Dall List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

d2912cb1 - treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

Tue, 04 Jun 2019 08:11:33 +0000

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation #extracted by the scancode license scanner the SPDX license identifier GPL-2.0-onlyhas been chosen to replace the boilerplate/reference in 4122 file(s).Signed-off-by: Thomas Gleixner Reviewed-by: Enrico Weigelt Reviewed-by: Kate Stewart Reviewed-by: Allison Randal Cc: linux-spdx@vger.kernel.orgLink: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.deSigned-off-by: Greg Kroah-Hartman List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

189af465 - ARM: smp: add support for per-task stack canaries

Thu, 06 Dec 2018 08:32:57 +0000

ARM: smp: add support for per-task stack canariesOn ARM, we currently only change the value of the stack canary whenswitching tasks if the kernel was built for UP. On SMP kernels, thisis impossible since the stack canary value is obtained via a globalsymbol reference, which meansa) all running tasks on all CPUs must use the same valueb) we can only modify the value when no kernel stack frames are live on any CPU, which is effectively never.So instead, use a GCC plugin to add a RTL pass that replaces eachreference to the address of the __stack_chk_guard symbol with anexpression that produces the address of the 'stack_canary' fieldthat is added to struct thread_info. This way, each task will useits own randomized value.Cc: Russell King Cc: Kees Cook Cc: Emese Revfy Cc: Arnd Bergmann Cc: Laura Abbott Cc: kernel-hardening@lists.openwall.comAcked-by: Nicolas Pitre Signed-off-by: Ard Biesheuvel Signed-off-by: Kees Cook List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

815f0ddb - include/linux/compiler.h: make compiler-.h mutually exclusive

Wed, 22 Aug 2018 23:37:24 +0000

include/linux/compiler*.h: make compiler-*.h mutually exclusiveCommit cafa0010cd51 ("Raise the minimum required gcc version to 4.6")recently exposed a brittle part of the build for supporting non-gcccompilers.Both Clang and ICC define __GNUC__, __GNUC_MINOR__, and__GNUC_PATCHLEVEL__ for quick compatibility with code bases that haven'tadded compiler specific checks for __clang__ or __INTEL_COMPILER.This is brittle, as they happened to get compatibility by posing as acertain version of GCC. This broke when upgrading the minimal versionof GCC required to build the kernel, to a version above what ICC andClang claim to be.Rather than always including compiler-gcc.h then undefining orredefining macros in compiler-intel.h or compiler-clang.h, let'sseparate out the compiler specific macro definitions into mutuallyexclusive headers, do more proper compiler detection, and keep shareddefinitions in compiler_types.h.Fixes: cafa0010cd51 ("Raise the minimum required gcc version to 4.6")Reported-by: Masahiro Yamada Suggested-by: Eli Friedman Suggested-by: Joe Perches Signed-off-by: Nick Desaulniers Signed-off-by: Linus Torvalds List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c

050e9baa - Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables

Thu, 14 Jun 2018 03:21:18 +0000

Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variablesThe changes to automatically test for working stack protector compilersupport in the Kconfig files removed the special STACKPROTECTOR_AUTOoption that picked the strongest stack protector that the compilersupported.That was all a nice cleanup - it makes no sense to have the AUTO casenow that the Kconfig phase can just determine the compiler supportdirectly.HOWEVER.It also meant that doing "make oldconfig" would now _disable_ the strongstackprotector if you had AUTO enabled, because in a legacy config file,the sane stack protector configuration would look like CONFIG_HAVE_CC_STACKPROTECTOR=y # CONFIG_CC_STACKPROTECTOR_NONE is not set # CONFIG_CC_STACKPROTECTOR_REGULAR is not set # CONFIG_CC_STACKPROTECTOR_STRONG is not set CONFIG_CC_STACKPROTECTOR_AUTO=yand when you ran this through "make oldconfig" with the Kbuild changes,it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that hadbeen renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to justCONFIG_CC_STACKPROTECTOR), but it would think that the STRONG versionused to be disabled (because it was really enabled by AUTO), and woulddisable it in the new config, resulting in: CONFIG_HAVE_CC_STACKPROTECTOR=y CONFIG_CC_HAS_STACKPROTECTOR_NONE=y CONFIG_CC_STACKPROTECTOR=y # CONFIG_CC_STACKPROTECTOR_STRONG is not set CONFIG_CC_HAS_SANE_STACKPROTECTOR=yThat's dangerously subtle - people could suddenly find themselves withthe weaker stack protector setup without even realizing.The solution here is to just rename not just the old RECULAR stackprotector option, but also the strong one. This does that by justremoving the CC_ prefix entirely for the user choices, because it reallyis not about the compiler support (the compiler support now insteadautomatially impacts _visibility_ of the options to users).This results in "make oldconfig" actually asking the user for theirchoice, so that we don't have any silent subtle security model changes.The end result would generally look like this: CONFIG_HAVE_CC_STACKPROTECTOR=y CONFIG_CC_HAS_STACKPROTECTOR_NONE=y CONFIG_STACKPROTECTOR=y CONFIG_STACKPROTECTOR_STRONG=y CONFIG_CC_HAS_SANE_STACKPROTECTOR=ywhere the "CC_" versions really are about internal compilerinfrastructure, not the user selections.Acked-by: Masahiro Yamada Signed-off-by: Linus Torvalds List of files: /linux-6.15/arch/arm/kernel/asm-offsets.c