* [PATCH V5 00/21] riscv: compat: Add COMPAT mode support for rv64
From: guoren @ 2022-02-01 15:05 UTC (permalink / raw)
To: guoren, palmer, arnd, anup, gregkh, liush, wefu, drew,
wangjunqiang, hch
Cc: linux-arch, linux-s390, Guo Ren, linux-parisc, x86, linux-kernel,
linux-csky, linux-mips, sparclinux, linux-riscv, linuxppc-dev,
linux-arm-kernel
From: Guo Ren <guoren@linux.alibaba.com>
Currently, most 64-bit architectures (x86, parisc, powerpc, arm64,
s390, mips, sparc) have supported COMPAT mode. But they all have
history issues and can't use standard linux unistd.h. RISC-V would
be first standard __SYSCALL_COMPAT user of include/uapi/asm-generic
/unistd.h.
The patchset are based on v5.17-rc2, you can compare rv64-compat32
v.s. rv32-whole in qemu with following step:
- Prepare rv32 rootfs & fw_jump.bin by buildroot.org
$ git clone git://git.busybox.net/buildroot
$ cd buildroot
$ make qemu_riscv32_virt_defconfig O=qemu_riscv32_virt_defconfig
$ make -C qemu_riscv32_virt_defconfig
$ make qemu_riscv64_virt_defconfig O=qemu_riscv64_virt_defconfig
$ make -C qemu_riscv64_virt_defconfig
(Got fw_jump.bin & rootfs.ext2 in qemu_riscvXX_virt_defconfig/images)
- Prepare Linux rv32 & rv64 Image
$ git clone git@github.com:c-sky/csky-linux.git -b riscv_compat_v5 linux
$ cd linux
$ echo "CONFIG_STRICT_KERNEL_RWX=n" >> arch/riscv/configs/defconfig
$ echo "CONFIG_STRICT_MODULE_RWX=n" >> arch/riscv/configs/defconfig
$ make ARCH=riscv CROSS_COMPILE=riscv32-buildroot-linux-gnu- O=../build-rv32/ rv32_defconfig
$ make ARCH=riscv CROSS_COMPILE=riscv32-buildroot-linux-gnu- O=../build-rv32/ Image
$ make ARCH=riscv CROSS_COMPILE=riscv64-buildroot-linux-gnu- O=../build-rv64/ defconfig
$ make ARCH=riscv CROSS_COMPILE=riscv64-buildroot-linux-gnu- O=../build-rv64/ Image
- Prepare Qemu: (made by LIU Zhiwei <zhiwei_liu@c-sky.com>)
$ git clone git@github.com:alistair23/qemu.git -b riscv-to-apply.for-upstream linux
$ cd qemu
$ ./configure --target-list="riscv64-softmmu riscv32-softmmu"
$ make
Now let's compare rv32-compat with rv32-native memory footprint. Kernel with rv32 = rv64
defconfig, rootfs, opensbi, Qemu are the same.
- Run rv64 with rv32 rootfs in compat mode:
$ ./build/qemu-system-riscv64 -cpu rv64,x-h=true -M virt -m 64m -nographic -bios qemu_riscv64_virt_defconfig/images/fw_jump.bin -kernel build-rv64/Image -drive file qemu_riscv32_virt_defconfig/images/rootfs.ext2,format=raw,id=hd0 -device virtio-blk-device,drive=hd0 -append "rootwait root=/dev/vda ro console=ttyS0 earlycon=sbi" -netdev user,id=net0 -device virtio-net-device,netdev=net0
QEMU emulator version 6.2.50 (v6.2.0-29-g196d7182c8)
OpenSBI v0.9
[ 0.000000] Linux version 5.16.0-rc6-00017-g750f87086bdd-dirty (guoren@guoren-Z87-HD3) (riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.37) #96 SMP Tue Dec 28 21:01:55 CST 2021
[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
[ 0.000000] Machine model: riscv-virtio,qemu
[ 0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
[ 0.000000] printk: bootconsole [sbi0] enabled
[ 0.000000] efi: UEFI not found.
[ 0.000000] Zone ranges:
[ 0.000000] DMA32 [mem 0x0000000080200000-0x0000000083ffffff]
[ 0.000000] Normal empty
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000080200000-0x0000000083ffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x0000000083ffffff]
[ 0.000000] SBI specification v0.2 detected
[ 0.000000] SBI implementation ID=0x1 Version=0x9
[ 0.000000] SBI TIME extension detected
[ 0.000000] SBI IPI extension detected
[ 0.000000] SBI RFENCE extension detected
[ 0.000000] SBI v0.2 HSM extension detected
[ 0.000000] riscv: ISA extensions acdfhimsu
[ 0.000000] riscv: ELF capabilities acdfim
[ 0.000000] percpu: Embedded 17 pages/cpu s30696 r8192 d30744 u69632
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 15655
[ 0.000000] Kernel command line: rootwait root=/dev/vda ro console=ttyS0 earlycon=sbi
[ 0.000000] Dentry cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] fixmap : 0xffffffcefee00000 - 0xffffffceff000000 (2048 kB)
[ 0.000000] pci io : 0xffffffceff000000 - 0xffffffcf00000000 ( 16 MB)
[ 0.000000] vmemmap : 0xffffffcf00000000 - 0xffffffcfffffffff (4095 MB)
[ 0.000000] vmalloc : 0xffffffd000000000 - 0xffffffdfffffffff (65535 MB)
[ 0.000000] lowmem : 0xffffffe000000000 - 0xffffffe003e00000 ( 62 MB)
[ 0.000000] kernel : 0xffffffff80000000 - 0xffffffffffffffff (2047 MB)
[ 0.000000] Memory: 52788K/63488K available (6184K kernel code, 888K rwdata, 1917K rodata, 294K init, 297K bss, 10700K reserved, 0K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
[ 0.000000] rcu: RCU debug extended QS entry/exit.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[ 0.000000] riscv-intc: 64 local interrupts mapped
[ 0.000000] plic: plic@c000000: mapped 53 interrupts with 1 handlers for 2 contexts.
...
Welcome to Buildroot
buildroot login: root
# cat /proc/cpuinfo
processor : 0
hart : 0
isa : rv64imafdcsuh
mmu : sv48
# file /bin/busybox
/bin/busybox: setuid ELF 32-bit LSB shared object, UCB RISC-V, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-riscv32-ilp32d.so.1, for GNU/Linux 5.15.0, stripped
# ca[ 78.386630] random: fast init done
# cat /proc/meminfo
MemTotal: 53076 kB
MemFree: 40264 kB
MemAvailable: 40244 kB
Buffers: 236 kB
Cached: 1560 kB
SwapCached: 0 kB
Active: 1700 kB
Inactive: 516 kB
Active(anon): 40 kB
Inactive(anon): 424 kB
Active(file): 1660 kB
Inactive(file): 92 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 444 kB
Mapped: 1188 kB
Shmem: 44 kB
KReclaimable: 952 kB
Slab: 5744 kB
SReclaimable: 952 kB
SUnreclaim: 4792 kB
KernelStack: 624 kB
PageTables: 156 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 26536 kB
Committed_AS: 1748 kB
VmallocTotal: 67108863 kB
VmallocUsed: 652 kB
VmallocChunk: 0 kB
Percpu: 80 kB
#
- Run rv32 with rv32 rootfs:
$ ./build/qemu-system-riscv32 -cpu rv32,x-h=true -M virt -m 64m -nographic -bios qemu_riscv32_virt_defconfig/images/fw_jump.bin -kernel build-rv32/Image -drive file qemu_riscv32_virt_defconfig/images/rootfs.ext2,format=raw,id=hd0 -device virtio-blk-device,drive=hd0 -append "rootwait root=/dev/vda ro console=ttyS0 earlycon=sbi" -netdev user,id=net0 -device virtio-net-device,netdev=net0
QEMU emulator version 6.2.50 (v6.2.0-29-g196d7182c8)
OpenSBI v0.9
[ 0.000000] Linux version 5.16.0-rc6-00017-g750f87086bdd-dirty (guoren@guoren-Z87-HD3) (riscv32-buildroot-linux-gnu-gcc.br_real (Buildroot 2021.11-201-g7600ca7960-dirty) 10.3.0, GNU ld (GNU Binutils) 2.36.1) #7 SMP Tue Dec 28 21:02:21 CST 2021
[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80400000
[ 0.000000] Machine model: riscv-virtio,qemu
[ 0.000000] earlycon: sbi0 at I/O port 0x0 (options '')
[ 0.000000] printk: bootconsole [sbi0] enabled
[ 0.000000] efi: UEFI not found.
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000080400000-0x0000000083ffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000080400000-0x0000000083ffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000080400000-0x0000000083ffffff]
[ 0.000000] SBI specification v0.2 detected
[ 0.000000] SBI implementation ID=0x1 Version=0x9
[ 0.000000] SBI TIME extension detected
[ 0.000000] SBI IPI extension detected
[ 0.000000] SBI RFENCE extension detected
[ 0.000000] SBI v0.2 HSM extension detected
[ 0.000000] riscv: ISA extensions acdfhimsu
[ 0.000000] riscv: ELF capabilities acdfim
[ 0.000000] percpu: Embedded 12 pages/cpu s16600 r8192 d24360 u49152
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 15240
[ 0.000000] Kernel command line: rootwait root=/dev/vda ro console=ttyS0 earlycon=sbi
[ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] fixmap : 0x9dc00000 - 0x9e000000 (4096 kB)
[ 0.000000] pci io : 0x9e000000 - 0x9f000000 ( 16 MB)
[ 0.000000] vmemmap : 0x9f000000 - 0x9fffffff ( 15 MB)
[ 0.000000] vmalloc : 0xa0000000 - 0xbfffffff ( 511 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xc3c00000 ( 60 MB)
[ 0.000000] Memory: 51924K/61440K available (6117K kernel code, 695K rwdata, 1594K rodata, 255K init, 241K bss, 9516K reserved, 0K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
[ 0.000000] rcu: RCU debug extended QS entry/exit.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[ 0.000000] riscv-intc: 32 local interrupts mapped
[ 0.000000] plic: plic@c000000: mapped 53 interrupts with 1 handlers for 2 contexts.
...
Welcome to Buildroot
buildroot login: root
# cat /proc/cpuinfo
processor : 0
hart : 0
isa : rv32imafdcsuh
mmu : sv32
# file /bin/busybox
/bin/busybox: setuid ELF 32-bit LSB shared object, UCB RISC-V, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-riscv32-ilp32d.so.1, for GNU/Linux 5.15.0, stripped
[ 79.320589] random: fast init done
# cat /proc/meminfo
MemTotal: 52176 kB
MemFree: 41012 kB
MemAvailable: 42176 kB
Buffers: 644 kB
Cached: 2724 kB
SwapCached: 0 kB
Active: 3128 kB
Inactive: 752 kB
Active(anon): 40 kB
Inactive(anon): 516 kB
Active(file): 3088 kB
Inactive(file): 236 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 4 kB
Writeback: 0 kB
AnonPages: 556 kB
Mapped: 2172 kB
Shmem: 44 kB
KReclaimable: 656 kB
Slab: 3684 kB
SReclaimable: 656 kB
SUnreclaim: 3028 kB
KernelStack: 312 kB
PageTables: 88 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 26088 kB
Committed_AS: 2088 kB
VmallocTotal: 524287 kB
VmallocUsed: 12 kB
VmallocChunk: 0 kB
Percpu: 60 kB
#
Some conclusions:
- kernel statics:
64: Memory: 52788K/63488K available (6184K kernel code, 888K rwdata, 1917K rodata, 294K init, 297K bss, 10700K reserved)
32: Memory: 51924K/61440K available (6117K kernel code, 695K rwdata, 1594K rodata, 255K init, 241K bss, 9516K reserved)
rv32 better than rv64: 1% 22% 17% 13% 19% 11%
The code size is very similar, but data size rv32 would be better.
- rv32 kernel runtime KernelStack, Slab... are smaller,
rv64: MemTotal: 53076 kB, MemFree: 40264 kB
rv32: MemTotal: 52176 + 2048 kB, MemFree: 41012 + 2048 kB
rv32 better than rv64: 2% 6%
(Because opensbi problem, we could add another 2MB for rv32.)
Overall in 64MB memory situation, rv64-compat is 6% worse than rv32-full
at memory footprint. If the user space memory usage increases, I think
the gap will be further reduced.
Changes in v5:
- Rebase on linux-5.17-rc2
- Include consolidate the fcntl patches by Christoph Hellwig
- Remove F_GETLK64/F_SETLK64/F_SETLKW64 from asm/compat.h
- Change COMPAT_RLIM_INFINITY from 0x7fffffff to 0xffffffff
- Bring back "Add hw-cap detect in setup_arch patch" in v1
Changes in v4:
- Rebase on linux-5.17-rc1
- Optimize compat_sys_call_table implementation with Arnd's advice
- Add reviewed-by for Arnd. Thx :)
- Remove FIXME comment in elf.h
- Optimize Cleanup duplicate definitions in compat.h with Arnd's advice
Changes in v3:
- Rebase on newest master (pre linux-5.17-rc1)
- Using newest qemu version v7 for test
- Remove fcntl common modification
- Fixup SET_PERSONALITY in elf.h by Arnd
- Fixup KVM Kconfig
- Update Acked-by & Reviewed-by
Changes in v2:
- Add __ARCH_WANT_COMPAT_STAT suggested
- Cleanup fcntl compatduplicate definitions
- Cleanup compat.h
- Move rv32_defconfig into Makefile
- Fixup rv64 rootfs boot failed, remove hw_compat_mode_detect
- Move SYSVIPC_COMPAT into init/Kconfig
- Simplify compat_elf_check
Christoph Hellwig (3):
uapi: simplify __ARCH_FLOCK{,64}_PAD a little
uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h
compat: consolidate the compat_flock{,64} definition
Guo Ren (18):
kconfig: Add SYSVIPC_COMPAT for all architectures
fs: stat: compat: Add __ARCH_WANT_COMPAT_STAT
asm-generic: compat: Cleanup duplicate definitions
syscalls: compat: Fix the missing part for __SYSCALL_COMPAT
riscv: Fixup difference with defconfig
riscv: compat: Add basic compat data type implementation
riscv: compat: Re-implement TASK_SIZE for COMPAT_32BIT
riscv: compat: syscall: Add compat_sys_call_table implementation
riscv: compat: syscall: Add entry.S implementation
riscv: compat: process: Add UXL_32 support in start_thread
riscv: compat: Add elf.h implementation
riscv: compat: Add hw capability check for elf
riscv: compat: vdso: Add rv32 VDSO base code implementation
riscv: compat: vdso: Add setup additional pages implementation
riscv: compat: signal: Add rt_frame implementation
riscv: compat: ptrace: Add compat_arch_ptrace implement
riscv: compat: Add COMPAT Kbuild skeletal support
KVM: compat: riscv: Prevent KVM_COMPAT from being selected
arch/arm64/Kconfig | 4 -
arch/arm64/include/asm/compat.h | 91 +------
arch/arm64/include/asm/unistd.h | 1 +
arch/mips/Kconfig | 5 -
arch/mips/include/asm/compat.h | 41 +--
arch/mips/include/asm/unistd.h | 2 +
arch/mips/include/uapi/asm/fcntl.h | 30 +--
arch/parisc/Kconfig | 4 -
arch/parisc/include/asm/compat.h | 45 +---
arch/parisc/include/asm/unistd.h | 1 +
arch/powerpc/Kconfig | 5 -
arch/powerpc/include/asm/compat.h | 50 +---
arch/powerpc/include/asm/unistd.h | 1 +
arch/riscv/Kconfig | 19 ++
arch/riscv/Makefile | 9 +
arch/riscv/configs/rv32_defconfig | 135 ----------
arch/riscv/include/asm/compat.h | 129 ++++++++++
arch/riscv/include/asm/csr.h | 7 +
arch/riscv/include/asm/elf.h | 52 +++-
arch/riscv/include/asm/mmu.h | 1 +
arch/riscv/include/asm/pgtable.h | 13 +-
arch/riscv/include/asm/syscall.h | 1 +
arch/riscv/include/asm/thread_info.h | 1 +
arch/riscv/include/asm/unistd.h | 11 +
arch/riscv/include/asm/vdso.h | 9 +
arch/riscv/include/uapi/asm/unistd.h | 2 +-
arch/riscv/kernel/Makefile | 3 +
arch/riscv/kernel/compat_signal.c | 243 ++++++++++++++++++
arch/riscv/kernel/compat_syscall_table.c | 19 ++
arch/riscv/kernel/compat_vdso/.gitignore | 2 +
arch/riscv/kernel/compat_vdso/Makefile | 68 +++++
arch/riscv/kernel/compat_vdso/compat_vdso.S | 8 +
.../kernel/compat_vdso/compat_vdso.lds.S | 3 +
arch/riscv/kernel/compat_vdso/flush_icache.S | 3 +
.../compat_vdso/gen_compat_vdso_offsets.sh | 5 +
arch/riscv/kernel/compat_vdso/getcpu.S | 3 +
arch/riscv/kernel/compat_vdso/note.S | 3 +
arch/riscv/kernel/compat_vdso/rt_sigreturn.S | 3 +
arch/riscv/kernel/entry.S | 18 +-
arch/riscv/kernel/process.c | 36 +++
arch/riscv/kernel/ptrace.c | 87 ++++++-
arch/riscv/kernel/signal.c | 13 +-
arch/riscv/kernel/sys_riscv.c | 6 +-
arch/riscv/kernel/vdso.c | 104 +++++---
arch/riscv/kernel/vdso/vdso.S | 6 +-
arch/s390/Kconfig | 3 -
arch/s390/include/asm/compat.h | 99 +------
arch/s390/include/asm/unistd.h | 1 +
arch/sparc/Kconfig | 5 -
arch/sparc/include/asm/compat.h | 61 ++---
arch/sparc/include/asm/unistd.h | 1 +
arch/x86/Kconfig | 4 -
arch/x86/include/asm/compat.h | 104 ++------
arch/x86/include/asm/unistd.h | 1 +
fs/open.c | 24 ++
fs/read_write.c | 16 ++
fs/stat.c | 2 +-
fs/sync.c | 9 +
include/asm-generic/compat.h | 113 ++++++++
include/linux/compat.h | 68 +++++
include/uapi/asm-generic/fcntl.h | 23 +-
include/uapi/asm-generic/unistd.h | 4 +-
init/Kconfig | 4 +
mm/fadvise.c | 11 +
mm/readahead.c | 7 +
tools/include/uapi/asm-generic/fcntl.h | 21 +-
tools/include/uapi/asm-generic/unistd.h | 4 +-
virt/kvm/Kconfig | 2 +-
68 files changed, 1198 insertions(+), 691 deletions(-)
delete mode 100644 arch/riscv/configs/rv32_defconfig
create mode 100644 arch/riscv/include/asm/compat.h
create mode 100644 arch/riscv/kernel/compat_signal.c
create mode 100644 arch/riscv/kernel/compat_syscall_table.c
create mode 100644 arch/riscv/kernel/compat_vdso/.gitignore
create mode 100644 arch/riscv/kernel/compat_vdso/Makefile
create mode 100644 arch/riscv/kernel/compat_vdso/compat_vdso.S
create mode 100644 arch/riscv/kernel/compat_vdso/compat_vdso.lds.S
create mode 100644 arch/riscv/kernel/compat_vdso/flush_icache.S
create mode 100755 arch/riscv/kernel/compat_vdso/gen_compat_vdso_offsets.sh
create mode 100644 arch/riscv/kernel/compat_vdso/getcpu.S
create mode 100644 arch/riscv/kernel/compat_vdso/note.S
create mode 100644 arch/riscv/kernel/compat_vdso/rt_sigreturn.S
--
2.25.1
^ permalink raw reply
* Re: [PATCH v7 0/5] Allow guest access to EFI confidential computing secret area
From: James Bottomley @ 2022-02-01 15:05 UTC (permalink / raw)
To: Greg KH
Cc: linux-efi, Brijesh Singh, mjg59, Lenny Szubowicz, Gerd Hoffmann,
gcwilson, Ard Biesheuvel, Daniele Buono, Andi Kleen, Nayna Jain,
James Morris, Dov Murik, Jim Cadden, Peter Gonda, Borislav Petkov,
Serge E. Hallyn, Tom Lendacky, Ashish Kalra, dougmill,
Dr. David Alan Gilbert, Tobin Feldman-Fitzthum, linux-coco,
gjoyce, dja, Dave Hansen, linux-kernel, linux-security-module,
linuxppc-dev, Andrew Scull
In-Reply-To: <YflGkNwyI6LUSVVk@kroah.com>
On Tue, 2022-02-01 at 15:41 +0100, Greg KH wrote:
> On Tue, Feb 01, 2022 at 09:24:50AM -0500, James Bottomley wrote:
> > [cc's added]
> > On Tue, 2022-02-01 at 14:50 +0100, Greg KH wrote:
[...]
> > > You all need to work together to come up with a unified place for
> > > this and stop making it platform-specific.
> >
> > I'm not entirely sure of that. If you look at the differences
> > between EFI variables and the COCO proposal: the former has an
> > update API which, in the case of signed variables, is rather
> > complex and a UC16 content requirement. The latter is binary data
> > with read only/delete. Plus each variable in EFI is described by a
> > GUID, so having a directory of random guids, some of which behave
> > like COCO secrets and some of which are EFI variables is going to
> > be incredibly confusing (and also break all our current listing
> > tools which seems somewhat undesirable).
> >
> > So we could end up with
> >
> > <common path prefix>/efivar
> > <common path prefix>/coco
>
> The powerpc stuff is not efi. But yes, that is messy here. But why
> doesn't the powerpc follow the coco standard?
There is no coco standard for EFI variables. There's only a UEFI
variable standard which, I believe, power tries to follow in some
measure since the variables are mostly used for its version of secure
boot. Certainly you're either a power or UEFI platform but not both,
so they could live at the same location ... that's not true with the
coco ones. I added the cc's to see if there are other ideas, but I
really think the use cases are too disjoint.
As Daniel has previously proposed, it might be possible to unify the
power and UEFI implementations ... useful if we want them to respond to
the same tooling, but we'll do that by giving them the same EFI
semantics. The semantics and source of the coco secrets will still be
immutable and completely alien to whatever backend does the non
volatile power/efi authenticated variables, so we'll still need two
different backends and then it's just a question of arguing about path,
which doesn't make sense as a blocker.
> > To achieve the separation, but I really don't see what this buys
> > us. Both filesystems would likely end up with different backends
> > because of the semantic differences and we can easily start now in
> > different places (effectively we've already done this for efi
> > variables) and unify later if that is the chosen direction, so it
> > doesn't look like a blocker.
> >
> > > Until then, we can't take this.
> >
> > I don't believe anyone was asking you to take it.
>
> I was on the review list...
You raised a doc/API concenrn. I think you were on the review list to
ensure it got addressed.
James
^ permalink raw reply
* Re: [PATCH v7 0/5] Allow guest access to EFI confidential computing secret area
From: Greg KH @ 2022-02-01 14:41 UTC (permalink / raw)
To: James Bottomley
Cc: linux-efi, Brijesh Singh, mjg59, Lenny Szubowicz, Gerd Hoffmann,
gcwilson, Ard Biesheuvel, Daniele Buono, Andi Kleen, Nayna Jain,
James Morris, Dov Murik, Jim Cadden, Peter Gonda, Borislav Petkov,
Serge E. Hallyn, Tom Lendacky, Ashish Kalra, dougmill,
Dr. David Alan Gilbert, Tobin Feldman-Fitzthum, linux-coco,
gjoyce, dja, Dave Hansen, linux-kernel, linux-security-module,
linuxppc-dev, Andrew Scull
In-Reply-To: <37779659ca96ac9c1f11bcc0ac0665895c795b54.camel@linux.ibm.com>
On Tue, Feb 01, 2022 at 09:24:50AM -0500, James Bottomley wrote:
> [cc's added]
> On Tue, 2022-02-01 at 14:50 +0100, Greg KH wrote:
> > On Tue, Feb 01, 2022 at 12:44:08PM +0000, Dov Murik wrote:
> [...]
> > > # ls -la /sys/kernel/security/coco/efi_secret
> > > total 0
> > > drwxr-xr-x 2 root root 0 Jun 28 11:55 .
> > > drwxr-xr-x 3 root root 0 Jun 28 11:54 ..
> > > -r--r----- 1 root root 0 Jun 28 11:54 736870e5-84f0-4973-92ec-
> > > 06879ce3da0b
> > > -r--r----- 1 root root 0 Jun 28 11:54 83c83f7f-1356-4975-8b7e-
> > > d3a0b54312c6
> > > -r--r----- 1 root root 0 Jun 28 11:54 9553f55d-3da2-43ee-ab5d-
> > > ff17f78864d2
> >
> > Please see my comments on the powerpc version of this type of thing:
> >
> > https://lore.kernel.org/r/20220122005637.28199-1-nayna@linux.ibm.com
>
> If you want a debate, actually cc'ing the people on the other thread
> would have been a good start ...
>
> For those added, this patch series is at:
>
> https://lore.kernel.org/all/20220201124413.1093099-1-dovmurik@linux.ibm.com/
Thanks for adding everyone.
> > You all need to work together to come up with a unified place for
> > this and stop making it platform-specific.
>
> I'm not entirely sure of that. If you look at the differences between
> EFI variables and the COCO proposal: the former has an update API
> which, in the case of signed variables, is rather complex and a UC16
> content requirement. The latter is binary data with read only/delete.
> Plus each variable in EFI is described by a GUID, so having a directory
> of random guids, some of which behave like COCO secrets and some of
> which are EFI variables is going to be incredibly confusing (and also
> break all our current listing tools which seems somewhat undesirable).
>
> So we could end up with
>
> <common path prefix>/efivar
> <common path prefix>/coco
The powerpc stuff is not efi. But yes, that is messy here. But why
doesn't the powerpc follow the coco standard?
> To achieve the separation, but I really don't see what this buys us.
> Both filesystems would likely end up with different backends because of
> the semantic differences and we can easily start now in different
> places (effectively we've already done this for efi variables) and
> unify later if that is the chosen direction, so it doesn't look like a
> blocker.
>
> > Until then, we can't take this.
>
> I don't believe anyone was asking you to take it.
I was on the review list...
^ permalink raw reply
* Re: [PATCH v7 0/5] Allow guest access to EFI confidential computing secret area
From: James Bottomley @ 2022-02-01 14:24 UTC (permalink / raw)
To: Greg KH, Dov Murik
Cc: linux-efi, Brijesh Singh, mjg59, Lenny Szubowicz, Gerd Hoffmann,
gcwilson, Ard Biesheuvel, Daniele Buono, Andi Kleen, Nayna Jain,
James Morris, Jim Cadden, Peter Gonda, Borislav Petkov,
Serge E. Hallyn, Tom Lendacky, Ashish Kalra, dougmill,
Dr. David Alan Gilbert, Tobin Feldman-Fitzthum, linux-coco,
gjoyce, dja, Dave Hansen, gregkh, linux-kernel,
linux-security-module, linuxppc-dev, Andrew Scull
In-Reply-To: <Yfk6vEuZFtgtA+G+@kroah.com>
[cc's added]
On Tue, 2022-02-01 at 14:50 +0100, Greg KH wrote:
> On Tue, Feb 01, 2022 at 12:44:08PM +0000, Dov Murik wrote:
[...]
> > # ls -la /sys/kernel/security/coco/efi_secret
> > total 0
> > drwxr-xr-x 2 root root 0 Jun 28 11:55 .
> > drwxr-xr-x 3 root root 0 Jun 28 11:54 ..
> > -r--r----- 1 root root 0 Jun 28 11:54 736870e5-84f0-4973-92ec-
> > 06879ce3da0b
> > -r--r----- 1 root root 0 Jun 28 11:54 83c83f7f-1356-4975-8b7e-
> > d3a0b54312c6
> > -r--r----- 1 root root 0 Jun 28 11:54 9553f55d-3da2-43ee-ab5d-
> > ff17f78864d2
>
> Please see my comments on the powerpc version of this type of thing:
>
> https://lore.kernel.org/r/20220122005637.28199-1-nayna@linux.ibm.com
If you want a debate, actually cc'ing the people on the other thread
would have been a good start ...
For those added, this patch series is at:
https://lore.kernel.org/all/20220201124413.1093099-1-dovmurik@linux.ibm.com/
> You all need to work together to come up with a unified place for
> this and stop making it platform-specific.
I'm not entirely sure of that. If you look at the differences between
EFI variables and the COCO proposal: the former has an update API
which, in the case of signed variables, is rather complex and a UC16
content requirement. The latter is binary data with read only/delete.
Plus each variable in EFI is described by a GUID, so having a directory
of random guids, some of which behave like COCO secrets and some of
which are EFI variables is going to be incredibly confusing (and also
break all our current listing tools which seems somewhat undesirable).
So we could end up with
<common path prefix>/efivar
<common path prefix>/coco
To achieve the separation, but I really don't see what this buys us.
Both filesystems would likely end up with different backends because of
the semantic differences and we can easily start now in different
places (effectively we've already done this for efi variables) and
unify later if that is the chosen direction, so it doesn't look like a
blocker.
> Until then, we can't take this.
I don't believe anyone was asking you to take it.
James
^ permalink raw reply
* Re: [PATCH V4 16/17] riscv: compat: Add COMPAT Kbuild skeletal support
From: Guo Ren @ 2022-02-01 13:56 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, linux-s390, Guo Ren, Parisc List, Greg Kroah-Hartman,
Drew Fustini, Anup Patel, Wang Junqiang, the arch/x86 maintainers,
Linux Kernel Mailing List, linux-csky,
open list:BROADCOM NVRAM DRIVER, Christoph Hellwig,
Palmer Dabbelt, liush, sparclinux, linux-riscv, linuxppc-dev,
Christoph Hellwig, Linux ARM, Wei Fu
In-Reply-To: <CAK8P3a3u8zo+MOOpDXaX8PY2ukN3J2VHnV8uDXQwc=0WgV6qFw@mail.gmail.com>
On Tue, Feb 1, 2022 at 7:48 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Feb 1, 2022 at 11:26 AM Guo Ren <guoren@kernel.org> wrote:
> >
> > Hi Arnd & Christoph,
> >
> > The UXL field controls the value of XLEN for U-mode, termed UXLEN,
> > which may differ from the
> > value of XLEN for S-mode, termed SXLEN. The encoding of UXL is the
> > same as that of the MXL
> > field of misa, shown in Table 3.1.
> >
> > Here is the patch. (We needn't exception helper, because we are in
> > S-mode and UXL wouldn't affect.)
>
> Looks good to me, just a few details that could be improved
>
> > -#define compat_elf_check_arch(x) ((x)->e_machine == EM_RISCV)
> > +#ifdef CONFIG_COMPAT
> > +#define compat_elf_check_arch compat_elf_check_arch
> > +extern bool compat_elf_check_arch(Elf32_Ehdr *hdr);
> > +#endif
>
> No need for the #ifdef
Okay
> > +}
>
> > +void compat_mode_detect(void)
>
> __init
Okay
>
> > +{
> > + unsigned long tmp = csr_read(CSR_STATUS);
> > + csr_write(CSR_STATUS, (tmp & ~SR_UXL) | SR_UXL_32);
> > +
> > + if ((csr_read(CSR_STATUS) & SR_UXL) != SR_UXL_32) {
> > + csr_write(CSR_STATUS, tmp);
> > + return;
> > + }
> > +
> > + csr_write(CSR_STATUS, tmp);
> > + compat_mode_support = true;
> > +
> > + pr_info("riscv: compat: 32bit U-mode applications support\n");
> > +}
>
> I think an entry in /proc/cpuinfo would be more helpful than the pr_info at
> boot time. Maybe a follow-up patch though, as there is no obvious place
> to put it. On other architectures, you typically have a set of space
> separated feature names, but riscv has a single string that describes
> the ISA, and this feature is technically the support for a second ISA.
Yes, it should be another patch after discussion.
>
> Arnd
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
^ permalink raw reply
* Re: [RFC PATCH 0/2] powerpc/pseries: add support for local secure storage called Platform Keystore(PKS)
From: Greg KH @ 2022-02-01 13:49 UTC (permalink / raw)
To: Daniel Axtens
Cc: mjg59, Nayna Jain, linux-kernel, Douglas Miller, George Wilson,
linuxppc-dev, gjoyce
In-Reply-To: <87sftec74i.fsf@dja-thinkpad.axtens.net>
On Mon, Jan 24, 2022 at 11:25:17AM +1100, Daniel Axtens wrote:
> Hi Greg,
>
> > Ok, this is like the 3rd or 4th different platform-specific proposal for
> > this type of functionality. I think we need to give up on
> > platform-specific user/kernel apis on this (random sysfs/securityfs
> > files scattered around the tree), and come up with a standard place for
> > all of this.
>
> I agree that we do have a number of platforms exposing superficially
> similar functionality. Indeed, back in 2019 I had a crack at a unified
> approach: [1] [2].
>
> Looking back at it now, I am not sure it ever would have worked because
> the semantics of the underlying firmware stores are quite
> different. Here are the ones I know about:
>
> - OpenPower/PowerNV Secure Variables:
>
> * Firmware semantics:
> - flat variable space
> - variables are fixed in firmware, can neither be created nor
> destroyed
> - variable names are ASCII
> - no concept of policy/attributes
>
> * Current kernel interface semantics:
> - names are case sensitive
> - directory per variable
>
>
> - (U)EFI variables:
>
> * Firmware semantics:
> - flat variable space
> - variables can be created/destroyed but the semantics are fiddly
> [3]
> - variable names are UTF-16 + UUID
> - variables have 32-bit attributes
>
> * efivarfs interface semantics:
> - file per variable
> - attributes are the first 4 bytes of the file
> - names are partially case-insensitive (UUID part) and partially
> case-sensitive ('name' part)
>
> * sysfs interface semantics (as used by CONFIG_GOOGLE_SMI)
> - directory per variable
> - attributes are a separate sysfs file
> - to create a variable you write a serialised structure to
> `/sys/firmware/efi/vars/new_var`, to delete a var you write
> to `.../del_var`
> - names are case-sensitive including the UUID
>
>
> - PowerVM Partition Key Store Variables:
>
> * Firmware semantics:
> - _not_ a flat space, there are 3 domains ("consumers"): firmware,
> bootloader and OS (not yet supported by the patch set)
> - variables can be created and destroyed but the semantics are
> fiddly and fiddly in different ways to UEFI [4]
> - variable names are arbitrary byte strings: the hypervisor permits
> names to contain nul and /.
> - variables have 32-bit attributes ("policy") that don't align with
> UEFI attributes
>
> * No stable kernel interface yet
>
> Even if we could come up with some stable kernel interface features
> (e.g. decide if we want file per variable vs directory per variable), I
> don't know how easy it would be to deal with the underlying semantic
> differences - I think userspace would still need substantial
> per-platform knowledge.
>
> Or have I misunderstood what you're asking for? (If you want them all to
> live under /sys/firmware, these ones all already do...)
I want them to be unified in some way, right now there are lots of
proposals for the same type of thing, but in different places (sysfs,
securityfs, somewhere else), and with different names.
Please work together.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] powerpc/xive: Add some error handling code to 'xive_spapr_init()'
From: Christophe Leroy @ 2022-02-01 13:39 UTC (permalink / raw)
To: Christophe JAILLET, benh@kernel.crashing.org, paulus@samba.org,
mpe@ellerman.id.au, allison@lohutok.net, tglx@linutronix.de,
clg@kaod.org, groug@kaod.org
Cc: linuxppc-dev@lists.ozlabs.org, kernel-janitors@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <7c34009b-0d34-baa8-f4ff-68f2203422c5@wanadoo.fr>
Le 01/02/2022 à 13:32, Christophe JAILLET a écrit :
> Le 01/02/2022 à 12:31, Christophe Leroy a écrit :
>> Hi,
>>
>> Le 01/08/2019 à 13:09, Christophe JAILLET a écrit :
>>> 'xive_irq_bitmap_add()' can return -ENOMEM.
>>> In this case, we should free the memory already allocated and return
>>> 'false' to the caller.
>>>
>>> Also add an error path which undoes the 'tima = ioremap(...)'
>>
>> This old patch doesn't apply, if it is still relevant can you please
>> rebase ?
>>
>> Thanks
>> Christophe
>>
>
> Hi, funny to see a 2 1/2 years old patch to pop-up like that :)
> It still looks relevant to me.
Yeah I'm trying to clean some dust in Patchwork.
>
> V2 sent.
> Still not compile tested.
>
At least it's all green at
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/564998101804886b151235c8a9f93020923bfd2c.1643718324.git.christophe.jaillet@wanadoo.fr/
Christophe
^ permalink raw reply
* Re: [PATCH v2] powerpc/xive: Add some error handling code to 'xive_spapr_init()'
From: Cédric Le Goater @ 2022-02-01 13:28 UTC (permalink / raw)
To: Christophe JAILLET, christophe.leroy, benh, paulus, mpe, allison,
tglx, groug
Cc: linuxppc-dev, kernel-janitors, linux-kernel
In-Reply-To: <564998101804886b151235c8a9f93020923bfd2c.1643718324.git.christophe.jaillet@wanadoo.fr>
On 2/1/22 13:31, Christophe JAILLET wrote:
> 'xive_irq_bitmap_add()' can return -ENOMEM.
> In this case, we should free the memory already allocated and return
> 'false' to the caller.
>
> Also add an error path which undoes the 'tima = ioremap(...)'
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
> ---
> NOT compile tested (I don't have a cross compiler and won't install one).
> So if some correction or improvement are needed, feel free to propose and
> commit it directly.
A cross compiler takes a couple of seconds to install on any distro.
It takes a little more to compile the pseries defconfig. To test with
QEMU, grab the disk image here :
https://github.com/legoater/qemu-ppc-boot/blob/main/buildroot/qemu_ppc64le_pseries-2021.11-7-g3058e75456-20211206
run :
qemu-system-ppc64 -M pseries -cpu POWER9 -kernel vmlinux -append "console=hvc0 rootwait root=/dev/sda" -drive file=rootfs.ext2,if=scsi,index=0,format=raw -nographic -net nic -net user -serial mon:stdio
and you will have a pseries machine with network and disk using the
XIVE interrupt controller.
To get more info on the genirq layer and the XIVE driver, simply
append :
dyndbg="file arch/powerpc/sysdev/xive/* +p; file kernel/irq/* +p"
Thanks,
C.
^ permalink raw reply
* Re: [PATCH] powerpc/xive: Add some error handling code to 'xive_spapr_init()'
From: Christophe JAILLET @ 2022-02-01 12:32 UTC (permalink / raw)
To: Christophe Leroy, benh, paulus, mpe, allison, tglx, clg, groug
Cc: linuxppc-dev, kernel-janitors, linux-kernel
In-Reply-To: <1ea13a2a-90fd-07d3-2031-19e81ea349b4@csgroup.eu>
Le 01/02/2022 à 12:31, Christophe Leroy a écrit :
> Hi,
>
> Le 01/08/2019 à 13:09, Christophe JAILLET a écrit :
>> 'xive_irq_bitmap_add()' can return -ENOMEM.
>> In this case, we should free the memory already allocated and return
>> 'false' to the caller.
>>
>> Also add an error path which undoes the 'tima = ioremap(...)'
>
> This old patch doesn't apply, if it is still relevant can you please
> rebase ?
>
> Thanks
> Christophe
>
Hi, funny to see a 2 1/2 years old patch to pop-up like that :)
It still looks relevant to me.
V2 sent.
Still not compile tested.
CJ
^ permalink raw reply
* [PATCH v2] powerpc/xive: Add some error handling code to 'xive_spapr_init()'
From: Christophe JAILLET @ 2022-02-01 12:31 UTC (permalink / raw)
To: christophe.leroy, benh, paulus, mpe, allison, tglx, clg, groug
Cc: Christophe JAILLET, linuxppc-dev, kernel-janitors, linux-kernel
'xive_irq_bitmap_add()' can return -ENOMEM.
In this case, we should free the memory already allocated and return
'false' to the caller.
Also add an error path which undoes the 'tima = ioremap(...)'
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
NOT compile tested (I don't have a cross compiler and won't install one).
So if some correction or improvement are needed, feel free to propose and
commit it directly.
v2: rebase with latest -next
---
arch/powerpc/sysdev/xive/spapr.c | 36 +++++++++++++++++++++++++-------
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/sysdev/xive/spapr.c b/arch/powerpc/sysdev/xive/spapr.c
index 928f95004501..29456c255f9f 100644
--- a/arch/powerpc/sysdev/xive/spapr.c
+++ b/arch/powerpc/sysdev/xive/spapr.c
@@ -67,6 +67,17 @@ static int __init xive_irq_bitmap_add(int base, int count)
return 0;
}
+static void xive_irq_bitmap_remove_all(void)
+{
+ struct xive_irq_bitmap *xibm, *tmp;
+
+ list_for_each_entry_safe(xibm, tmp, &xive_irq_bitmaps, list) {
+ list_del(&xibm->list);
+ kfree(xibm->bitmap);
+ kfree(xibm);
+ }
+}
+
static int __xive_irq_bitmap_alloc(struct xive_irq_bitmap *xibm)
{
int irq;
@@ -803,7 +814,7 @@ bool __init xive_spapr_init(void)
u32 val;
u32 len;
const __be32 *reg;
- int i;
+ int i, err;
if (xive_spapr_disabled())
return false;
@@ -828,23 +839,26 @@ bool __init xive_spapr_init(void)
}
if (!xive_get_max_prio(&max_prio))
- return false;
+ goto err_unmap;
/* Feed the IRQ number allocator with the ranges given in the DT */
reg = of_get_property(np, "ibm,xive-lisn-ranges", &len);
if (!reg) {
pr_err("Failed to read 'ibm,xive-lisn-ranges' property\n");
- return false;
+ goto err_unmap;
}
if (len % (2 * sizeof(u32)) != 0) {
pr_err("invalid 'ibm,xive-lisn-ranges' property\n");
- return false;
+ goto err_unmap;
}
- for (i = 0; i < len / (2 * sizeof(u32)); i++, reg += 2)
- xive_irq_bitmap_add(be32_to_cpu(reg[0]),
- be32_to_cpu(reg[1]));
+ for (i = 0; i < len / (2 * sizeof(u32)); i++, reg += 2) {
+ err = xive_irq_bitmap_add(be32_to_cpu(reg[0]),
+ be32_to_cpu(reg[1]));
+ if (err < 0)
+ goto err_mem_free;
+ }
/* Iterate the EQ sizes and pick one */
of_property_for_each_u32(np, "ibm,xive-eq-sizes", prop, reg, val) {
@@ -855,10 +869,16 @@ bool __init xive_spapr_init(void)
/* Initialize XIVE core with our backend */
if (!xive_core_init(np, &xive_spapr_ops, tima, TM_QW1_OS, max_prio))
- return false;
+ goto err_mem_free;
pr_info("Using %dkB queues\n", 1 << (xive_queue_shift - 10));
return true;
+
+err_mem_free:
+ xive_irq_bitmap_remove_all();
+err_unmap:
+ iounmap(tima);
+ return false;
}
machine_arch_initcall(pseries, xive_core_debug_init);
--
2.32.0
^ permalink raw reply related
* Re: [PATCH] powerpc/kasan: Fix early region not updated correctly
From: Christophe Leroy @ 2022-02-01 12:36 UTC (permalink / raw)
To: Chen Jingwen, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Christophe Leroy, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, kasan-dev
In-Reply-To: <20211229035226.59159-1-chenjingwen6@huawei.com>
Le 29/12/2021 à 04:52, Chen Jingwen a écrit :
> The shadow's page table is not updated when PTE_RPN_SHIFT is 24
> and PAGE_SHIFT is 12. It not only causes false positives but
> also false negative as shown the following text.
>
> Fix it by bringing the logic of kasan_early_shadow_page_entry here.
>
> 1. False Positive:
> ==================================================================
> BUG: KASAN: vmalloc-out-of-bounds in pcpu_alloc+0x508/0xa50
> Write of size 16 at addr f57f3be0 by task swapper/0/1
>
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-12267-gdebe436e77c7 #1
> Call Trace:
> [c80d1c20] [c07fe7b8] dump_stack_lvl+0x4c/0x6c (unreliable)
> [c80d1c40] [c02ff668] print_address_description.constprop.0+0x88/0x300
> [c80d1c70] [c02ff45c] kasan_report+0x1ec/0x200
> [c80d1cb0] [c0300b20] kasan_check_range+0x160/0x2f0
> [c80d1cc0] [c03018a4] memset+0x34/0x90
> [c80d1ce0] [c0280108] pcpu_alloc+0x508/0xa50
> [c80d1d40] [c02fd7bc] __kmem_cache_create+0xfc/0x570
> [c80d1d70] [c0283d64] kmem_cache_create_usercopy+0x274/0x3e0
> [c80d1db0] [c2036580] init_sd+0xc4/0x1d0
> [c80d1de0] [c00044a0] do_one_initcall+0xc0/0x33c
> [c80d1eb0] [c2001624] kernel_init_freeable+0x2c8/0x384
> [c80d1ef0] [c0004b14] kernel_init+0x24/0x170
> [c80d1f10] [c001b26c] ret_from_kernel_thread+0x5c/0x64
>
> Memory state around the buggy address:
> f57f3a80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> f57f3b00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>> f57f3b80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> ^
> f57f3c00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> f57f3c80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
> ==================================================================
>
> 2. False Negative (with KASAN tests):
> ==================================================================
> Before fix:
> ok 45 - kmalloc_double_kzfree
> # vmalloc_oob: EXPECTATION FAILED at lib/test_kasan.c:1039
> KASAN failure expected in "((volatile char *)area)[3100]", but none occurred
> not ok 46 - vmalloc_oob
> not ok 1 - kasan
>
> ==================================================================
> After fix:
> ok 1 - kasan
>
> Fixes: cbd18991e24fe ("powerpc/mm: Fix an Oops in kasan_mmu_init()")
> Cc: stable@vger.kernel.org # 5.4.x
> Signed-off-by: Chen Jingwen <chenjingwen6@huawei.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/mm/kasan/kasan_init_32.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/mm/kasan/kasan_init_32.c b/arch/powerpc/mm/kasan/kasan_init_32.c
> index cf8770b1a692e..f3e4d069e0ba7 100644
> --- a/arch/powerpc/mm/kasan/kasan_init_32.c
> +++ b/arch/powerpc/mm/kasan/kasan_init_32.c
> @@ -83,13 +83,12 @@ void __init
> kasan_update_early_region(unsigned long k_start, unsigned long k_end, pte_t pte)
> {
> unsigned long k_cur;
> - phys_addr_t pa = __pa(kasan_early_shadow_page);
>
> for (k_cur = k_start; k_cur != k_end; k_cur += PAGE_SIZE) {
> pmd_t *pmd = pmd_off_k(k_cur);
> pte_t *ptep = pte_offset_kernel(pmd, k_cur);
>
> - if ((pte_val(*ptep) & PTE_RPN_MASK) != pa)
> + if (pte_page(*ptep) != virt_to_page(lm_alias(kasan_early_shadow_page)))
> continue;
>
> __set_pte_at(&init_mm, k_cur, ptep, pte, 0);
^ permalink raw reply
* Re: [PATCH] powerpc/ptdump: Fix sparse warning in hashpagetable.c
From: Michael Ellerman @ 2022-02-01 12:25 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
kernel test robot
In-Reply-To: <bbc196451dd34521d239023ccca488db35b8fff1.1643567900.git.christophe.leroy@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> arch/powerpc/mm/ptdump/hashpagetable.c:264:29: warning: restricted __be64 degrades to integer
> arch/powerpc/mm/ptdump/hashpagetable.c:265:49: warning: restricted __be64 degrades to integer
> arch/powerpc/mm/ptdump/hashpagetable.c:267:36: warning: incorrect type in assignment (different base types)
> arch/powerpc/mm/ptdump/hashpagetable.c:267:36: expected unsigned long long [usertype]
> arch/powerpc/mm/ptdump/hashpagetable.c:267:36: got restricted __be64 [usertype] v
> arch/powerpc/mm/ptdump/hashpagetable.c:268:36: warning: incorrect type in assignment (different base types)
> arch/powerpc/mm/ptdump/hashpagetable.c:268:36: expected unsigned long long [usertype]
> arch/powerpc/mm/ptdump/hashpagetable.c:268:36: got restricted __be64 [usertype] r
>
> struct hash_pte fields have type __be64. Convert them to
> regular long before using them.
Your patch changes one side of the comparison but not the other, which
implies the code doesn't work at the moment, ie. it should never be
matching.
But it does work at the moment, so there must be something else going on.
> diff --git a/arch/powerpc/mm/ptdump/hashpagetable.c b/arch/powerpc/mm/ptdump/hashpagetable.c
> index c7f824d294b2..bf60ab1bedb9 100644
> --- a/arch/powerpc/mm/ptdump/hashpagetable.c
> +++ b/arch/powerpc/mm/ptdump/hashpagetable.c
> @@ -261,11 +261,11 @@ static int pseries_find(unsigned long ea, int psize, bool primary, u64 *v, u64 *
Expanding the context a little:
for (i = 0; i < HPTES_PER_GROUP; i += 4, hpte_group += 4) {
lpar_rc = plpar_pte_read_4(0, hpte_group, (void *)ptes);
> if (lpar_rc)
> continue;
> for (j = 0; j < 4; j++) {
> - if (HPTE_V_COMPARE(ptes[j].v, want_v) &&
> - (ptes[j].v & HPTE_V_VALID)) {
> + if (HPTE_V_COMPARE(be64_to_cpu(ptes[j].v), want_v) &&
> + (be64_to_cpu(ptes[j].v) & HPTE_V_VALID)) {
> /* HPTE matches */
> - *v = ptes[j].v;
> - *r = ptes[j].r;
> + *v = be64_to_cpu(ptes[j].v);
> + *r = be64_to_cpu(ptes[j].r);
> return 0;
> }
> }
Turns out the values returned from plpar_pte_read_4() are already in CPU
endian.
We pass an on-stack buffer to plpar_pte_read_4():
plpar_pte_read_4(0, hpte_group, (void *)ptes);
Which makes it look like the hypercall is writing to memory (our
buffer), so we'd expect the values to need an endian swap.
But plpar_pte_read_4() writes into that buffer from another on-stack
buffer:
static inline long plpar_pte_read_4(unsigned long flags, unsigned long ptex,
unsigned long *ptes)
{
long rc;
unsigned long retbuf[PLPAR_HCALL9_BUFSIZE];
rc = plpar_hcall9(H_READ, retbuf, flags | H_READ_4, ptex);
memcpy(ptes, retbuf, 8*sizeof(unsigned long));
return rc;
}
And the values in that stack buffer are actually returned from the
hypervisor in registers, r4-r11, and written into retbuf by the asm
wrapper:
_GLOBAL_TOC(plpar_hcall9)
HMT_MEDIUM
mfcr r0
stw r0,8(r1)
HCALL_BRANCH(plpar_hcall9_trace)
std r4,STK_PARAM(R4)(r1) /* Save ret buffer */ <- this is retbuf
mr r4,r5
mr r5,r6
mr r6,r7
mr r7,r8
mr r8,r9
mr r9,r10
ld r10,STK_PARAM(R11)(r1) /* put arg7 in R10 */
ld r11,STK_PARAM(R12)(r1) /* put arg8 in R11 */
ld r12,STK_PARAM(R13)(r1) /* put arg9 in R12 */
HVSC /* invoke the hypervisor */
mr r0,r12
ld r12,STK_PARAM(R4)(r1) <- reload retbuf into r12
std r4, 0(r12)
std r5, 8(r12)
std r6, 16(r12)
std r7, 24(r12)
std r8, 32(r12)
std r9, 40(r12)
std r10,48(r12)
std r11,56(r12)
std r0, 64(r12)
Although the values are BE in memory in the actual HPT, they're read by
the hypervisor which does the byte swap for us, and then when the
hypervisor returns they're returned in the registers. So there's no
extra byte swap needed.
Possibly we should move struct hash_pte into hash_native.c, which is
where it's almost exclusively used, and is used to point to actual HPTEs
in memory.
But for now I think the patch below is a minimal fix for this sparse
warning, it's what other callers of plpar_pte_read_4() are doing.
cheers
diff --git a/arch/powerpc/mm/ptdump/hashpagetable.c b/arch/powerpc/mm/ptdump/hashpagetable.c
index c7f824d294b2..9a601587836b 100644
--- a/arch/powerpc/mm/ptdump/hashpagetable.c
+++ b/arch/powerpc/mm/ptdump/hashpagetable.c
@@ -238,7 +238,10 @@ static int native_find(unsigned long ea, int psize, bool primary, u64 *v, u64
static int pseries_find(unsigned long ea, int psize, bool primary, u64 *v, u64 *r)
{
- struct hash_pte ptes[4];
+ struct {
+ unsigned long v;
+ unsigned long r;
+ } ptes[4];
unsigned long vsid, vpn, hash, hpte_group, want_v;
int i, j, ssize = mmu_kernel_ssize;
long lpar_rc = 0;
^ permalink raw reply related
* Re: microwatt booting linux-5.7 under verilator
From: Luke Kenneth Casson Leighton @ 2022-02-01 11:59 UTC (permalink / raw)
To: Michael Ellerman
Cc: openpower-hdl-cores, Libre-Soc General Development, linuxppc-dev,
Nicholas Piggin
In-Reply-To: <87o83qn6qd.fsf@mpe.ellerman.id.au>
On Tue, Feb 1, 2022 at 11:53 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
> If you build with CONFIG_RELOCATABLE=y and CONFIG_RELOCATABLE_TEST=y the
> kernel will run wherever you load it (must be 64K aligned), without
> copying itself down to zero first. That will save you a few cycles.
ahh, thank you :)
l.
^ permalink raw reply
* Re: [Oops][next-20220128] 5.17.0-rc1 kernel panics on my powerpc box
From: Michael Ellerman @ 2022-02-01 12:02 UTC (permalink / raw)
To: Andy Shevchenko, Abdul Haleem, Thomas Gleixner
Cc: sachinp, Stephen Rothwell, heikki.krogerus, peterz, linux-next,
Brian King, linuxppc-dev
In-Reply-To: <YffISHu7b/qMEdUa@smile.fi.intel.com>
Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
> On Mon, Jan 31, 2022 at 12:30:14PM +0530, Abdul Haleem wrote:
>> Greeting's
>>
>> Today's linux-next kernel failed to boot 5.17.0-rc1-next-20220128 with kernel Oops on PowerVM LPAR
>>
>> dmesg:
>> Started hybrid virtual network scan and config.
>> Started VDO volume services.
>> Started Dynamic System Tuning Daemon.
>> Attempted to run process '/opt/rsct/bin/trspoolmgr' with NULL argv
>> Created slice system-systemd\x2dcoredump.slice.
>> Started Process Core Dump (PID 3726/UID 0).
>> Started Process Core Dump (PID 4032/UID 0).
>> Started Process Core Dump (PID 4200/UID 0).
>> Started RMC-Resource Monitioring and Control.
>> Started Process Core Dump (PID 4319/UID 0).
>> rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
>> rpaphp: Slot [U78D2.001.WZS01DT-P1-C10] registered
>> Started Process Core Dump (PID 4687/UID 0).
>> Started Process Core Dump (PID 4806/UID 0).
>> Started Process Core Dump (PID 4973/UID 0).
>> Async-gnnft timeout - hdl=7.
>> BUG: Unable to handle kernel data access on read at 0x5deadbeef000012a
>> Faulting instruction address: 0xc000000000221f4c
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
>> Modules linked in: rpadlpar_io rpaphp tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag bonding rfkill sunrpc dm_round_robin dm_multipath dm_mod ocrdma ib_uverbs ib_core pseries_rng xts vmx_crypto uio_pdrv_genirq gf128mul uio sch_fq_codel ext4 mbcache jbd2 sd_mod sg qla2xxx ibmvscsi ibmveth scsi_transport_srp nvme_fc nvme_fabrics nvme_core be2net t10_pi scsi_transport_fc
>> CPU: 8 PID: 5782 Comm: mksquashfs Not tainted 5.17.0-rc1-next-20220128-autotest #1
>> NIP: c000000000221f4c LR: c000000000221ee4 CTR: 0000000000000006
>> REGS: c0000001008bb920 TRAP: 0380 Not tainted (5.17.0-rc1-next-20220128-autotest)
>> MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24004224 XER: 20040000
>> CFAR: c000000000220df8 IRQMASK: 1
>> GPR00: c000000000221ee4 c0000001008bbbc0 c0000000028d6100 00000000ffff9cc0
>> GPR04: 0000000000000000 00000000000001c0 00000000000001c0 0000000000000000
>> GPR08: 0000000000000000 5deadbeef0000122 c0000001008bbbe8 0000000000000001
>> GPR12: c000000000221d50 c000000007fe6680 00007fffbcf00000 0000000000000100
>> GPR16: 0000000000000100 00007fffbce64420 0000000000000001 0000000000000002
>> GPR20: c000000002912108 5deadbeef0000122 c00000079c008668 0000000000000000
>> GPR24: 0000000000000000 c0000001008bbbe8 00000000ffff9540 c000000002913a00
>> GPR28: 0000000000000000 c0000000a4560950 c00000079c008600 c0000000020e8600
>> NIP [c000000000221f4c] run_timer_softirq+0x1fc/0x7c0
>> LR [c000000000221ee4] run_timer_softirq+0x194/0x7c0
>> Call Trace:
>> [c0000001008bbbc0] [c000000000221ee4] run_timer_softirq+0x194/0x7c0 (unreliable)
>> [c0000001008bbc90] [c000000000ca7e5c] __do_softirq+0x15c/0x3d0
>> [c0000001008bbd80] [c00000000014f538] irq_exit+0x168/0x1b0
>> [c0000001008bbdb0] [c000000000027184] timer_interrupt+0x1a4/0x3e0
>> [c0000001008bbe10] [c000000000009a08] decrementer_common_virt+0x208/0x210
>> --- interrupt: 900 at 0x7fffbccb3850
>> NIP: 00007fffbccb3850 LR: 00007fffbccb51f8 CTR: 0000000000000000
>> REGS: c0000001008bbe80 TRAP: 0900 Not tainted (5.17.0-rc1-next-20220128-autotest)
>> MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 42004488 XER: 20040000
>> CFAR: 0000000000000000 IRQMASK: 0
>> GPR00: 0000000000007fff 00007ffe8afde4d0 00007fffbcce7f00 00007ffe74020c50
>> GPR04: 0000000000006bfa 0000000000003cf1 00007ffe740223a0 0000000000000005
>> GPR08: 00007ffe74028fb4 00000000000009a3 0000000000000004 0000000000000039
>> GPR12: 00007ffe740323b0 00007ffe8afe68e0 00007fffbcf00000 00007ffe8a7d0000
>> GPR16: 00007fffbce64410 00007fffbce64420 0000000000000000 00007fffbce60318
>> GPR20: 00007ffe740323b0 00007ffe740423c0 0000000000003fff 0000000000000005
>> GPR24: 0000000000000004 00007fffbccc8058 0000000000000000 000000000000000c
>> GPR28: 0000000000000102 0000000000004415 00007ffe7402df8b 00007ffe7402e08d
>> NIP [00007fffbccb3850] 0x7fffbccb3850
>> LR [00007fffbccb51f8] 0x7fffbccb51f8
>> --- interrupt: 900
>> Instruction dump:
>> 60000000 e9390000 2fa90000 419effc8 ebb90000 fbbe0008 60000000 e93d0000
>> e95d0008 2fa90000 f92a0000 419e0008 <f9490008> 813d0020 fb1d0008 ea9d0018
>> ---[ end trace 0000000000000000 ]---
>>
>> The fault instruction points to
>>
>> # gdb -batch /boot/vmlinuz-5.17.0-rc1-next-20220128-autotest -ex 'list *(0xc000000000221f4c)'
>> 0xc000000000221f4c is in run_timer_softirq (./include/linux/list.h:850).
>> 845 struct hlist_node *next = n->next;
>> 846 struct hlist_node **pprev = n->pprev;
>> 847
>> 848 WRITE_ONCE(*pprev, next);
>> 849 if (next)
>> 850 WRITE_ONCE(next->pprev, pprev);
>> 851 }
>> 852
>> 853 /**
>> 854 * hlist_del - Delete the specified hlist_node from its list
>
> It's quite likely not a culprit, but the result of some (race?) condition.
> Cc'ing to Thomas, maybe he has an idea.
The disassembly says we're storing r10 to r9 + 8. If you look at the
first register dump, r9 is 5deadbeef0000122 which is:
#define LIST_POISON2 ((void *) 0x122 + POISON_POINTER_DELTA)
So we seem to be deleting a list entry that's already been deleted?
cheers
^ permalink raw reply
* Re: [PATCH v3] powerpc: Fix virt_addr_valid() check
From: Christophe Leroy @ 2022-02-01 11:57 UTC (permalink / raw)
To: Kefeng Wang, linuxppc-dev@lists.ozlabs.org, mpe@ellerman.id.au,
benh@kernel.crashing.org, paulus@samba.org,
linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, npiggin@gmail.com
In-Reply-To: <20220127123754.77825-1-wangkefeng.wang@huawei.com>
Le 27/01/2022 à 13:37, Kefeng Wang a écrit :
> When run ethtool eth0 on PowerPC64, the BUG occurred,
>
> usercopy: Kernel memory exposure attempt detected from SLUB object not in SLUB page?! (offset 0, size 1048)!
> kernel BUG at mm/usercopy.c:99
> ...
> usercopy_abort+0x64/0xa0 (unreliable)
> __check_heap_object+0x168/0x190
> __check_object_size+0x1a0/0x200
> dev_ethtool+0x2494/0x2b20
> dev_ioctl+0x5d0/0x770
> sock_do_ioctl+0xf0/0x1d0
> sock_ioctl+0x3ec/0x5a0
> __se_sys_ioctl+0xf0/0x160
> system_call_exception+0xfc/0x1f0
> system_call_common+0xf8/0x200
>
> The code shows below,
>
> data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN));
> copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN))
>
> The data is alloced by vmalloc(), virt_addr_valid(ptr) will return true
> on PowerPC64, which leads to the panic.
>
> As commit 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va
> and __pa addresses") does, let's check the virt addr above PAGE_OFFSET in
> the virt_addr_valid() for PowerPC64, which will make sure that the passed
> address is a valid linear map address.
>
> Meanwhile, PAGE_OFFSET is the virtual address of the start of lowmem,
> the check is suitable for PowerPC32 too.
>
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> v3:
> - update changelog and remove a redundant cast
> arch/powerpc/include/asm/page.h | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index 254687258f42..a8a29a23ce2d 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -132,7 +132,10 @@ static inline bool pfn_valid(unsigned long pfn)
> #define virt_to_page(kaddr) pfn_to_page(virt_to_pfn(kaddr))
> #define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
>
> -#define virt_addr_valid(kaddr) pfn_valid(virt_to_pfn(kaddr))
> +#define virt_addr_valid(vaddr) ({ \
> + unsigned long _addr = (unsigned long)vaddr; \
> + _addr >= PAGE_OFFSET && pfn_valid(virt_to_pfn(_addr)); \
> +})
>
> /*
> * On Book-E parts we need __va to parse the device tree and we can't
^ permalink raw reply
* Re: microwatt booting linux-5.7 under verilator
From: Michael Ellerman @ 2022-02-01 11:53 UTC (permalink / raw)
To: Nicholas Piggin, Libre-Soc General Development, linuxppc-dev,
Luke Kenneth Casson Leighton, lkcl, openpower-hdl-cores
In-Reply-To: <1643696448.f3llnvzeyb.astroid@bobo.none>
Nicholas Piggin <npiggin@gmail.com> writes:
> Excerpts from lkcl's message of January 31, 2022 2:19 pm:
>>
>> On January 31, 2022 3:31:41 AM UTC, Nicholas Piggin <npiggin@gmail.com> wrote:
>>>Hi Luke,
>>>
>>>Interesting to read about the project, thanks for the post.
>>
>> no problem. it's been i think 18 years since i last did linux kernel work.
>>
>>>> i also had to fix a couple of things in the linux kernel source
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/joel/microwatt.git
>>>
>>>I think these have mostly (all?) been upstreamed now.
>>
>> i believe so, although last i checked (6 months?) there was some of dts still to do. instructions online all tend to refer to joel or benh's tree(s)
>>
>>>> this led me to add support for CONFIG_KERNEL_UNCOMPRESSED
>>>> and cut that time entirely, hence why you can see this in the console
>>>log:
>>>>
>>>> 0x5b0e10 bytes of uncompressed data copied
>>>
>>>Interesting, it looks like your HAVE_KERNEL_UNCOMPRESSED support
>>>patch is pretty trivial.
>>
>> yeah i was really surprised, it was all there
>>
>>> We should be able to upstream it pretty
>>>easily I think?
>>
>> don't see why not.
>
> Okay then we should.
>
>>
>> the next interesting thing which would save another hour when emulating HDL at this astoundingly-slow speed of sub-1000 instructions per second would be in-place execution: no memcpy, just jump.
>>
>> i seem to recall this (inplace execution) being a standard option back in 2003 when i was doing xda-developers wince smartphone reverse-emgineering, although with it being 19 years ago i could be wrong
>
> Not sure of the details on that. Is it memcpy()ing out of ROM or RAM to
> RAM? Is this in the arch boot code? (I don't know very well).
If you build with CONFIG_RELOCATABLE=y and CONFIG_RELOCATABLE_TEST=y the
kernel will run wherever you load it (must be 64K aligned), without
copying itself down to zero first. That will save you a few cycles.
cheers
^ permalink raw reply
* Re: [PATCH V4 16/17] riscv: compat: Add COMPAT Kbuild skeletal support
From: Arnd Bergmann @ 2022-02-01 11:48 UTC (permalink / raw)
To: Guo Ren
Cc: Guo Ren, open list:BROADCOM NVRAM DRIVER, sparclinux, linux-riscv,
Christoph Hellwig, linux-arch, linux-s390, Anup Patel,
the arch/x86 maintainers, linux-csky, Christoph Hellwig,
Arnd Bergmann, Linux ARM, Parisc List, Drew Fustini, liush,
Wang Junqiang, Linux Kernel Mailing List, Palmer Dabbelt,
Greg Kroah-Hartman, linuxppc-dev, Wei Fu
In-Reply-To: <CAJF2gTTgTzvGfa3nGzVo4C=fe+ZCGBWp=VhTMRt1vF1O1bnS5g@mail.gmail.com>
On Tue, Feb 1, 2022 at 11:26 AM Guo Ren <guoren@kernel.org> wrote:
>
> Hi Arnd & Christoph,
>
> The UXL field controls the value of XLEN for U-mode, termed UXLEN,
> which may differ from the
> value of XLEN for S-mode, termed SXLEN. The encoding of UXL is the
> same as that of the MXL
> field of misa, shown in Table 3.1.
>
> Here is the patch. (We needn't exception helper, because we are in
> S-mode and UXL wouldn't affect.)
Looks good to me, just a few details that could be improved
> -#define compat_elf_check_arch(x) ((x)->e_machine == EM_RISCV)
> +#ifdef CONFIG_COMPAT
> +#define compat_elf_check_arch compat_elf_check_arch
> +extern bool compat_elf_check_arch(Elf32_Ehdr *hdr);
> +#endif
No need for the #ifdef
> +}
> +void compat_mode_detect(void)
__init
> +{
> + unsigned long tmp = csr_read(CSR_STATUS);
> + csr_write(CSR_STATUS, (tmp & ~SR_UXL) | SR_UXL_32);
> +
> + if ((csr_read(CSR_STATUS) & SR_UXL) != SR_UXL_32) {
> + csr_write(CSR_STATUS, tmp);
> + return;
> + }
> +
> + csr_write(CSR_STATUS, tmp);
> + compat_mode_support = true;
> +
> + pr_info("riscv: compat: 32bit U-mode applications support\n");
> +}
I think an entry in /proc/cpuinfo would be more helpful than the pr_info at
boot time. Maybe a follow-up patch though, as there is no obvious place
to put it. On other architectures, you typically have a set of space
separated feature names, but riscv has a single string that describes
the ISA, and this feature is technically the support for a second ISA.
Arnd
^ permalink raw reply
* Re: powerpc: Set crashkernel offset to mid of RMA region
From: Michael Ellerman @ 2022-02-01 11:44 UTC (permalink / raw)
To: Sourabh Jain, linuxppc-dev; +Cc: mahesh, hbathini, Abdul haleem
In-Reply-To: <20220128100445.251233-1-sourabhjain@linux.ibm.com>
Sourabh Jain <sourabhjain@linux.ibm.com> writes:
> On large config LPARs (having 192 and more cores), Linux fails to boot
> due to insufficient memory in the first memblock. It is due to the
> memory reservation for the crash kernel which starts at 128MB offset of
> the first memblock. This memory reservation for the crash kernel doesn't
> leave enough space in the first memblock to accommodate other essential
> system resources.
>
> The crash kernel start address was set to 128MB offset by default to
> ensure that the crash kernel get some memory below the RMA region which
> is used to be of size 256MB. But given that the RMA region size can be
> 512MB or more, setting the crash kernel offset to mid of RMA size will
> leave enough space for kernel to allocate memory for other system
> resources.
>
> Since the above crash kernel offset change is only applicable to the LPAR
> platform, the LPAR feature detection is pushed before the crash kernel
> reservation. The rest of LPAR specific initialization will still
> be done during pseries_probe_fw_features as usual.
>
> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> Reported-and-tested-by: Abdul haleem <abdhalee@linux.vnet.ibm.com>
>
> ---
> arch/powerpc/kernel/rtas.c | 4 ++++
> arch/powerpc/kexec/core.c | 15 +++++++++++----
> 2 files changed, 15 insertions(+), 4 deletions(-)
>
> ---
> Change in v3:
> Dropped 1st and 2nd patch from v2. 1st and 2nd patch from v2 patch
> series [1] try to discover 1T segment MMU feature support
> BEFORE boot CPU paca allocation ([1] describes why it is needed).
> MPE has posted a patch [2] that archives a similar objective by moving
> boot CPU paca allocation after mmu_early_init_devtree().
>
> NOTE: This patch is dependent on the patch [2].
>
> [1] https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20211018084434.217772-3-sourabhjain@linux.ibm.com/
> [2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-January/239175.html
> ---
>
> diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
> index 733e6ef36758..06df7464fb57 100644
> --- a/arch/powerpc/kernel/rtas.c
> +++ b/arch/powerpc/kernel/rtas.c
> @@ -1313,6 +1313,10 @@ int __init early_init_dt_scan_rtas(unsigned long node,
> entryp = of_get_flat_dt_prop(node, "linux,rtas-entry", NULL);
> sizep = of_get_flat_dt_prop(node, "rtas-size", NULL);
>
> + /* need this feature to decide the crashkernel offset */
> + if (of_get_flat_dt_prop(node, "ibm,hypertas-functions", NULL))
> + powerpc_firmware_features |= FW_FEATURE_LPAR;
> +
As you'd have seen this breaks the 32-bit build. It will need an #ifdef
CONFIG_PPC64 around it.
> if (basep && entryp && sizep) {
> rtas.base = *basep;
> rtas.entry = *entryp;
> diff --git a/arch/powerpc/kexec/core.c b/arch/powerpc/kexec/core.c
> index 8b68d9f91a03..abf5897ae88c 100644
> --- a/arch/powerpc/kexec/core.c
> +++ b/arch/powerpc/kexec/core.c
> @@ -134,11 +134,18 @@ void __init reserve_crashkernel(void)
> if (!crashk_res.start) {
> #ifdef CONFIG_PPC64
> /*
> - * On 64bit we split the RMO in half but cap it at half of
> - * a small SLB (128MB) since the crash kernel needs to place
> - * itself and some stacks to be in the first segment.
> + * On the LPAR platform place the crash kernel to mid of
> + * RMA size (512MB or more) to ensure the crash kernel
> + * gets enough space to place itself and some stack to be
> + * in the first segment. At the same time normal kernel
> + * also get enough space to allocate memory for essential
> + * system resource in the first segment. Keep the crash
> + * kernel starts at 128MB offset on other platforms.
> */
> - crashk_res.start = min(0x8000000ULL, (ppc64_rma_size / 2));
> + if (firmware_has_feature(FW_FEATURE_LPAR))
> + crashk_res.start = ppc64_rma_size / 2;
> + else
> + crashk_res.start = min(0x8000000ULL, (ppc64_rma_size / 2));
I think this will break on machines using Radix won't it? At this point
in boot ppc64_rma_size will be == 0. Because we won't call into
hash__setup_initial_memory_limit().
That's not changed by your patch, but seems like this code needs to be
more careful/clever.
cheers
> #else
> crashk_res.start = KDUMP_KERNELBASE;
> #endif
> --
> 2.34.1
^ permalink raw reply
* Re: [PATCH] powerpc/xive: Add some error handling code to 'xive_spapr_init()'
From: Christophe Leroy @ 2022-02-01 11:31 UTC (permalink / raw)
To: Christophe JAILLET, benh, paulus, mpe, allison, tglx, clg, groug
Cc: linuxppc-dev, kernel-janitors, linux-kernel
In-Reply-To: <20190801110956.8517-1-christophe.jaillet@wanadoo.fr>
Hi,
Le 01/08/2019 à 13:09, Christophe JAILLET a écrit :
> 'xive_irq_bitmap_add()' can return -ENOMEM.
> In this case, we should free the memory already allocated and return
> 'false' to the caller.
>
> Also add an error path which undoes the 'tima = ioremap(...)'
This old patch doesn't apply, if it is still relevant can you please
rebase ?
Thanks
Christophe
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> NOT compile tested (I don't have a cross compiler and won't install one).
> So if some correction or improvement are needed, feel free to propose and
> commit it directly.
> ---
> arch/powerpc/sysdev/xive/spapr.c | 36 +++++++++++++++++++++++++-------
> 1 file changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/xive/spapr.c b/arch/powerpc/sysdev/xive/spapr.c
> index 52198131c75e..b3ae0b76c433 100644
> --- a/arch/powerpc/sysdev/xive/spapr.c
> +++ b/arch/powerpc/sysdev/xive/spapr.c
> @@ -64,6 +64,17 @@ static int xive_irq_bitmap_add(int base, int count)
> return 0;
> }
>
> +static void xive_irq_bitmap_remove_all(void)
> +{
> + struct xive_irq_bitmap *xibm, *tmp;
> +
> + list_for_each_entry_safe(xibm, tmp, &xive_irq_bitmaps, list) {
> + list_del(&xibm->list);
> + kfree(xibm->bitmap);
> + kfree(xibm);
> + }
> +}
> +
> static int __xive_irq_bitmap_alloc(struct xive_irq_bitmap *xibm)
> {
> int irq;
> @@ -723,7 +734,7 @@ bool __init xive_spapr_init(void)
> u32 val;
> u32 len;
> const __be32 *reg;
> - int i;
> + int i, err;
>
> if (xive_spapr_disabled())
> return false;
> @@ -748,23 +759,26 @@ bool __init xive_spapr_init(void)
> }
>
> if (!xive_get_max_prio(&max_prio))
> - return false;
> + goto err_unmap;
>
> /* Feed the IRQ number allocator with the ranges given in the DT */
> reg = of_get_property(np, "ibm,xive-lisn-ranges", &len);
> if (!reg) {
> pr_err("Failed to read 'ibm,xive-lisn-ranges' property\n");
> - return false;
> + goto err_unmap;
> }
>
> if (len % (2 * sizeof(u32)) != 0) {
> pr_err("invalid 'ibm,xive-lisn-ranges' property\n");
> - return false;
> + goto err_unmap;
> }
>
> - for (i = 0; i < len / (2 * sizeof(u32)); i++, reg += 2)
> - xive_irq_bitmap_add(be32_to_cpu(reg[0]),
> - be32_to_cpu(reg[1]));
> + for (i = 0; i < len / (2 * sizeof(u32)); i++, reg += 2) {
> + err = xive_irq_bitmap_add(be32_to_cpu(reg[0]),
> + be32_to_cpu(reg[1]));
> + if (err < 0)
> + goto err_mem_free;
> + }
>
> /* Iterate the EQ sizes and pick one */
> of_property_for_each_u32(np, "ibm,xive-eq-sizes", prop, reg, val) {
> @@ -775,8 +789,14 @@ bool __init xive_spapr_init(void)
>
> /* Initialize XIVE core with our backend */
> if (!xive_core_init(&xive_spapr_ops, tima, TM_QW1_OS, max_prio))
> - return false;
> + goto err_mem_free;
>
> pr_info("Using %dkB queues\n", 1 << (xive_queue_shift - 10));
> return true;
> +
> +err_mem_free:
> + xive_irq_bitmap_remove_all();
> +err_unmap:
> + iounmap(tima);
> + return false;
> }
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: reserve memory for capture kernel after hugepages init
From: Christophe Leroy @ 2022-02-01 11:18 UTC (permalink / raw)
To: Hari Bathini
Cc: linuxppc-dev, Mahesh J Salgaonkar, Ananth N Mavinakayanahalli
In-Reply-To: <156166326909.13320.3330203549978146193.stgit@hbathini.in.ibm.com>
Le 27/06/2019 à 21:21, Hari Bathini a écrit :
> Sometimes, memory reservation for KDump/FADump can overlap with memory
> marked for hugepages. This overlap leads to error, hang in KDump case
> and copy error reported by f/w in case of FADump, while trying to
> capture dump. Report error while setting up memory for the capture
> kernel instead of running into issues while capturing dump, by moving
> KDump/FADump reservation below MMU early init and failing gracefully
> when hugepages memory overlaps with capture kernel memory.
This patch doesn't apply, if it's still needed can you please rebase ?
Christophe
>
> Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
> ---
> arch/powerpc/kernel/prom.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index 7159e79..454e19cf 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -731,14 +731,6 @@ void __init early_init_devtree(void *params)
> if (PHYSICAL_START > MEMORY_START)
> memblock_reserve(MEMORY_START, 0x8000);
> reserve_kdump_trampoline();
> -#ifdef CONFIG_FA_DUMP
> - /*
> - * If we fail to reserve memory for firmware-assisted dump then
> - * fallback to kexec based kdump.
> - */
> - if (fadump_reserve_mem() == 0)
> -#endif
> - reserve_crashkernel();
> early_reserve_mem();
>
> /* Ensure that total memory size is page-aligned. */
> @@ -777,6 +769,14 @@ void __init early_init_devtree(void *params)
> #endif
>
> mmu_early_init_devtree();
> +#ifdef CONFIG_FA_DUMP
> + /*
> + * If we fail to reserve memory for firmware-assisted dump then
> + * fallback to kexec based kdump.
> + */
> + if (fadump_reserve_mem() == 0)
> +#endif
> + reserve_crashkernel();
>
> #ifdef CONFIG_PPC_POWERNV
> /* Scan and build the list of machine check recoverable ranges */
^ permalink raw reply
* Re: consolidate the compat fcntl definitions v2
From: Christophe Leroy @ 2022-02-01 11:23 UTC (permalink / raw)
To: Christoph Hellwig, Arnd Bergmann
Cc: linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
linux-parisc@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, Guo Ren,
sparclinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20220131064933.3780271-1-hch@lst.de>
Hi Christoph,
Le 31/01/2022 à 07:49, Christoph Hellwig a écrit :
> Hi all,
>
> currenty the compat fcnt definitions are duplicate for all compat
> architectures, and the native fcntl64 definitions aren't even usable
> from userspace due to a bogus CONFIG_64BIT ifdef. This series tries
> to sort out all that.
There must be something wrong with this cover letter, patchwork doesn't
see it, see
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?submitter=82
Any idea what the problem is ?
Thanks
Christophe
>
> Changes since v1:
> - only make the F*64 defines uapi visible for 32-bit architectures
>
> Diffstat:
> arch/arm64/include/asm/compat.h | 20 --------------------
> arch/mips/include/asm/compat.h | 23 ++---------------------
> arch/mips/include/uapi/asm/fcntl.h | 30 +++++-------------------------
> arch/parisc/include/asm/compat.h | 16 ----------------
> arch/powerpc/include/asm/compat.h | 20 --------------------
> arch/s390/include/asm/compat.h | 20 --------------------
> arch/sparc/include/asm/compat.h | 22 +---------------------
> arch/x86/include/asm/compat.h | 24 +++---------------------
> include/linux/compat.h | 31 +++++++++++++++++++++++++++++++
> include/uapi/asm-generic/fcntl.h | 23 +++++++++--------------
> tools/include/uapi/asm-generic/fcntl.h | 21 +++++++--------------
> 11 files changed, 58 insertions(+), 192 deletions(-)
^ permalink raw reply
* Re: microwatt booting linux-5.7 under verilator
From: Luke Kenneth Casson Leighton @ 2022-02-01 9:52 UTC (permalink / raw)
To: Nicholas Piggin
Cc: openpower-hdl-cores, Libre-Soc General Development, linuxppc-dev
In-Reply-To: <1643696448.f3llnvzeyb.astroid@bobo.none>
On Tue, Feb 1, 2022 at 6:27 AM Nicholas Piggin <npiggin@gmail.com> wrote:
> Not sure of the details on that. Is it memcpy()ing out of ROM or RAM to
> RAM? Is this in the arch boot code? (I don't know very well).
RAM to RAM. arch/powerpc/boot/main.c:
if (uncompressed_image) {
memcpy(addr, vmlinuz_addr + ei.elfoffset, ei.loadsize);
printf("0x%lx bytes of uncompressed data copied\n\r",
ei.loadsize);
goto out;
}
in some systems those would be two different types of RAM,
(one would be on-board SRAM, the target would be DRAM
which had previously been initialised by the previous chain-boot
loader e.g. u-boot)
[in other circumstances, the source location might be addressable
SPI NOR flash, which would be slower, expensive, and therefore
compression is plain common sense, in which case it's out of
scope for this discussion.]
in the case of the simulation - and also in the case of the
WinCE Smartphone hand-held reverse-engineering using
GNUHARET.EXE (similar to LOADLIN.EXE if anyone remembers
that) - the uncompressed initramfs are both in the same
RAM, so the memcpy is completely redundant.
the only good reason for the memcpy would be to ensure
that the start location is at a known-fixed offset, and of course
that can be arranged in advance by the simulator. even if
it has to be at 0x0000_0000_0000_0000 that can be arranged
by moving the cold-boot loader to an alternative hard-reset
start address and telling the simulated-core to start from there.
> >
> > other areas are the memset before VM is set up, followed by memset *again* on.individual pages once created. those are an hour each
>
> Seems like we could should avoid the duplication and maybe be able to
> add an option to skip zeroing (I thought there was one, maybe thinking
> of something else).
it makes sense for security reasons (on real hardware) - a simulation
not so much, it's guaranteed to be all-zeros at startup.
> Are you using optimize for size? That can result in much slower code in
> some places. In skiboot we compile some of the string.h library code
> with -O2 for example.
interesting - no, this is default options. have to be careful not to
introduce any VSX instructions (the core doesn't have them).
CROSS_COMPILE="ccache powerpc64le-linux-gnu-" \
ARCH=powerpc \
make -j16 O=microwatt
l.
^ permalink raw reply
* Re: powerpc: Set crashkernel offset to mid of RMA region
From: Hari Bathini @ 2022-02-01 11:10 UTC (permalink / raw)
To: Sourabh Jain, linuxppc-dev, mpe; +Cc: mahesh, Abdul haleem
In-Reply-To: <20220128100445.251233-1-sourabhjain@linux.ibm.com>
On 28/01/22 3:34 pm, Sourabh Jain wrote:
> On large config LPARs (having 192 and more cores), Linux fails to boot
> due to insufficient memory in the first memblock. It is due to the
> memory reservation for the crash kernel which starts at 128MB offset of
> the first memblock. This memory reservation for the crash kernel doesn't
> leave enough space in the first memblock to accommodate other essential
> system resources.
>
> The crash kernel start address was set to 128MB offset by default to
> ensure that the crash kernel get some memory below the RMA region which
> is used to be of size 256MB. But given that the RMA region size can be
> 512MB or more, setting the crash kernel offset to mid of RMA size will
> leave enough space for kernel to allocate memory for other system
> resources.
>
> Since the above crash kernel offset change is only applicable to the LPAR
> platform, the LPAR feature detection is pushed before the crash kernel
> reservation. The rest of LPAR specific initialization will still
> be done during pseries_probe_fw_features as usual.
>
> Signed-off-by: Sourabh Jain<sourabhjain@linux.ibm.com>
> Reported-and-tested-by: Abdul haleem<abdhalee@linux.vnet.ibm.com>
>
> ---
> arch/powerpc/kernel/rtas.c | 4 ++++
> arch/powerpc/kexec/core.c | 15 +++++++++++----
> 2 files changed, 15 insertions(+), 4 deletions(-)
>
> ---
> Change in v3:
> Dropped 1st and 2nd patch from v2. 1st and 2nd patch from v2 patch
> series [1] try to discover 1T segment MMU feature support
> BEFORE boot CPU paca allocation ([1] describes why it is needed).
> MPE has posted a patch [2] that archives a similar objective by moving
> boot CPU paca allocation after mmu_early_init_devtree().
>
> NOTE: This patch is dependent on the patch [2].
>
> [1]https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20211018084434.217772-3-sourabhjain@linux.ibm.com/
> [2]https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-January/239175.html
This dependency info must be captured somewhere within the changelog to
be useful.
^ permalink raw reply
* [RESEND PATCH v2] powerpc/fadump: register for fadump as early as possible
From: Hari Bathini @ 2022-02-01 10:53 UTC (permalink / raw)
To: Michael Ellerman
Cc: Kairui Song, Petr Tesarik, Mahesh J Salgaonkar, Sourabh Jain,
linuxppc-dev, Michal Suchánek, Dave Young
Crash recovery (fadump) is setup in the userspace by some service.
This service rebuilds initrd with dump capture capability, if it is
not already dump capture capable before proceeding to register for
firmware assisted dump (echo 1 > /sys/kernel/fadump/registered). But
arming the kernel with crash recovery support does not have to wait
for userspace configuration. So, register for fadump while setting
it up itself. This can at worst lead to a scenario, where /proc/vmcore
is ready afer crash but the initrd does not know how/where to offload
it, which is always better than not having a /proc/vmcore at all due
to incomplete configuration in the userspace at the time of crash.
Commit 0823c68b054b ("powerpc/fadump: re-register firmware-assisted
dump if already registered") ensures this change does not break
userspace.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
---
* Resending the patch after rebasing on latest code.
Changes in V2:
* Updated the changelog with bit more explanation about userspace issue
with/without this change.
* Added a comment in the code for why setup_fadump function is changed
from subsys_init() to subsys_init_sync() call.
arch/powerpc/kernel/fadump.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index d03e488cfe9c..97d80df4563f 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -1637,9 +1637,11 @@ int __init setup_fadump(void)
if (fw_dump.ops->fadump_process(&fw_dump) < 0)
fadump_invalidate_release_mem();
}
- /* Initialize the kernel dump memory structure for FAD registration. */
- else if (fw_dump.reserve_dump_area_size)
+ /* Initialize the kernel dump memory structure and register with f/w */
+ else if (fw_dump.reserve_dump_area_size) {
fw_dump.ops->fadump_init_mem_struct(&fw_dump);
+ register_fadump();
+ }
/*
* In case of panic, fadump is triggered via ppc_panic_event()
@@ -1651,7 +1653,12 @@ int __init setup_fadump(void)
return 1;
}
-subsys_initcall(setup_fadump);
+/*
+ * Replace subsys_initcall() with subsys_initcall_sync() as there is dependency
+ * with crash_save_vmcoreinfo_init() to ensure vmcoreinfo initialization is done
+ * before regisering with f/w.
+ */
+subsys_initcall_sync(setup_fadump);
#else /* !CONFIG_PRESERVE_FA_DUMP */
/* Scan the Firmware Assisted dump configuration details. */
--
2.34.1
^ permalink raw reply related
* Re: [PATCH V4 16/17] riscv: compat: Add COMPAT Kbuild skeletal support
From: Guo Ren @ 2022-02-01 10:26 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, linux-s390, Guo Ren, Parisc List, Greg Kroah-Hartman,
Drew Fustini, Anup Patel, Wang Junqiang, the arch/x86 maintainers,
Linux Kernel Mailing List, linux-csky,
open list:BROADCOM NVRAM DRIVER, Christoph Hellwig,
Palmer Dabbelt, liush, sparclinux, linux-riscv, linuxppc-dev,
Christoph Hellwig, Linux ARM, Wei Fu
In-Reply-To: <CAK8P3a2C7nDGQvopYzi1fe_LWyosp8t9dcBsduYK5k_s_OrCaA@mail.gmail.com>
Hi Arnd & Christoph,
The UXL field controls the value of XLEN for U-mode, termed UXLEN,
which may differ from the
value of XLEN for S-mode, termed SXLEN. The encoding of UXL is the
same as that of the MXL
field of misa, shown in Table 3.1.
Here is the patch. (We needn't exception helper, because we are in
S-mode and UXL wouldn't affect.)
arch/riscv/include/asm/elf.h | 5 ++++-
arch/riscv/include/asm/processor.h | 1 +
arch/riscv/kernel/process.c | 22 ++++++++++++++++++++++
arch/riscv/kernel/setup.c | 5 +++++
4 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/include/asm/elf.h b/arch/riscv/include/asm/elf.h
index 37f1cbdaa242..6baa49c4fba1 100644
--- a/arch/riscv/include/asm/elf.h
+++ b/arch/riscv/include/asm/elf.h
@@ -35,7 +35,10 @@
*/
#define elf_check_arch(x) ((x)->e_machine == EM_RISCV)
-#define compat_elf_check_arch(x) ((x)->e_machine == EM_RISCV)
+#ifdef CONFIG_COMPAT
+#define compat_elf_check_arch compat_elf_check_arch
+extern bool compat_elf_check_arch(Elf32_Ehdr *hdr);
+#endif
#define CORE_DUMP_USE_REGSET
#define ELF_EXEC_PAGESIZE (PAGE_SIZE)
diff --git a/arch/riscv/include/asm/processor.h
b/arch/riscv/include/asm/processor.h
index 9544c138d9ce..8b288ac0d704 100644
--- a/arch/riscv/include/asm/processor.h
+++ b/arch/riscv/include/asm/processor.h
@@ -64,6 +64,7 @@ extern void start_thread(struct pt_regs *regs,
#ifdef CONFIG_COMPAT
extern void compat_start_thread(struct pt_regs *regs,
unsigned long pc, unsigned long sp);
+extern void compat_mode_detect(void);
#define DEFAULT_MAP_WINDOW_64 TASK_SIZE_64
#else
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index 9ebf9a95e5ea..496d09c5d384 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -101,6 +101,28 @@ void start_thread(struct pt_regs *regs, unsigned long pc,
}
#ifdef CONFIG_COMPAT
+static bool compat_mode_support __read_mostly = false;
+
+bool compat_elf_check_arch(Elf32_Ehdr *hdr)
+{
+ if (compat_mode_support && (hdr->e_machine == EM_RISCV))
+ return true;
+
+ return false;
+}
+
+void compat_mode_detect(void)
+{
+ unsigned long tmp = csr_read(CSR_STATUS);
+ csr_write(CSR_STATUS, (tmp & ~SR_UXL) | SR_UXL_32);
+
+ if ((csr_read(CSR_STATUS) & SR_UXL) != SR_UXL_32) {
+ csr_write(CSR_STATUS, tmp);
+ return;
+ }
+
+ csr_write(CSR_STATUS, tmp);
+ compat_mode_support = true;
+
+ pr_info("riscv: compat: 32bit U-mode applications support\n");
+}
+
void compat_start_thread(struct pt_regs *regs, unsigned long pc,
unsigned long sp)
{
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index b42bfdc67482..be131219d549 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -12,6 +12,7 @@
#include <linux/mm.h>
#include <linux/memblock.h>
#include <linux/sched.h>
+#include <linux/compat.h>
#include <linux/console.h>
#include <linux/screen_info.h>
#include <linux/of_fdt.h>
@@ -294,6 +295,10 @@ void __init setup_arch(char **cmdline_p)
setup_smp();
#endif
+#ifdef CONFIG_COMPAT
+ compat_mode_detect();
+#endif
+
riscv_fill_hwcap();
}
On Tue, Feb 1, 2022 at 5:36 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Feb 1, 2022 at 10:13 AM Guo Ren <guoren@kernel.org> wrote:
> > On Tue, Feb 1, 2022 at 3:45 PM Christoph Hellwig <hch@lst.de> wrote:
> > > On Mon, Jan 31, 2022 at 09:50:58PM +0800, Guo Ren wrote:
> > > > On Mon, Jan 31, 2022 at 8:26 PM Christoph Hellwig <hch@infradead.org> wrote:
> > > > >
> > > > > Given that most rv64 implementations can't run in rv32 mode, what is the
> > > > > failure mode if someone tries it with the compat mode enabled?
> > > > A static linked simple hello_world could still run on a non-compat
> > > > support hardware. But most rv32 apps would meet different userspace
> > > > segment faults.
> > > >
> > > > Current code would let the machine try the rv32 apps without detecting
> > > > whether hw support or not.
> > >
> > > Hmm, we probably want some kind of check for not even offer running
> > > rv32 binaries. I guess trying to write UXL some time during early
> > > boot and catching the resulting exception would be the way to go?
> >
> > Emm... I think it's unnecessary. Free rv32 app running won't cause
> > system problem, just as a wrong elf running. They are U-mode
> > privileged.
>
> While it's not a security issue, I think it would be helpful to get a
> user-readable error message and a machine-readable /proc/cpuinfo
> flag to see if a particular system can run rv32 binaries rather than
> relying on SIGILL to kill a process.
--
2.25.1
>
> Arnd
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox