Loading Documentation/admin-guide/hw-vuln/spectre.rst +80 −8 Original line number Original line Diff line number Diff line Loading @@ -41,10 +41,11 @@ Related CVEs The following CVE entries describe Spectre variants: The following CVE entries describe Spectre variants: ============= ======================= ================= ============= ======================= ========================== CVE-2017-5753 Bounds check bypass Spectre variant 1 CVE-2017-5753 Bounds check bypass Spectre variant 1 CVE-2017-5715 Branch target injection Spectre variant 2 CVE-2017-5715 Branch target injection Spectre variant 2 ============= ======================= ================= CVE-2019-1125 Spectre v1 swapgs Spectre variant 1 (swapgs) ============= ======================= ========================== Problem Problem ------- ------- Loading Loading @@ -78,6 +79,13 @@ There are some extensions of Spectre variant 1 attacks for reading data over the network, see :ref:`[12] <spec_ref12>`. However such attacks over the network, see :ref:`[12] <spec_ref12>`. However such attacks are difficult, low bandwidth, fragile, and are considered low risk. are difficult, low bandwidth, fragile, and are considered low risk. Note that, despite "Bounds Check Bypass" name, Spectre variant 1 is not only about user-controlled array bounds checks. It can affect any conditional checks. The kernel entry code interrupt, exception, and NMI handlers all have conditional swapgs checks. Those may be problematic in the context of Spectre v1, as kernel code can speculatively run with a user GS. Spectre variant 2 (Branch Target Injection) Spectre variant 2 (Branch Target Injection) ------------------------------------------- ------------------------------------------- Loading Loading @@ -132,6 +140,9 @@ not cover all possible attack vectors. 1. A user process attacking the kernel 1. A user process attacking the kernel ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Spectre variant 1 ~~~~~~~~~~~~~~~~~ The attacker passes a parameter to the kernel via a register or The attacker passes a parameter to the kernel via a register or via a known address in memory during a syscall. Such parameter may via a known address in memory during a syscall. Such parameter may be used later by the kernel as an index to an array or to derive be used later by the kernel as an index to an array or to derive Loading @@ -144,7 +155,40 @@ not cover all possible attack vectors. potentially be influenced for Spectre attacks, new "nospec" accessor potentially be influenced for Spectre attacks, new "nospec" accessor macros are used to prevent speculative loading of data. macros are used to prevent speculative loading of data. Spectre variant 2 attacker can :ref:`poison <poison_btb>` the branch Spectre variant 1 (swapgs) ~~~~~~~~~~~~~~~~~~~~~~~~~~ An attacker can train the branch predictor to speculatively skip the swapgs path for an interrupt or exception. If they initialize the GS register to a user-space value, if the swapgs is speculatively skipped, subsequent GS-related percpu accesses in the speculation window will be done with the attacker-controlled GS value. This could cause privileged memory to be accessed and leaked. For example: :: if (coming from user space) swapgs mov %gs:<percpu_offset>, %reg mov (%reg), %reg1 When coming from user space, the CPU can speculatively skip the swapgs, and then do a speculative percpu load using the user GS value. So the user can speculatively force a read of any kernel value. If a gadget exists which uses the percpu value as an address in another load/store, then the contents of the kernel value may become visible via an L1 side channel attack. A similar attack exists when coming from kernel space. The CPU can speculatively do the swapgs, causing the user GS to get used for the rest of the speculative window. Spectre variant 2 ~~~~~~~~~~~~~~~~~ A spectre variant 2 attacker can :ref:`poison <poison_btb>` the branch target buffer (BTB) before issuing syscall to launch an attack. target buffer (BTB) before issuing syscall to launch an attack. After entering the kernel, the kernel could use the poisoned branch After entering the kernel, the kernel could use the poisoned branch target buffer on indirect jump and jump to gadget code in speculative target buffer on indirect jump and jump to gadget code in speculative Loading Loading @@ -280,11 +324,18 @@ The sysfs file showing Spectre variant 1 mitigation status is: The possible values in this file are: The possible values in this file are: ======================================= ================================= .. list-table:: 'Mitigation: __user pointer sanitation' Protection in kernel on a case by case base with explicit pointer * - 'Not affected' sanitation. - The processor is not vulnerable. ======================================= ================================= * - 'Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers' - The swapgs protections are disabled; otherwise it has protection in the kernel on a case by case base with explicit pointer sanitation and usercopy LFENCE barriers. * - 'Mitigation: usercopy/swapgs barriers and __user pointer sanitization' - Protection in the kernel on a case by case base with explicit pointer sanitation, usercopy LFENCE barriers, and swapgs LFENCE barriers. However, the protections are put in place on a case by case basis, However, the protections are put in place on a case by case basis, and there is no guarantee that all possible attack vectors for Spectre and there is no guarantee that all possible attack vectors for Spectre Loading Loading @@ -366,12 +417,27 @@ Turning on mitigation for Spectre variant 1 and Spectre variant 2 1. Kernel mitigation 1. Kernel mitigation ^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^ Spectre variant 1 ~~~~~~~~~~~~~~~~~ For the Spectre variant 1, vulnerable kernel code (as determined For the Spectre variant 1, vulnerable kernel code (as determined by code audit or scanning tools) is annotated on a case by case by code audit or scanning tools) is annotated on a case by case basis to use nospec accessor macros for bounds clipping :ref:`[2] basis to use nospec accessor macros for bounds clipping :ref:`[2] <spec_ref2>` to avoid any usable disclosure gadgets. However, it may <spec_ref2>` to avoid any usable disclosure gadgets. However, it may not cover all attack vectors for Spectre variant 1. not cover all attack vectors for Spectre variant 1. Copy-from-user code has an LFENCE barrier to prevent the access_ok() check from being mis-speculated. The barrier is done by the barrier_nospec() macro. For the swapgs variant of Spectre variant 1, LFENCE barriers are added to interrupt, exception and NMI entry where needed. These barriers are done by the FENCE_SWAPGS_KERNEL_ENTRY and FENCE_SWAPGS_USER_ENTRY macros. Spectre variant 2 ~~~~~~~~~~~~~~~~~ For Spectre variant 2 mitigation, the compiler turns indirect calls or For Spectre variant 2 mitigation, the compiler turns indirect calls or jumps in the kernel into equivalent return trampolines (retpolines) jumps in the kernel into equivalent return trampolines (retpolines) :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` to go to the target :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` to go to the target Loading Loading @@ -473,6 +539,12 @@ Mitigation control on the kernel command line Spectre variant 2 mitigation can be disabled or force enabled at the Spectre variant 2 mitigation can be disabled or force enabled at the kernel command line. kernel command line. nospectre_v1 [X86,PPC] Disable mitigations for Spectre Variant 1 (bounds check bypass). With this option data leaks are possible in the system. nospectre_v2 nospectre_v2 [X86] Disable all mitigations for the Spectre variant 2 [X86] Disable all mitigations for the Spectre variant 2 Loading Documentation/admin-guide/kernel-parameters.txt +4 −3 Original line number Original line Diff line number Diff line Loading @@ -2522,6 +2522,7 @@ Equivalent to: nopti [X86,PPC] Equivalent to: nopti [X86,PPC] nospectre_v1 [PPC] nospectre_v1 [PPC] nobp=0 [S390] nobp=0 [S390] nospectre_v1 [X86] nospectre_v2 [X86,PPC,S390] nospectre_v2 [X86,PPC,S390] spectre_v2_user=off [X86] spectre_v2_user=off [X86] spec_store_bypass_disable=off [X86,PPC] spec_store_bypass_disable=off [X86,PPC] Loading Loading @@ -2868,9 +2869,9 @@ nosmt=force: Force disable SMT, cannot be undone nosmt=force: Force disable SMT, cannot be undone via the sysfs control file. via the sysfs control file. nospectre_v1 [PPC] Disable mitigations for Spectre Variant 1 (bounds nospectre_v1 [X66, PPC] Disable mitigations for Spectre Variant 1 check bypass). With this option data leaks are possible (bounds check bypass). With this option data leaks in the system. are possible in the system. nospectre_v2 [X86,PPC_FSL_BOOK3E] Disable all mitigations for the Spectre variant 2 nospectre_v2 [X86,PPC_FSL_BOOK3E] Disable all mitigations for the Spectre variant 2 (indirect branch prediction) vulnerability. System may (indirect branch prediction) vulnerability. System may Loading Makefile +4 −2 Original line number Original line Diff line number Diff line # SPDX-License-Identifier: GPL-2.0 # SPDX-License-Identifier: GPL-2.0 VERSION = 4 VERSION = 4 PATCHLEVEL = 19 PATCHLEVEL = 19 SUBLEVEL = 62 SUBLEVEL = 66 EXTRAVERSION = EXTRAVERSION = NAME = "People's Front" NAME = "People's Front" Loading Loading @@ -434,6 +434,7 @@ KBUILD_CFLAGS_MODULE := -DMODULE KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds KBUILD_LDFLAGS := KBUILD_LDFLAGS := GCC_PLUGINS_CFLAGS := GCC_PLUGINS_CFLAGS := CLANG_FLAGS := export ARCH SRCARCH CONFIG_SHELL HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE AS LD CC export ARCH SRCARCH CONFIG_SHELL HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE AS LD CC export CPP AR NM STRIP OBJCOPY OBJDUMP KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS export CPP AR NM STRIP OBJCOPY OBJDUMP KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS Loading Loading @@ -487,7 +488,7 @@ endif ifeq ($(cc-name),clang) ifeq ($(cc-name),clang) ifneq ($(CROSS_COMPILE),) ifneq ($(CROSS_COMPILE),) CLANG_TRIPLE ?= $(CROSS_COMPILE) CLANG_TRIPLE ?= $(CROSS_COMPILE) CLANG_FLAGS := --target=$(notdir $(CLANG_TRIPLE:%-=%)) CLANG_FLAGS += --target=$(notdir $(CLANG_TRIPLE:%-=%)) ifeq ($(shell $(srctree)/scripts/clang-android.sh $(CC) $(CLANG_FLAGS)), y) ifeq ($(shell $(srctree)/scripts/clang-android.sh $(CC) $(CLANG_FLAGS)), y) $(error "Clang with Android --target detected. Did you specify CLANG_TRIPLE?") $(error "Clang with Android --target detected. Did you specify CLANG_TRIPLE?") endif endif Loading @@ -499,6 +500,7 @@ ifneq ($(GCC_TOOLCHAIN),) CLANG_FLAGS += --gcc-toolchain=$(GCC_TOOLCHAIN) CLANG_FLAGS += --gcc-toolchain=$(GCC_TOOLCHAIN) endif endif CLANG_FLAGS += -no-integrated-as CLANG_FLAGS += -no-integrated-as CLANG_FLAGS += -Werror=unknown-warning-option KBUILD_CFLAGS += $(CLANG_FLAGS) KBUILD_CFLAGS += $(CLANG_FLAGS) KBUILD_AFLAGS += $(CLANG_FLAGS) KBUILD_AFLAGS += $(CLANG_FLAGS) export CLANG_FLAGS export CLANG_FLAGS Loading arch/arc/Kconfig +0 −13 Original line number Original line Diff line number Diff line Loading @@ -199,7 +199,6 @@ config NR_CPUS config ARC_SMP_HALT_ON_RESET config ARC_SMP_HALT_ON_RESET bool "Enable Halt-on-reset boot mode" bool "Enable Halt-on-reset boot mode" default y if ARC_UBOOT_SUPPORT help help In SMP configuration cores can be configured as Halt-on-reset In SMP configuration cores can be configured as Halt-on-reset or they could all start at same time. For Halt-on-reset, non or they could all start at same time. For Halt-on-reset, non Loading Loading @@ -539,18 +538,6 @@ config ARC_DBG_TLB_PARANOIA endif endif config ARC_UBOOT_SUPPORT bool "Support uboot arg Handling" default n help ARC Linux by default checks for uboot provided args as pointers to external cmdline or DTB. This however breaks in absence of uboot, when booting from Metaware debugger directly, as the registers are not zeroed out on reset by mdb and/or ARCv2 based cores. The bogus registers look like uboot args to kernel which then chokes. So only enable the uboot arg checking/processing if users are sure of uboot being in play. config ARC_BUILTIN_DTB_NAME config ARC_BUILTIN_DTB_NAME string "Built in DTB" string "Built in DTB" help help Loading arch/arc/configs/nps_defconfig +0 −1 Original line number Original line Diff line number Diff line Loading @@ -31,7 +31,6 @@ CONFIG_ARC_CACHE_LINE_SHIFT=5 # CONFIG_ARC_HAS_LLSC is not set # CONFIG_ARC_HAS_LLSC is not set CONFIG_ARC_KVADDR_SIZE=402 CONFIG_ARC_KVADDR_SIZE=402 CONFIG_ARC_EMUL_UNALIGNED=y CONFIG_ARC_EMUL_UNALIGNED=y CONFIG_ARC_UBOOT_SUPPORT=y CONFIG_PREEMPT=y CONFIG_PREEMPT=y CONFIG_NET=y CONFIG_NET=y CONFIG_UNIX=y CONFIG_UNIX=y Loading Loading
Documentation/admin-guide/hw-vuln/spectre.rst +80 −8 Original line number Original line Diff line number Diff line Loading @@ -41,10 +41,11 @@ Related CVEs The following CVE entries describe Spectre variants: The following CVE entries describe Spectre variants: ============= ======================= ================= ============= ======================= ========================== CVE-2017-5753 Bounds check bypass Spectre variant 1 CVE-2017-5753 Bounds check bypass Spectre variant 1 CVE-2017-5715 Branch target injection Spectre variant 2 CVE-2017-5715 Branch target injection Spectre variant 2 ============= ======================= ================= CVE-2019-1125 Spectre v1 swapgs Spectre variant 1 (swapgs) ============= ======================= ========================== Problem Problem ------- ------- Loading Loading @@ -78,6 +79,13 @@ There are some extensions of Spectre variant 1 attacks for reading data over the network, see :ref:`[12] <spec_ref12>`. However such attacks over the network, see :ref:`[12] <spec_ref12>`. However such attacks are difficult, low bandwidth, fragile, and are considered low risk. are difficult, low bandwidth, fragile, and are considered low risk. Note that, despite "Bounds Check Bypass" name, Spectre variant 1 is not only about user-controlled array bounds checks. It can affect any conditional checks. The kernel entry code interrupt, exception, and NMI handlers all have conditional swapgs checks. Those may be problematic in the context of Spectre v1, as kernel code can speculatively run with a user GS. Spectre variant 2 (Branch Target Injection) Spectre variant 2 (Branch Target Injection) ------------------------------------------- ------------------------------------------- Loading Loading @@ -132,6 +140,9 @@ not cover all possible attack vectors. 1. A user process attacking the kernel 1. A user process attacking the kernel ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Spectre variant 1 ~~~~~~~~~~~~~~~~~ The attacker passes a parameter to the kernel via a register or The attacker passes a parameter to the kernel via a register or via a known address in memory during a syscall. Such parameter may via a known address in memory during a syscall. Such parameter may be used later by the kernel as an index to an array or to derive be used later by the kernel as an index to an array or to derive Loading @@ -144,7 +155,40 @@ not cover all possible attack vectors. potentially be influenced for Spectre attacks, new "nospec" accessor potentially be influenced for Spectre attacks, new "nospec" accessor macros are used to prevent speculative loading of data. macros are used to prevent speculative loading of data. Spectre variant 2 attacker can :ref:`poison <poison_btb>` the branch Spectre variant 1 (swapgs) ~~~~~~~~~~~~~~~~~~~~~~~~~~ An attacker can train the branch predictor to speculatively skip the swapgs path for an interrupt or exception. If they initialize the GS register to a user-space value, if the swapgs is speculatively skipped, subsequent GS-related percpu accesses in the speculation window will be done with the attacker-controlled GS value. This could cause privileged memory to be accessed and leaked. For example: :: if (coming from user space) swapgs mov %gs:<percpu_offset>, %reg mov (%reg), %reg1 When coming from user space, the CPU can speculatively skip the swapgs, and then do a speculative percpu load using the user GS value. So the user can speculatively force a read of any kernel value. If a gadget exists which uses the percpu value as an address in another load/store, then the contents of the kernel value may become visible via an L1 side channel attack. A similar attack exists when coming from kernel space. The CPU can speculatively do the swapgs, causing the user GS to get used for the rest of the speculative window. Spectre variant 2 ~~~~~~~~~~~~~~~~~ A spectre variant 2 attacker can :ref:`poison <poison_btb>` the branch target buffer (BTB) before issuing syscall to launch an attack. target buffer (BTB) before issuing syscall to launch an attack. After entering the kernel, the kernel could use the poisoned branch After entering the kernel, the kernel could use the poisoned branch target buffer on indirect jump and jump to gadget code in speculative target buffer on indirect jump and jump to gadget code in speculative Loading Loading @@ -280,11 +324,18 @@ The sysfs file showing Spectre variant 1 mitigation status is: The possible values in this file are: The possible values in this file are: ======================================= ================================= .. list-table:: 'Mitigation: __user pointer sanitation' Protection in kernel on a case by case base with explicit pointer * - 'Not affected' sanitation. - The processor is not vulnerable. ======================================= ================================= * - 'Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers' - The swapgs protections are disabled; otherwise it has protection in the kernel on a case by case base with explicit pointer sanitation and usercopy LFENCE barriers. * - 'Mitigation: usercopy/swapgs barriers and __user pointer sanitization' - Protection in the kernel on a case by case base with explicit pointer sanitation, usercopy LFENCE barriers, and swapgs LFENCE barriers. However, the protections are put in place on a case by case basis, However, the protections are put in place on a case by case basis, and there is no guarantee that all possible attack vectors for Spectre and there is no guarantee that all possible attack vectors for Spectre Loading Loading @@ -366,12 +417,27 @@ Turning on mitigation for Spectre variant 1 and Spectre variant 2 1. Kernel mitigation 1. Kernel mitigation ^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^ Spectre variant 1 ~~~~~~~~~~~~~~~~~ For the Spectre variant 1, vulnerable kernel code (as determined For the Spectre variant 1, vulnerable kernel code (as determined by code audit or scanning tools) is annotated on a case by case by code audit or scanning tools) is annotated on a case by case basis to use nospec accessor macros for bounds clipping :ref:`[2] basis to use nospec accessor macros for bounds clipping :ref:`[2] <spec_ref2>` to avoid any usable disclosure gadgets. However, it may <spec_ref2>` to avoid any usable disclosure gadgets. However, it may not cover all attack vectors for Spectre variant 1. not cover all attack vectors for Spectre variant 1. Copy-from-user code has an LFENCE barrier to prevent the access_ok() check from being mis-speculated. The barrier is done by the barrier_nospec() macro. For the swapgs variant of Spectre variant 1, LFENCE barriers are added to interrupt, exception and NMI entry where needed. These barriers are done by the FENCE_SWAPGS_KERNEL_ENTRY and FENCE_SWAPGS_USER_ENTRY macros. Spectre variant 2 ~~~~~~~~~~~~~~~~~ For Spectre variant 2 mitigation, the compiler turns indirect calls or For Spectre variant 2 mitigation, the compiler turns indirect calls or jumps in the kernel into equivalent return trampolines (retpolines) jumps in the kernel into equivalent return trampolines (retpolines) :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` to go to the target :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` to go to the target Loading Loading @@ -473,6 +539,12 @@ Mitigation control on the kernel command line Spectre variant 2 mitigation can be disabled or force enabled at the Spectre variant 2 mitigation can be disabled or force enabled at the kernel command line. kernel command line. nospectre_v1 [X86,PPC] Disable mitigations for Spectre Variant 1 (bounds check bypass). With this option data leaks are possible in the system. nospectre_v2 nospectre_v2 [X86] Disable all mitigations for the Spectre variant 2 [X86] Disable all mitigations for the Spectre variant 2 Loading
Documentation/admin-guide/kernel-parameters.txt +4 −3 Original line number Original line Diff line number Diff line Loading @@ -2522,6 +2522,7 @@ Equivalent to: nopti [X86,PPC] Equivalent to: nopti [X86,PPC] nospectre_v1 [PPC] nospectre_v1 [PPC] nobp=0 [S390] nobp=0 [S390] nospectre_v1 [X86] nospectre_v2 [X86,PPC,S390] nospectre_v2 [X86,PPC,S390] spectre_v2_user=off [X86] spectre_v2_user=off [X86] spec_store_bypass_disable=off [X86,PPC] spec_store_bypass_disable=off [X86,PPC] Loading Loading @@ -2868,9 +2869,9 @@ nosmt=force: Force disable SMT, cannot be undone nosmt=force: Force disable SMT, cannot be undone via the sysfs control file. via the sysfs control file. nospectre_v1 [PPC] Disable mitigations for Spectre Variant 1 (bounds nospectre_v1 [X66, PPC] Disable mitigations for Spectre Variant 1 check bypass). With this option data leaks are possible (bounds check bypass). With this option data leaks in the system. are possible in the system. nospectre_v2 [X86,PPC_FSL_BOOK3E] Disable all mitigations for the Spectre variant 2 nospectre_v2 [X86,PPC_FSL_BOOK3E] Disable all mitigations for the Spectre variant 2 (indirect branch prediction) vulnerability. System may (indirect branch prediction) vulnerability. System may Loading
Makefile +4 −2 Original line number Original line Diff line number Diff line # SPDX-License-Identifier: GPL-2.0 # SPDX-License-Identifier: GPL-2.0 VERSION = 4 VERSION = 4 PATCHLEVEL = 19 PATCHLEVEL = 19 SUBLEVEL = 62 SUBLEVEL = 66 EXTRAVERSION = EXTRAVERSION = NAME = "People's Front" NAME = "People's Front" Loading Loading @@ -434,6 +434,7 @@ KBUILD_CFLAGS_MODULE := -DMODULE KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds KBUILD_LDFLAGS := KBUILD_LDFLAGS := GCC_PLUGINS_CFLAGS := GCC_PLUGINS_CFLAGS := CLANG_FLAGS := export ARCH SRCARCH CONFIG_SHELL HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE AS LD CC export ARCH SRCARCH CONFIG_SHELL HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE AS LD CC export CPP AR NM STRIP OBJCOPY OBJDUMP KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS export CPP AR NM STRIP OBJCOPY OBJDUMP KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS Loading Loading @@ -487,7 +488,7 @@ endif ifeq ($(cc-name),clang) ifeq ($(cc-name),clang) ifneq ($(CROSS_COMPILE),) ifneq ($(CROSS_COMPILE),) CLANG_TRIPLE ?= $(CROSS_COMPILE) CLANG_TRIPLE ?= $(CROSS_COMPILE) CLANG_FLAGS := --target=$(notdir $(CLANG_TRIPLE:%-=%)) CLANG_FLAGS += --target=$(notdir $(CLANG_TRIPLE:%-=%)) ifeq ($(shell $(srctree)/scripts/clang-android.sh $(CC) $(CLANG_FLAGS)), y) ifeq ($(shell $(srctree)/scripts/clang-android.sh $(CC) $(CLANG_FLAGS)), y) $(error "Clang with Android --target detected. Did you specify CLANG_TRIPLE?") $(error "Clang with Android --target detected. Did you specify CLANG_TRIPLE?") endif endif Loading @@ -499,6 +500,7 @@ ifneq ($(GCC_TOOLCHAIN),) CLANG_FLAGS += --gcc-toolchain=$(GCC_TOOLCHAIN) CLANG_FLAGS += --gcc-toolchain=$(GCC_TOOLCHAIN) endif endif CLANG_FLAGS += -no-integrated-as CLANG_FLAGS += -no-integrated-as CLANG_FLAGS += -Werror=unknown-warning-option KBUILD_CFLAGS += $(CLANG_FLAGS) KBUILD_CFLAGS += $(CLANG_FLAGS) KBUILD_AFLAGS += $(CLANG_FLAGS) KBUILD_AFLAGS += $(CLANG_FLAGS) export CLANG_FLAGS export CLANG_FLAGS Loading
arch/arc/Kconfig +0 −13 Original line number Original line Diff line number Diff line Loading @@ -199,7 +199,6 @@ config NR_CPUS config ARC_SMP_HALT_ON_RESET config ARC_SMP_HALT_ON_RESET bool "Enable Halt-on-reset boot mode" bool "Enable Halt-on-reset boot mode" default y if ARC_UBOOT_SUPPORT help help In SMP configuration cores can be configured as Halt-on-reset In SMP configuration cores can be configured as Halt-on-reset or they could all start at same time. For Halt-on-reset, non or they could all start at same time. For Halt-on-reset, non Loading Loading @@ -539,18 +538,6 @@ config ARC_DBG_TLB_PARANOIA endif endif config ARC_UBOOT_SUPPORT bool "Support uboot arg Handling" default n help ARC Linux by default checks for uboot provided args as pointers to external cmdline or DTB. This however breaks in absence of uboot, when booting from Metaware debugger directly, as the registers are not zeroed out on reset by mdb and/or ARCv2 based cores. The bogus registers look like uboot args to kernel which then chokes. So only enable the uboot arg checking/processing if users are sure of uboot being in play. config ARC_BUILTIN_DTB_NAME config ARC_BUILTIN_DTB_NAME string "Built in DTB" string "Built in DTB" help help Loading
arch/arc/configs/nps_defconfig +0 −1 Original line number Original line Diff line number Diff line Loading @@ -31,7 +31,6 @@ CONFIG_ARC_CACHE_LINE_SHIFT=5 # CONFIG_ARC_HAS_LLSC is not set # CONFIG_ARC_HAS_LLSC is not set CONFIG_ARC_KVADDR_SIZE=402 CONFIG_ARC_KVADDR_SIZE=402 CONFIG_ARC_EMUL_UNALIGNED=y CONFIG_ARC_EMUL_UNALIGNED=y CONFIG_ARC_UBOOT_SUPPORT=y CONFIG_PREEMPT=y CONFIG_PREEMPT=y CONFIG_NET=y CONFIG_NET=y CONFIG_UNIX=y CONFIG_UNIX=y Loading
