* [PATCHv3 0/3] clean up KPTI / SDEI trampoline data alignment
@ 2020-03-19 9:12 Rémi Denis-Courmont
2020-03-19 9:14 ` [PATCH 1/3] arm64: clean up trampoline vector loads Rémi Denis-Courmont
` (4 more replies)
0 siblings, 5 replies; 16+ messages in thread
From: Rémi Denis-Courmont @ 2020-03-19 9:12 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, linux-arm-kernel
Cc: Mark Rutland, James Morse, linux-kernel
Hi,
The KPTI and SDE trampolines each load a pointer from the same fixmap data
page. This reduces the data alignment to the useful value, and tries to
clarify the assembler code.
Changes since v2:
- Retain alignment even when SDEI is disabled to keep ld happy.
----------------------------------------------------------------
Rémi Denis-Courmont (3):
arm64: clean up trampoline vector loads
arm64/sdei: gather trampolines' .rodata
arm64: reduce trampoline data alignment
arch/arm64/kernel/entry.S | 23 ++++++++++-------------
arch/arm64/mm/mmu.c | 5 ++---
2 files changed, 12 insertions(+), 16 deletions(-)
--
Реми Дёни-Курмон
http://www.remlab.net/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 1/3] arm64: clean up trampoline vector loads
2020-03-19 9:12 [PATCHv3 0/3] clean up KPTI / SDEI trampoline data alignment Rémi Denis-Courmont
@ 2020-03-19 9:14 ` Rémi Denis-Courmont
2020-03-23 12:07 ` Mark Rutland
2020-03-19 9:14 ` [PATCH 2/3] arm64/sdei: gather trampolines' .rodata Rémi Denis-Courmont
` (3 subsequent siblings)
4 siblings, 1 reply; 16+ messages in thread
From: Rémi Denis-Courmont @ 2020-03-19 9:14 UTC (permalink / raw)
To: catalin.marinas, will, linux-arm-kernel
Cc: mark.rutland, james.morse, linux-kernel
From: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
This switches from custom instruction patterns to the regular large
memory model sequence with ADRP and LDR. In doing so, the ADD
instruction can be eliminated in the SDEI handler, and the code no
longer assumes that the trampoline vectors and the vectors address both
start on a page boundary.
Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
---
arch/arm64/kernel/entry.S | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index e5d4e30ee242..24f828739696 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -805,9 +805,9 @@ alternative_else_nop_endif
2:
tramp_map_kernel x30
#ifdef CONFIG_RANDOMIZE_BASE
- adr x30, tramp_vectors + PAGE_SIZE
+ adrp x30, tramp_vectors + PAGE_SIZE
alternative_insn isb, nop, ARM64_WORKAROUND_QCOM_FALKOR_E1003
- ldr x30, [x30]
+ ldr x30, [x30, #:lo12:__entry_tramp_data_start]
#else
ldr x30, =vectors
#endif
@@ -953,9 +953,8 @@ SYM_CODE_START(__sdei_asm_entry_trampoline)
1: str x4, [x1, #(SDEI_EVENT_INTREGS + S_ORIG_ADDR_LIMIT)]
#ifdef CONFIG_RANDOMIZE_BASE
- adr x4, tramp_vectors + PAGE_SIZE
- add x4, x4, #:lo12:__sdei_asm_trampoline_next_handler
- ldr x4, [x4]
+ adrp x4, tramp_vectors + PAGE_SIZE
+ ldr x4, [x4, #:lo12:__sdei_asm_trampoline_next_handler]
#else
ldr x4, =__sdei_asm_handler
#endif
--
2.26.0.rc2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH 2/3] arm64/sdei: gather trampolines' .rodata
2020-03-19 9:12 [PATCHv3 0/3] clean up KPTI / SDEI trampoline data alignment Rémi Denis-Courmont
2020-03-19 9:14 ` [PATCH 1/3] arm64: clean up trampoline vector loads Rémi Denis-Courmont
@ 2020-03-19 9:14 ` Rémi Denis-Courmont
2020-03-19 9:14 ` [PATCH 3/3] arm64: reduce trampoline data alignment Rémi Denis-Courmont
` (2 subsequent siblings)
4 siblings, 0 replies; 16+ messages in thread
From: Rémi Denis-Courmont @ 2020-03-19 9:14 UTC (permalink / raw)
To: catalin.marinas, will, linux-arm-kernel
Cc: mark.rutland, james.morse, linux-kernel
From: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
This gathers the two bits of data together for clarity.
Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
---
arch/arm64/kernel/entry.S | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 24f828739696..c36733d8cd75 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -862,6 +862,11 @@ SYM_CODE_END(tramp_exit_compat)
SYM_DATA_START(__entry_tramp_data_start)
.quad vectors
SYM_DATA_END(__entry_tramp_data_start)
+#ifdef CONFIG_ARM_SDE_INTERFACE
+SYM_DATA_START(__sdei_asm_trampoline_next_handler)
+ .quad __sdei_asm_handler
+SYM_DATA_END(__sdei_asm_trampoline_next_handler)
+#endif /* CONFIG_ARM_SDE_INTERFACE */
.popsection // .rodata
#endif /* CONFIG_RANDOMIZE_BASE */
#endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
@@ -980,13 +985,6 @@ SYM_CODE_END(__sdei_asm_exit_trampoline)
NOKPROBE(__sdei_asm_exit_trampoline)
.ltorg
.popsection // .entry.tramp.text
-#ifdef CONFIG_RANDOMIZE_BASE
-.pushsection ".rodata", "a"
-SYM_DATA_START(__sdei_asm_trampoline_next_handler)
- .quad __sdei_asm_handler
-SYM_DATA_END(__sdei_asm_trampoline_next_handler)
-.popsection // .rodata
-#endif /* CONFIG_RANDOMIZE_BASE */
#endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
/*
--
2.26.0.rc2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH 3/3] arm64: reduce trampoline data alignment
2020-03-19 9:12 [PATCHv3 0/3] clean up KPTI / SDEI trampoline data alignment Rémi Denis-Courmont
2020-03-19 9:14 ` [PATCH 1/3] arm64: clean up trampoline vector loads Rémi Denis-Courmont
2020-03-19 9:14 ` [PATCH 2/3] arm64/sdei: gather trampolines' .rodata Rémi Denis-Courmont
@ 2020-03-19 9:14 ` Rémi Denis-Courmont
2020-03-21 13:40 ` Catalin Marinas
2020-03-19 18:37 ` [PATCHv3 0/3] clean up KPTI / SDEI " Will Deacon
2020-03-20 16:54 ` Catalin Marinas
4 siblings, 1 reply; 16+ messages in thread
From: Rémi Denis-Courmont @ 2020-03-19 9:14 UTC (permalink / raw)
To: catalin.marinas, will, linux-arm-kernel
Cc: mark.rutland, james.morse, linux-kernel
From: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
The trampoline data, currently consisting of two relocated pointers,
must be within a single page. However, there are no needs for it to
start a page.
This reduces the alignment to 16 bytes, which is sufficient to ensure
that the data is entirely within a single page of the fixmap.
Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
---
arch/arm64/kernel/entry.S | 2 +-
arch/arm64/mm/mmu.c | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index c36733d8cd75..ecad15443655 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -858,7 +858,7 @@ SYM_CODE_END(tramp_exit_compat)
.popsection // .entry.tramp.text
#ifdef CONFIG_RANDOMIZE_BASE
.pushsection ".rodata", "a"
- .align PAGE_SHIFT
+ .align 4 // all .rodata must be in a single fixmap page
SYM_DATA_START(__entry_tramp_data_start)
.quad vectors
SYM_DATA_END(__entry_tramp_data_start)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 9b08f7c7e6f0..6a0e75f48e7b 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -599,9 +599,8 @@ static int __init map_entry_trampoline(void)
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
extern char __entry_tramp_data_start[];
- __set_fixmap(FIX_ENTRY_TRAMP_DATA,
- __pa_symbol(__entry_tramp_data_start),
- PAGE_KERNEL_RO);
+ pa_start = __pa_symbol(__entry_tramp_data_start) & PAGE_MASK;
+ __set_fixmap(FIX_ENTRY_TRAMP_DATA, pa_start, PAGE_KERNEL_RO);
}
return 0;
--
2.26.0.rc2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCHv3 0/3] clean up KPTI / SDEI trampoline data alignment
2020-03-19 9:12 [PATCHv3 0/3] clean up KPTI / SDEI trampoline data alignment Rémi Denis-Courmont
` (2 preceding siblings ...)
2020-03-19 9:14 ` [PATCH 3/3] arm64: reduce trampoline data alignment Rémi Denis-Courmont
@ 2020-03-19 18:37 ` Will Deacon
2020-03-20 16:54 ` Catalin Marinas
4 siblings, 0 replies; 16+ messages in thread
From: Will Deacon @ 2020-03-19 18:37 UTC (permalink / raw)
To: Rémi Denis-Courmont
Cc: Mark Rutland, Catalin Marinas, James Morse, linux-kernel,
linux-arm-kernel
On Thu, Mar 19, 2020 at 11:12:56AM +0200, Rémi Denis-Courmont wrote:
> Hi,
>
> The KPTI and SDE trampolines each load a pointer from the same fixmap data
> page. This reduces the data alignment to the useful value, and tries to
> clarify the assembler code.
>
> Changes since v2:
> - Retain alignment even when SDEI is disabled to keep ld happy.
>
> ----------------------------------------------------------------
> Rémi Denis-Courmont (3):
> arm64: clean up trampoline vector loads
> arm64/sdei: gather trampolines' .rodata
> arm64: reduce trampoline data alignment
For the series:
Acked-by: Will Deacon <will@kernel.org>
[in future please don't drop acks from patches that haven't changed, cheers]
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCHv3 0/3] clean up KPTI / SDEI trampoline data alignment
2020-03-19 9:12 [PATCHv3 0/3] clean up KPTI / SDEI trampoline data alignment Rémi Denis-Courmont
` (3 preceding siblings ...)
2020-03-19 18:37 ` [PATCHv3 0/3] clean up KPTI / SDEI " Will Deacon
@ 2020-03-20 16:54 ` Catalin Marinas
4 siblings, 0 replies; 16+ messages in thread
From: Catalin Marinas @ 2020-03-20 16:54 UTC (permalink / raw)
To: Rémi Denis-Courmont
Cc: Mark Rutland, James Morse, Will Deacon, linux-kernel,
linux-arm-kernel
On Thu, Mar 19, 2020 at 11:12:56AM +0200, Rémi Denis-Courmont wrote:
> Hi,
>
> The KPTI and SDE trampolines each load a pointer from the same fixmap data
> page. This reduces the data alignment to the useful value, and tries to
> clarify the assembler code.
>
> Changes since v2:
> - Retain alignment even when SDEI is disabled to keep ld happy.
I queued v2. Thanks.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] arm64: reduce trampoline data alignment
2020-03-19 9:14 ` [PATCH 3/3] arm64: reduce trampoline data alignment Rémi Denis-Courmont
@ 2020-03-21 13:40 ` Catalin Marinas
2020-03-23 11:58 ` Mark Rutland
0 siblings, 1 reply; 16+ messages in thread
From: Catalin Marinas @ 2020-03-21 13:40 UTC (permalink / raw)
To: Rémi Denis-Courmont
Cc: mark.rutland, james.morse, will, linux-kernel, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]
On Thu, Mar 19, 2020 at 11:14:07AM +0200, Rémi Denis-Courmont wrote:
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index c36733d8cd75..ecad15443655 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -858,7 +858,7 @@ SYM_CODE_END(tramp_exit_compat)
> .popsection // .entry.tramp.text
> #ifdef CONFIG_RANDOMIZE_BASE
> .pushsection ".rodata", "a"
> - .align PAGE_SHIFT
> + .align 4 // all .rodata must be in a single fixmap page
> SYM_DATA_START(__entry_tramp_data_start)
> .quad vectors
> SYM_DATA_END(__entry_tramp_data_start)
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 9b08f7c7e6f0..6a0e75f48e7b 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -599,9 +599,8 @@ static int __init map_entry_trampoline(void)
> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> extern char __entry_tramp_data_start[];
>
> - __set_fixmap(FIX_ENTRY_TRAMP_DATA,
> - __pa_symbol(__entry_tramp_data_start),
> - PAGE_KERNEL_RO);
> + pa_start = __pa_symbol(__entry_tramp_data_start) & PAGE_MASK;
> + __set_fixmap(FIX_ENTRY_TRAMP_DATA, pa_start, PAGE_KERNEL_RO);
> }
>
> return 0;
For some reason, I haven't investigated yet, a kernel with KASAN and 64K
pages enabled does not boot (see the attached config). It seems to lock
up when starting user space. Bisected to this commit, reverting it fixes
the issue.
--
Catalin
[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 10654 bytes --]
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_AUDIT=y
CONFIG_NO_HZ_IDLE=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT=y
CONFIG_IRQ_TIME_ACCOUNTING=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_NUMA_BALANCING=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_BLK_CGROUP=y
CONFIG_CGROUP_PIDS=y
CONFIG_CGROUP_HUGETLB=y
CONFIG_CPUSETS=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_PERF=y
CONFIG_USER_NS=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_COMPAT_BRK is not set
CONFIG_PROFILING=y
CONFIG_ARM64_64K_PAGES=y
CONFIG_NUMA=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
CONFIG_HIBERNATION=y
CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y
CONFIG_EFI_CAPSULE_LOADER=y
CONFIG_JUMP_LABEL=y
CONFIG_COMPAT_32BIT_TIME=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_BLK_DEV_INTEGRITY=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_KSM=y
CONFIG_MEMORY_FAILURE=y
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IPV6=m
CONFIG_NETFILTER=y
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m
CONFIG_NETFILTER_XT_TARGET_LOG=m
CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_NAT=m
CONFIG_IP6_NF_TARGET_MASQUERADE=m
CONFIG_BRIDGE=m
CONFIG_BRIDGE_VLAN_FILTERING=y
CONFIG_VLAN_8021Q=m
CONFIG_VLAN_8021Q_GVRP=y
CONFIG_VLAN_8021Q_MVRP=y
CONFIG_BPF_JIT=y
CONFIG_BT=m
CONFIG_BT_HIDP=m
# CONFIG_BT_HS is not set
# CONFIG_BT_LE is not set
CONFIG_BT_LEDS=y
# CONFIG_BT_DEBUGFS is not set
CONFIG_BT_HCIBTUSB=m
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_LL=y
CONFIG_BT_HCIUART_BCM=y
CONFIG_BT_HCIUART_QCA=y
CONFIG_CFG80211=m
CONFIG_MAC80211=m
CONFIG_MAC80211_LEDS=y
CONFIG_RFKILL=m
CONFIG_NET_9P=y
CONFIG_NET_9P_VIRTIO=y
CONFIG_PCI=y
CONFIG_PCIEPORTBUS=y
CONFIG_PCI_IOV=y
CONFIG_HOTPLUG_PCI=y
CONFIG_PCI_HOST_GENERIC=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_FW_LOADER_USER_HELPER=y
CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
CONFIG_SIMPLE_PM_BUS=y
CONFIG_MTD=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_RAW_NAND=y
CONFIG_MTD_NAND_DENALI_DT=y
CONFIG_MTD_SPI_NOR=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=m
CONFIG_VIRTIO_BLK=y
CONFIG_BLK_DEV_NVME=m
CONFIG_SRAM=y
CONFIG_EEPROM_AT25=m
# CONFIG_SCSI_PROC_FS is not set
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_SAS_LIBSAS=y
CONFIG_SCSI_SAS_ATA=y
CONFIG_SCSI_MPT3SAS=m
CONFIG_SCSI_UFSHCD=y
CONFIG_SCSI_UFSHCD_PLATFORM=y
CONFIG_ATA=y
CONFIG_SATA_AHCI=y
CONFIG_SATA_AHCI_PLATFORM=y
CONFIG_AHCI_CEVA=y
CONFIG_AHCI_QORIQ=y
CONFIG_SATA_SIL24=y
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
CONFIG_BLK_DEV_DM=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_NETDEVICES=y
CONFIG_MACVLAN=m
CONFIG_MACVTAP=m
CONFIG_TUN=y
CONFIG_VETH=m
CONFIG_VIRTIO_NET=y
CONFIG_AMD_XGBE=y
CONFIG_ATL1C=m
CONFIG_BCMGENET=m
CONFIG_BNX2X=m
CONFIG_MACB=y
CONFIG_THUNDER_NIC_PF=y
CONFIG_E1000E=y
CONFIG_IGB=y
CONFIG_IGBVF=y
CONFIG_MVMDIO=y
CONFIG_SKY2=y
CONFIG_MLX4_EN=m
CONFIG_MLX5_CORE=m
CONFIG_MLX5_CORE_EN=y
CONFIG_QCOM_EMAC=m
CONFIG_SMSC911X=y
CONFIG_STMMAC_ETH=m
CONFIG_MDIO_BITBANG=y
CONFIG_MDIO_BUS_MUX_MMIOREG=y
CONFIG_MARVELL_PHY=m
CONFIG_MARVELL_10G_PHY=m
CONFIG_MICREL_PHY=y
CONFIG_AT803X_PHY=y
CONFIG_REALTEK_PHY=m
CONFIG_ROCKCHIP_PHY=y
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_RTL8152=m
CONFIG_USB_LAN78XX=m
CONFIG_USB_USBNET=m
CONFIG_USB_NET_DM9601=m
CONFIG_USB_NET_SR9800=m
CONFIG_USB_NET_SMSC75XX=m
CONFIG_USB_NET_SMSC95XX=m
CONFIG_USB_NET_PLUSB=m
CONFIG_USB_NET_MCS7830=m
CONFIG_ATH10K=m
CONFIG_ATH10K_PCI=m
CONFIG_BRCMFMAC=m
CONFIG_MWIFIEX=m
CONFIG_MWIFIEX_PCIE=m
CONFIG_WL18XX=m
CONFIG_WLCORE_SDIO=m
CONFIG_INPUT_EVDEV=y
CONFIG_KEYBOARD_ADC=m
CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_CROS_EC=y
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ATMEL_MXT=m
CONFIG_INPUT_MISC=y
# CONFIG_SERIO_SERPORT is not set
CONFIG_LEGACY_PTY_COUNT=16
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DW=y
CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_SERIAL_XILINX_PS_UART=y
CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y
CONFIG_SERIAL_FSL_LPUART=y
CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
CONFIG_SERIAL_FSL_LINFLEXUART=y
CONFIG_SERIAL_FSL_LINFLEXUART_CONSOLE=y
CONFIG_SERIAL_DEV_BUS=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_IPMI_HANDLER=m
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS_I2C_INFINEON=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_MUX=y
CONFIG_I2C_MUX_PCA954x=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
CONFIG_I2C_GPIO=m
CONFIG_I2C_RK3X=y
CONFIG_I2C_CROS_EC_TUNNEL=y
CONFIG_I2C_SLAVE=y
CONFIG_SPI=y
CONFIG_SPI_BITBANG=m
CONFIG_SPI_NXP_FLEXSPI=y
CONFIG_SPI_ROCKCHIP=y
CONFIG_SPI_SPIDEV=m
CONFIG_SPMI=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_SINGLE=y
CONFIG_PINCTRL_MAX77620=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_ALTERA=m
CONFIG_GPIO_DWAPB=y
CONFIG_GPIO_GENERIC_PLATFORM=y
CONFIG_GPIO_MB86S7X=y
CONFIG_GPIO_MAX732X=y
CONFIG_GPIO_PCA953X=y
CONFIG_GPIO_PCA953X_IRQ=y
CONFIG_GPIO_MAX77620=y
CONFIG_POWER_AVS=y
CONFIG_QCOM_CPR=y
CONFIG_POWER_RESET_SYSCON=y
CONFIG_SYSCON_REBOOT_MODE=y
CONFIG_BATTERY_SBS=m
CONFIG_BATTERY_BQ27XXX=y
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_PWM_FAN=m
CONFIG_SENSORS_INA2XX=m
CONFIG_SENSORS_INA3221=m
CONFIG_CPU_THERMAL=y
CONFIG_THERMAL_EMULATION=y
CONFIG_QORIQ_THERMAL=m
CONFIG_WATCHDOG=y
CONFIG_DW_WATCHDOG=y
CONFIG_MFD_BD9571MWV=y
CONFIG_MFD_AXP20X_I2C=y
CONFIG_MFD_HI6421_PMIC=y
CONFIG_MFD_MAX77620=y
CONFIG_MFD_RK808=y
CONFIG_MFD_SEC_CORE=y
CONFIG_MFD_ROHM_BD718XX=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_AXP20X=y
CONFIG_REGULATOR_BD718XX=y
CONFIG_REGULATOR_BD9571MWV=y
CONFIG_REGULATOR_FAN53555=y
CONFIG_REGULATOR_GPIO=y
CONFIG_REGULATOR_HI6421V530=y
CONFIG_REGULATOR_MAX77620=y
CONFIG_REGULATOR_MAX8973=y
CONFIG_REGULATOR_PFUZE100=y
CONFIG_REGULATOR_PWM=y
CONFIG_REGULATOR_QCOM_SPMI=y
CONFIG_REGULATOR_RK808=y
CONFIG_REGULATOR_S2MPS11=y
CONFIG_REGULATOR_VCTRL=m
CONFIG_RC_CORE=m
CONFIG_RC_DECODERS=y
CONFIG_RC_DEVICES=y
CONFIG_MEDIA_SUPPORT=m
CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_MEDIA_ANALOG_TV_SUPPORT=y
CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y
CONFIG_MEDIA_CONTROLLER=y
CONFIG_VIDEO_V4L2_SUBDEV_API=y
# CONFIG_DVB_NET is not set
CONFIG_MEDIA_USB_SUPPORT=y
CONFIG_USB_VIDEO_CLASS=m
CONFIG_V4L_PLATFORM_DRIVERS=y
CONFIG_V4L_MEM2MEM_DRIVERS=y
CONFIG_DRM=m
CONFIG_DRM_I2C_NXP_TDA998X=m
CONFIG_DRM_NOUVEAU=m
CONFIG_DRM_RCAR_LVDS=m
CONFIG_DRM_PANEL_SIMPLE=m
CONFIG_DRM_SII902X=m
CONFIG_DRM_TI_SN65DSI86=m
CONFIG_DRM_I2C_ADV7511=m
CONFIG_DRM_ETNAVIV=m
CONFIG_FB=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_EFI=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=m
CONFIG_BACKLIGHT_PWM=m
CONFIG_BACKLIGHT_LP855X=m
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_DYNAMIC_MINORS=y
CONFIG_SND_SOC=y
CONFIG_SND_SOC_AK4613=m
CONFIG_SND_SOC_DMIC=m
CONFIG_SND_SOC_ES7134=m
CONFIG_SND_SOC_ES7241=m
CONFIG_SND_SOC_MAX98357A=m
CONFIG_SND_SOC_PCM3168A_I2C=m
CONFIG_SND_SOC_SPDIF=m
CONFIG_SND_SOC_TAS571X=m
CONFIG_SND_SIMPLE_CARD=m
CONFIG_SND_AUDIO_GRAPH_CARD=m
CONFIG_I2C_HID=m
CONFIG_USB_CONN_GPIO=m
CONFIG_USB=y
CONFIG_USB_OTG=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_HCD_PLATFORM=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_PLATFORM=y
CONFIG_USB_STORAGE=y
CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_DWC3=y
CONFIG_USB_DWC2=y
CONFIG_USB_CHIPIDEA=y
CONFIG_USB_CHIPIDEA_UDC=y
CONFIG_USB_CHIPIDEA_HOST=y
CONFIG_USB_ISP1760=y
CONFIG_USB_HSIC_USB3503=y
CONFIG_NOP_USB_XCEIV=y
CONFIG_USB_GADGET=y
CONFIG_USB_SNP_UDC_PLAT=y
CONFIG_USB_BDC_UDC=y
CONFIG_TYPEC=m
CONFIG_TYPEC_TCPM=m
CONFIG_TYPEC_FUSB302=m
CONFIG_TYPEC_HD3SS3220=m
CONFIG_MMC=y
CONFIG_MMC_BLOCK_MINORS=32
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_MMC_SDHCI_OF_ARASAN=y
CONFIG_MMC_SDHCI_CADENCE=y
CONFIG_MMC_SDHCI_F_SDH30=y
CONFIG_MMC_SPI=y
CONFIG_MMC_SDHCI_XENON=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
CONFIG_LEDS_GPIO=y
CONFIG_LEDS_PWM=y
CONFIG_LEDS_SYSCON=y
CONFIG_LEDS_TRIGGER_DISK=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_CPU=y
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
CONFIG_LEDS_TRIGGER_PANIC=y
CONFIG_EDAC=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_MAX77686=y
CONFIG_RTC_DRV_RK808=m
CONFIG_RTC_DRV_RX8581=m
CONFIG_RTC_DRV_S5M=y
CONFIG_RTC_DRV_DS3232=y
CONFIG_RTC_DRV_CROS_EC=y
CONFIG_RTC_DRV_SNVS=m
CONFIG_DMADEVICES=y
CONFIG_FSL_EDMA=y
CONFIG_QCOM_HIDMA_MGMT=y
CONFIG_QCOM_HIDMA=y
CONFIG_VFIO=y
CONFIG_VFIO_PCI=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_BALLOON=y
CONFIG_VIRTIO_MMIO=y
CONFIG_MFD_CROS_EC=y
CONFIG_CROS_EC_I2C=y
CONFIG_CROS_EC_SPI=y
CONFIG_COMMON_CLK_RK808=y
CONFIG_COMMON_CLK_CS2000_CP=y
CONFIG_COMMON_CLK_S2MPS11=y
CONFIG_COMMON_CLK_PWM=y
CONFIG_HWSPINLOCK=y
CONFIG_REMOTEPROC=y
CONFIG_SOC_TI=y
CONFIG_EXTCON_USB_GPIO=y
CONFIG_EXTCON_USBC_CROS_EC=y
CONFIG_MEMORY=y
CONFIG_IIO=y
CONFIG_QCOM_SPMI_ADC5=m
CONFIG_IIO_CROS_EC_SENSORS_CORE=m
CONFIG_IIO_CROS_EC_SENSORS=m
CONFIG_IIO_CROS_EC_LIGHT_PROX=m
CONFIG_SENSORS_ISL29018=m
CONFIG_IIO_CROS_EC_BARO=m
CONFIG_MPL3115=m
CONFIG_PWM=y
CONFIG_PWM_CROS_EC=m
CONFIG_RESET_BRCMSTB_RESCAL=y
CONFIG_PHY_FSL_IMX8MQ_USB=y
CONFIG_PHY_QCOM_USB_HS=y
CONFIG_PHY_SAMSUNG_USB2=y
CONFIG_FPGA=y
CONFIG_FPGA_BRIDGE=m
CONFIG_ALTERA_FREEZE_BRIDGE=m
CONFIG_FPGA_REGION=m
CONFIG_OF_FPGA_REGION=m
CONFIG_TEE=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_XFS_FS=y
CONFIG_XFS_QUOTA=y
CONFIG_BTRFS_FS=m
CONFIG_BTRFS_FS_POSIX_ACL=y
CONFIG_FANOTIFY=y
CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y
CONFIG_QUOTA=y
CONFIG_AUTOFS4_FS=y
CONFIG_FUSE_FS=m
CONFIG_CUSE=m
CONFIG_OVERLAY_FS=m
CONFIG_VFAT_FS=y
CONFIG_HUGETLBFS=y
CONFIG_CONFIGFS_FS=y
CONFIG_EFIVAR_FS=y
CONFIG_SQUASHFS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V4=y
CONFIG_NFS_V4_1=y
CONFIG_NFS_V4_2=y
CONFIG_ROOT_NFS=y
CONFIG_9P_FS=y
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ISO8859_1=y
CONFIG_SECURITY=y
CONFIG_CRYPTO_CRYPTD=y
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_ECHAINIV=y
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_SHA3=m
CONFIG_CRYPTO_SM3=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_ANSI_CPRNG=y
CONFIG_CRYPTO_USER_API_RNG=m
CONFIG_CRYPTO_DEV_AMLOGIC_GXL=y
CONFIG_CRC_CCITT=m
CONFIG_CMA_SIZE_MBYTES=32
CONFIG_PRINTK_TIME=y
CONFIG_DEBUG_INFO=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_KASAN=y
CONFIG_KASAN_INLINE=y
# CONFIG_SCHED_DEBUG is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_FTRACE is not set
CONFIG_LKDTM=y
CONFIG_MEMTEST=y
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 3/3] arm64: reduce trampoline data alignment
2020-03-21 13:40 ` Catalin Marinas
@ 2020-03-23 11:58 ` Mark Rutland
0 siblings, 0 replies; 16+ messages in thread
From: Mark Rutland @ 2020-03-23 11:58 UTC (permalink / raw)
To: Catalin Marinas
Cc: james.morse, will, linux-arm-kernel, Rémi Denis-Courmont,
linux-kernel
On Sat, Mar 21, 2020 at 01:41:01PM +0000, Catalin Marinas wrote:
> On Thu, Mar 19, 2020 at 11:14:07AM +0200, Rémi Denis-Courmont wrote:
> > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > index c36733d8cd75..ecad15443655 100644
> > --- a/arch/arm64/kernel/entry.S
> > +++ b/arch/arm64/kernel/entry.S
> > @@ -858,7 +858,7 @@ SYM_CODE_END(tramp_exit_compat)
> > .popsection // .entry.tramp.text
> > #ifdef CONFIG_RANDOMIZE_BASE
> > .pushsection ".rodata", "a"
> > - .align PAGE_SHIFT
> > + .align 4 // all .rodata must be in a single fixmap page
> > SYM_DATA_START(__entry_tramp_data_start)
> > .quad vectors
> > SYM_DATA_END(__entry_tramp_data_start)
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index 9b08f7c7e6f0..6a0e75f48e7b 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -599,9 +599,8 @@ static int __init map_entry_trampoline(void)
> > if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> > extern char __entry_tramp_data_start[];
> >
> > - __set_fixmap(FIX_ENTRY_TRAMP_DATA,
> > - __pa_symbol(__entry_tramp_data_start),
> > - PAGE_KERNEL_RO);
> > + pa_start = __pa_symbol(__entry_tramp_data_start) & PAGE_MASK;
> > + __set_fixmap(FIX_ENTRY_TRAMP_DATA, pa_start, PAGE_KERNEL_RO);
> > }
> >
> > return 0;
>
> For some reason, I haven't investigated yet, a kernel with KASAN and 64K
> pages enabled does not boot (see the attached config). It seems to lock
> up when starting user space. Bisected to this commit, reverting it fixes
> the issue.
I think the issue might be due to ADRP + ADD :lo12: using 4K offsets,
and so patch 1 isn't quite right for !4K kernels, as we're not
accounting for 4 bits of the address when we try to generate it.
I'll check that now.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] arm64: clean up trampoline vector loads
2020-03-19 9:14 ` [PATCH 1/3] arm64: clean up trampoline vector loads Rémi Denis-Courmont
@ 2020-03-23 12:07 ` Mark Rutland
2020-03-23 12:08 ` Rémi Denis-Courmont
0 siblings, 1 reply; 16+ messages in thread
From: Mark Rutland @ 2020-03-23 12:07 UTC (permalink / raw)
To: Rémi Denis-Courmont
Cc: catalin.marinas, will, james.morse, linux-arm-kernel,
linux-kernel
On Thu, Mar 19, 2020 at 11:14:05AM +0200, Rémi Denis-Courmont wrote:
> From: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
>
> This switches from custom instruction patterns to the regular large
> memory model sequence with ADRP and LDR. In doing so, the ADD
> instruction can be eliminated in the SDEI handler, and the code no
> longer assumes that the trampoline vectors and the vectors address both
> start on a page boundary.
>
> Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
> ---
> arch/arm64/kernel/entry.S | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index e5d4e30ee242..24f828739696 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -805,9 +805,9 @@ alternative_else_nop_endif
> 2:
> tramp_map_kernel x30
> #ifdef CONFIG_RANDOMIZE_BASE
> - adr x30, tramp_vectors + PAGE_SIZE
> + adrp x30, tramp_vectors + PAGE_SIZE
> alternative_insn isb, nop, ARM64_WORKAROUND_QCOM_FALKOR_E1003
> - ldr x30, [x30]
> + ldr x30, [x30, #:lo12:__entry_tramp_data_start]
I think this is busted for !4K kernels once we reduce the alignment of
__entry_tramp_data_start.
The ADRP gives us a 64K aligned address (with bits 15:0 clear). The lo12
relocation gives us bits 11:0, so we haven't accounted for bits 15:12.
I think that's what's causing the hang Catalin sees with 64K pages (and
would also be a problem for 16K pages).
Ideally, we'd account for those bits with the ADRP, but I'm not sure
that an ELF relocation can encode symbol + addr + symbol:15-12, so we
likely nned more instructions to explicitly mask that in.
... either that, or leave this page aligned.
> #else
> ldr x30, =vectors
> #endif
> @@ -953,9 +953,8 @@ SYM_CODE_START(__sdei_asm_entry_trampoline)
> 1: str x4, [x1, #(SDEI_EVENT_INTREGS + S_ORIG_ADDR_LIMIT)]
>
> #ifdef CONFIG_RANDOMIZE_BASE
> - adr x4, tramp_vectors + PAGE_SIZE
> - add x4, x4, #:lo12:__sdei_asm_trampoline_next_handler
> - ldr x4, [x4]
> + adrp x4, tramp_vectors + PAGE_SIZE
> + ldr x4, [x4, #:lo12:__sdei_asm_trampoline_next_handler]
Likewise here.
Thanks,
Mark.
> #else
> ldr x4, =__sdei_asm_handler
> #endif
> --
> 2.26.0.rc2
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] arm64: clean up trampoline vector loads
2020-03-23 12:07 ` Mark Rutland
@ 2020-03-23 12:08 ` Rémi Denis-Courmont
2020-03-23 12:14 ` Mark Rutland
0 siblings, 1 reply; 16+ messages in thread
From: Rémi Denis-Courmont @ 2020-03-23 12:08 UTC (permalink / raw)
To: Mark Rutland
Cc: catalin.marinas, will, james.morse, linux-arm-kernel,
linux-kernel
Le maanantaina 23. maaliskuuta 2020, 14.07.00 EET Mark Rutland a écrit :
> On Thu, Mar 19, 2020 at 11:14:05AM +0200, Rémi Denis-Courmont wrote:
> > From: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
> >
> > This switches from custom instruction patterns to the regular large
> > memory model sequence with ADRP and LDR. In doing so, the ADD
> > instruction can be eliminated in the SDEI handler, and the code no
> > longer assumes that the trampoline vectors and the vectors address both
> > start on a page boundary.
> >
> > Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
> > ---
> >
> > arch/arm64/kernel/entry.S | 9 ++++-----
> > 1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > index e5d4e30ee242..24f828739696 100644
> > --- a/arch/arm64/kernel/entry.S
> > +++ b/arch/arm64/kernel/entry.S
> > @@ -805,9 +805,9 @@ alternative_else_nop_endif
> >
> > 2:
> > tramp_map_kernel x30
> >
> > #ifdef CONFIG_RANDOMIZE_BASE
> >
> > - adr x30, tramp_vectors + PAGE_SIZE
> > + adrp x30, tramp_vectors + PAGE_SIZE
> >
> > alternative_insn isb, nop, ARM64_WORKAROUND_QCOM_FALKOR_E1003
> >
> > - ldr x30, [x30]
> > + ldr x30, [x30, #:lo12:__entry_tramp_data_start]
>
> I think this is busted for !4K kernels once we reduce the alignment of
> __entry_tramp_data_start.
>
> The ADRP gives us a 64K aligned address (with bits 15:0 clear). The lo12
> relocation gives us bits 11:0, so we haven't accounted for bits 15:12.
IMU, ADRP gives a 4K aligned value, regardless of MMU (TCR) settings.
I rather suspect that the problem is with my C code diff assuming that
PAGE_MASK is 4095.
--
Rémi Denis-Courmont
http://www.remlab.net/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] arm64: clean up trampoline vector loads
2020-03-23 12:08 ` Rémi Denis-Courmont
@ 2020-03-23 12:14 ` Mark Rutland
2020-03-23 19:04 ` Catalin Marinas
0 siblings, 1 reply; 16+ messages in thread
From: Mark Rutland @ 2020-03-23 12:14 UTC (permalink / raw)
To: Rémi Denis-Courmont
Cc: catalin.marinas, will, james.morse, linux-arm-kernel,
linux-kernel
On Mon, Mar 23, 2020 at 02:08:53PM +0200, Rémi Denis-Courmont wrote:
> Le maanantaina 23. maaliskuuta 2020, 14.07.00 EET Mark Rutland a écrit :
> > On Thu, Mar 19, 2020 at 11:14:05AM +0200, Rémi Denis-Courmont wrote:
> > > From: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
> > >
> > > This switches from custom instruction patterns to the regular large
> > > memory model sequence with ADRP and LDR. In doing so, the ADD
> > > instruction can be eliminated in the SDEI handler, and the code no
> > > longer assumes that the trampoline vectors and the vectors address both
> > > start on a page boundary.
> > >
> > > Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
> > > ---
> > >
> > > arch/arm64/kernel/entry.S | 9 ++++-----
> > > 1 file changed, 4 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > > index e5d4e30ee242..24f828739696 100644
> > > --- a/arch/arm64/kernel/entry.S
> > > +++ b/arch/arm64/kernel/entry.S
> > > @@ -805,9 +805,9 @@ alternative_else_nop_endif
> > >
> > > 2:
> > > tramp_map_kernel x30
> > >
> > > #ifdef CONFIG_RANDOMIZE_BASE
> > >
> > > - adr x30, tramp_vectors + PAGE_SIZE
> > > + adrp x30, tramp_vectors + PAGE_SIZE
> > >
> > > alternative_insn isb, nop, ARM64_WORKAROUND_QCOM_FALKOR_E1003
> > >
> > > - ldr x30, [x30]
> > > + ldr x30, [x30, #:lo12:__entry_tramp_data_start]
> >
> > I think this is busted for !4K kernels once we reduce the alignment of
> > __entry_tramp_data_start.
> >
> > The ADRP gives us a 64K aligned address (with bits 15:0 clear). The lo12
> > relocation gives us bits 11:0, so we haven't accounted for bits 15:12.
>
> IMU, ADRP gives a 4K aligned value, regardless of MMU (TCR) settings.
Sorry, I had erroneously assumed tramp_vectors was page aligned. The
issue still stands -- we haven't accounted for bits 15:12, as those can
differ between tramp_vectors and __entry_tramp_data_start.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] arm64: clean up trampoline vector loads
2020-03-23 12:14 ` Mark Rutland
@ 2020-03-23 19:04 ` Catalin Marinas
2020-03-23 20:42 ` Rémi Denis-Courmont
0 siblings, 1 reply; 16+ messages in thread
From: Catalin Marinas @ 2020-03-23 19:04 UTC (permalink / raw)
To: Mark Rutland
Cc: james.morse, will, linux-arm-kernel, Rémi Denis-Courmont,
linux-kernel
On Mon, Mar 23, 2020 at 12:14:37PM +0000, Mark Rutland wrote:
> On Mon, Mar 23, 2020 at 02:08:53PM +0200, Rémi Denis-Courmont wrote:
> > Le maanantaina 23. maaliskuuta 2020, 14.07.00 EET Mark Rutland a écrit :
> > > On Thu, Mar 19, 2020 at 11:14:05AM +0200, Rémi Denis-Courmont wrote:
> > > > From: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
> > > >
> > > > This switches from custom instruction patterns to the regular large
> > > > memory model sequence with ADRP and LDR. In doing so, the ADD
> > > > instruction can be eliminated in the SDEI handler, and the code no
> > > > longer assumes that the trampoline vectors and the vectors address both
> > > > start on a page boundary.
> > > >
> > > > Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
> > > > ---
> > > >
> > > > arch/arm64/kernel/entry.S | 9 ++++-----
> > > > 1 file changed, 4 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > > > index e5d4e30ee242..24f828739696 100644
> > > > --- a/arch/arm64/kernel/entry.S
> > > > +++ b/arch/arm64/kernel/entry.S
> > > > @@ -805,9 +805,9 @@ alternative_else_nop_endif
> > > >
> > > > 2:
> > > > tramp_map_kernel x30
> > > >
> > > > #ifdef CONFIG_RANDOMIZE_BASE
> > > >
> > > > - adr x30, tramp_vectors + PAGE_SIZE
> > > > + adrp x30, tramp_vectors + PAGE_SIZE
> > > >
> > > > alternative_insn isb, nop, ARM64_WORKAROUND_QCOM_FALKOR_E1003
> > > >
> > > > - ldr x30, [x30]
> > > > + ldr x30, [x30, #:lo12:__entry_tramp_data_start]
> > >
> > > I think this is busted for !4K kernels once we reduce the alignment of
> > > __entry_tramp_data_start.
> > >
> > > The ADRP gives us a 64K aligned address (with bits 15:0 clear). The lo12
> > > relocation gives us bits 11:0, so we haven't accounted for bits 15:12.
> >
> > IMU, ADRP gives a 4K aligned value, regardless of MMU (TCR) settings.
>
> Sorry, I had erroneously assumed tramp_vectors was page aligned. The
> issue still stands -- we haven't accounted for bits 15:12, as those can
> differ between tramp_vectors and __entry_tramp_data_start.
Should we just use adrp on __entry_tramp_data_start? Anyway, the diff
below doesn't solve the issue I'm seeing (only reverting patch 3).
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index ca1340eb46d8..4cc9d1df3985 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -810,7 +810,7 @@ alternative_else_nop_endif
2:
tramp_map_kernel x30
#ifdef CONFIG_RANDOMIZE_BASE
- adrp x30, tramp_vectors + PAGE_SIZE
+ adrp x30, __entry_tramp_data_start
alternative_insn isb, nop, ARM64_WORKAROUND_QCOM_FALKOR_E1003
ldr x30, [x30, #:lo12:__entry_tramp_data_start]
#else
@@ -964,7 +964,7 @@ SYM_CODE_START(__sdei_asm_entry_trampoline)
1: str x4, [x1, #(SDEI_EVENT_INTREGS + S_ORIG_ADDR_LIMIT)]
#ifdef CONFIG_RANDOMIZE_BASE
- adrp x4, tramp_vectors + PAGE_SIZE
+ adrp x4, __sdei_asm_trampoline_next_handler
ldr x4, [x4, #:lo12:__sdei_asm_trampoline_next_handler]
#else
ldr x4, =__sdei_asm_handler
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] arm64: clean up trampoline vector loads
2020-03-23 19:04 ` Catalin Marinas
@ 2020-03-23 20:42 ` Rémi Denis-Courmont
2020-03-24 10:37 ` Catalin Marinas
2020-03-24 10:52 ` Mark Rutland
0 siblings, 2 replies; 16+ messages in thread
From: Rémi Denis-Courmont @ 2020-03-23 20:42 UTC (permalink / raw)
To: Catalin Marinas
Cc: Mark Rutland, james.morse, will, linux-kernel, linux-arm-kernel
Le maanantaina 23. maaliskuuta 2020, 21.04.09 EET Catalin Marinas a écrit :
> On Mon, Mar 23, 2020 at 12:14:37PM +0000, Mark Rutland wrote:
> > On Mon, Mar 23, 2020 at 02:08:53PM +0200, Rémi Denis-Courmont wrote:
> > > Le maanantaina 23. maaliskuuta 2020, 14.07.00 EET Mark Rutland a écrit :
> > > > On Thu, Mar 19, 2020 at 11:14:05AM +0200, Rémi Denis-Courmont wrote:
> > > > > From: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
> > > > >
> > > > > This switches from custom instruction patterns to the regular large
> > > > > memory model sequence with ADRP and LDR. In doing so, the ADD
> > > > > instruction can be eliminated in the SDEI handler, and the code no
> > > > > longer assumes that the trampoline vectors and the vectors address
> > > > > both
> > > > > start on a page boundary.
> > > > >
> > > > > Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
> > > > > ---
> > > > >
> > > > > arch/arm64/kernel/entry.S | 9 ++++-----
> > > > > 1 file changed, 4 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > > > > index e5d4e30ee242..24f828739696 100644
> > > > > --- a/arch/arm64/kernel/entry.S
> > > > > +++ b/arch/arm64/kernel/entry.S
> > > > > @@ -805,9 +805,9 @@ alternative_else_nop_endif
> > > > >
> > > > > 2:
> > > > > tramp_map_kernel x30
> > > > >
> > > > > #ifdef CONFIG_RANDOMIZE_BASE
> > > > >
> > > > > - adr x30, tramp_vectors + PAGE_SIZE
> > > > > + adrp x30, tramp_vectors + PAGE_SIZE
> > > > >
> > > > > alternative_insn isb, nop, ARM64_WORKAROUND_QCOM_FALKOR_E1003
> > > > >
> > > > > - ldr x30, [x30]
> > > > > + ldr x30, [x30, #:lo12:__entry_tramp_data_start]
> > > >
> > > > I think this is busted for !4K kernels once we reduce the alignment of
> > > > __entry_tramp_data_start.
> > > >
> > > > The ADRP gives us a 64K aligned address (with bits 15:0 clear). The
> > > > lo12
> > > > relocation gives us bits 11:0, so we haven't accounted for bits 15:12.
> > >
> > > IMU, ADRP gives a 4K aligned value, regardless of MMU (TCR) settings.
> >
> > Sorry, I had erroneously assumed tramp_vectors was page aligned. The
> > issue still stands -- we haven't accounted for bits 15:12, as those can
> > differ between tramp_vectors and __entry_tramp_data_start.
Does that mean that the SDEI code never worked with page size > 4 KiB?
> Should we just use adrp on __entry_tramp_data_start? Anyway, the diff
> below doesn't solve the issue I'm seeing (only reverting patch 3).
AFAIU, the preexisting code uses the manual PAGE_SIZE offset because the offset
in the main vmlinux does not match the architected offset inside the fixmap. If
so, then using the symbol directly will not work at all.
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index ca1340eb46d8..4cc9d1df3985 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -810,7 +810,7 @@ alternative_else_nop_endif
> 2:
> tramp_map_kernel x30
> #ifdef CONFIG_RANDOMIZE_BASE
> - adrp x30, tramp_vectors + PAGE_SIZE
> + adrp x30, __entry_tramp_data_start
> alternative_insn isb, nop, ARM64_WORKAROUND_QCOM_FALKOR_E1003
> ldr x30, [x30, #:lo12:__entry_tramp_data_start]
> #else
> @@ -964,7 +964,7 @@ SYM_CODE_START(__sdei_asm_entry_trampoline)
> 1: str x4, [x1, #(SDEI_EVENT_INTREGS + S_ORIG_ADDR_LIMIT)]
>
> #ifdef CONFIG_RANDOMIZE_BASE
> - adrp x4, tramp_vectors + PAGE_SIZE
> + adrp x4, __sdei_asm_trampoline_next_handler
> ldr x4, [x4, #:lo12:__sdei_asm_trampoline_next_handler]
> #else
> ldr x4, =__sdei_asm_handler
--
雷米‧德尼-库尔蒙
http://www.remlab.net/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] arm64: clean up trampoline vector loads
2020-03-23 20:42 ` Rémi Denis-Courmont
@ 2020-03-24 10:37 ` Catalin Marinas
2020-03-24 10:52 ` Mark Rutland
1 sibling, 0 replies; 16+ messages in thread
From: Catalin Marinas @ 2020-03-24 10:37 UTC (permalink / raw)
To: Rémi Denis-Courmont
Cc: Mark Rutland, james.morse, will, linux-kernel, linux-arm-kernel
On Mon, Mar 23, 2020 at 10:42:30PM +0200, Rémi Denis-Courmont wrote:
> Le maanantaina 23. maaliskuuta 2020, 21.04.09 EET Catalin Marinas a écrit :
> > Should we just use adrp on __entry_tramp_data_start? Anyway, the diff
> > below doesn't solve the issue I'm seeing (only reverting patch 3).
>
> AFAIU, the preexisting code uses the manual PAGE_SIZE offset because the offset
> in the main vmlinux does not match the architected offset inside the fixmap. If
> so, then using the symbol directly will not work at all.
You are right, it broke the defconfig as well.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] arm64: clean up trampoline vector loads
2020-03-23 20:42 ` Rémi Denis-Courmont
2020-03-24 10:37 ` Catalin Marinas
@ 2020-03-24 10:52 ` Mark Rutland
2020-03-24 11:23 ` Catalin Marinas
1 sibling, 1 reply; 16+ messages in thread
From: Mark Rutland @ 2020-03-24 10:52 UTC (permalink / raw)
To: Rémi Denis-Courmont
Cc: Catalin Marinas, will, james.morse, linux-arm-kernel,
linux-kernel
On Mon, Mar 23, 2020 at 10:42:30PM +0200, Rémi Denis-Courmont wrote:
> Le maanantaina 23. maaliskuuta 2020, 21.04.09 EET Catalin Marinas a écrit :
> > On Mon, Mar 23, 2020 at 12:14:37PM +0000, Mark Rutland wrote:
> > > On Mon, Mar 23, 2020 at 02:08:53PM +0200, Rémi Denis-Courmont wrote:
> > > > Le maanantaina 23. maaliskuuta 2020, 14.07.00 EET Mark Rutland a écrit :
> > > > > On Thu, Mar 19, 2020 at 11:14:05AM +0200, Rémi Denis-Courmont wrote:
> > > > > > From: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
> > > > > >
> > > > > > This switches from custom instruction patterns to the regular large
> > > > > > memory model sequence with ADRP and LDR. In doing so, the ADD
> > > > > > instruction can be eliminated in the SDEI handler, and the code no
> > > > > > longer assumes that the trampoline vectors and the vectors address
> > > > > > both
> > > > > > start on a page boundary.
> > > > > >
> > > > > > Signed-off-by: Rémi Denis-Courmont <remi.denis.courmont@huawei.com>
> > > > > > ---
> > > > > >
> > > > > > arch/arm64/kernel/entry.S | 9 ++++-----
> > > > > > 1 file changed, 4 insertions(+), 5 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > > > > > index e5d4e30ee242..24f828739696 100644
> > > > > > --- a/arch/arm64/kernel/entry.S
> > > > > > +++ b/arch/arm64/kernel/entry.S
> > > > > > @@ -805,9 +805,9 @@ alternative_else_nop_endif
> > > > > >
> > > > > > 2:
> > > > > > tramp_map_kernel x30
> > > > > >
> > > > > > #ifdef CONFIG_RANDOMIZE_BASE
> > > > > >
> > > > > > - adr x30, tramp_vectors + PAGE_SIZE
> > > > > > + adrp x30, tramp_vectors + PAGE_SIZE
> > > > > >
> > > > > > alternative_insn isb, nop, ARM64_WORKAROUND_QCOM_FALKOR_E1003
> > > > > >
> > > > > > - ldr x30, [x30]
> > > > > > + ldr x30, [x30, #:lo12:__entry_tramp_data_start]
> > > > >
> > > > > I think this is busted for !4K kernels once we reduce the alignment of
> > > > > __entry_tramp_data_start.
> > > > >
> > > > > The ADRP gives us a 64K aligned address (with bits 15:0 clear). The
> > > > > lo12
> > > > > relocation gives us bits 11:0, so we haven't accounted for bits 15:12.
> > > >
> > > > IMU, ADRP gives a 4K aligned value, regardless of MMU (TCR) settings.
> > >
> > > Sorry, I had erroneously assumed tramp_vectors was page aligned. The
> > > issue still stands -- we haven't accounted for bits 15:12, as those can
> > > differ between tramp_vectors and __entry_tramp_data_start.
>
> Does that mean that the SDEI code never worked with page size > 4 KiB?
I think this happens to work, but is fragile. Because nothing happens to
get placed in .rodata between the _entry_tramp_data_start data and the
__sdei_asm_trampoline_next_handler data, the
__sdei_asm_trampoline_next_handler data doesn't spill into a separate
page from the _entry_tramp_data_start data.
If we did start adding stuff into .rodata between those two, there'd be
a bigger risk of things going wrong. That was why I suggested a
.entry.tramp.data section previously.
> > Should we just use adrp on __entry_tramp_data_start? Anyway, the diff
> > below doesn't solve the issue I'm seeing (only reverting patch 3).
>
> AFAIU, the preexisting code uses the manual PAGE_SIZE offset because the offset
> in the main vmlinux does not match the architected offset inside the fixmap. If
> so, then using the symbol directly will not work at all.
Indeed. I can't see a neat way of avoiding this right now, so should we
drop these patches and leave the code as-is (but with comments as to the
special requirements that it has)?
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 1/3] arm64: clean up trampoline vector loads
2020-03-24 10:52 ` Mark Rutland
@ 2020-03-24 11:23 ` Catalin Marinas
0 siblings, 0 replies; 16+ messages in thread
From: Catalin Marinas @ 2020-03-24 11:23 UTC (permalink / raw)
To: Mark Rutland
Cc: james.morse, will, linux-arm-kernel, Rémi Denis-Courmont,
linux-kernel
On Tue, Mar 24, 2020 at 10:52:17AM +0000, Mark Rutland wrote:
> On Mon, Mar 23, 2020 at 10:42:30PM +0200, Rémi Denis-Courmont wrote:
> > Le maanantaina 23. maaliskuuta 2020, 21.04.09 EET Catalin Marinas a écrit :
> > > Should we just use adrp on __entry_tramp_data_start? Anyway, the diff
> > > below doesn't solve the issue I'm seeing (only reverting patch 3).
> >
> > AFAIU, the preexisting code uses the manual PAGE_SIZE offset because the offset
> > in the main vmlinux does not match the architected offset inside the fixmap. If
> > so, then using the symbol directly will not work at all.
>
> Indeed. I can't see a neat way of avoiding this right now, so should we
> drop these patches and leave the code as-is (but with comments as to the
> special requirements that it has)?
I'm going to drop these three patches from -next for now but I can take
any updated comments (they are pretty much missing from this code).
Thanks.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-03-24 11:23 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-03-19 9:12 [PATCHv3 0/3] clean up KPTI / SDEI trampoline data alignment Rémi Denis-Courmont
2020-03-19 9:14 ` [PATCH 1/3] arm64: clean up trampoline vector loads Rémi Denis-Courmont
2020-03-23 12:07 ` Mark Rutland
2020-03-23 12:08 ` Rémi Denis-Courmont
2020-03-23 12:14 ` Mark Rutland
2020-03-23 19:04 ` Catalin Marinas
2020-03-23 20:42 ` Rémi Denis-Courmont
2020-03-24 10:37 ` Catalin Marinas
2020-03-24 10:52 ` Mark Rutland
2020-03-24 11:23 ` Catalin Marinas
2020-03-19 9:14 ` [PATCH 2/3] arm64/sdei: gather trampolines' .rodata Rémi Denis-Courmont
2020-03-19 9:14 ` [PATCH 3/3] arm64: reduce trampoline data alignment Rémi Denis-Courmont
2020-03-21 13:40 ` Catalin Marinas
2020-03-23 11:58 ` Mark Rutland
2020-03-19 18:37 ` [PATCHv3 0/3] clean up KPTI / SDEI " Will Deacon
2020-03-20 16:54 ` Catalin Marinas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).