@@ -2,6 +2,18 @@#ifndef __ASM_GENERIC_COMPAT_H#define __ASM_GENERIC_COMPAT_H+#ifndef COMPAT_USER_HZ+#define COMPAT_USER_HZ 100+#endif++#ifndef COMPAT_RLIM_INFINITY+#define COMPAT_RLIM_INFINITY 0xffffffff+#endif++#ifndef COMPAT_OFF_T_MAX+#define COMPAT_OFF_T_MAX 0x7fffffff+#endif+/* These types are common across all compat ABIs */typedefu32compat_size_t;typedefs32compat_ssize_t;
From: Guo Ren <redacted>
Make "uapi asm unistd.h" could be used for architectures' COMPAT
mode. The __SYSCALL_COMPAT is first used in riscv.
Signed-off-by: Guo Ren <redacted>
Signed-off-by: Guo Ren <guoren@kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
include/uapi/asm-generic/unistd.h | 4 ++--
tools/include/uapi/asm-generic/unistd.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
@@ -1,135 +0,0 @@-CONFIG_SYSVIPC=y-CONFIG_POSIX_MQUEUE=y-CONFIG_NO_HZ_IDLE=y-CONFIG_HIGH_RES_TIMERS=y-CONFIG_BPF_SYSCALL=y-CONFIG_IKCONFIG=y-CONFIG_IKCONFIG_PROC=y-CONFIG_CGROUPS=y-CONFIG_CGROUP_SCHED=y-CONFIG_CFS_BANDWIDTH=y-CONFIG_CGROUP_BPF=y-CONFIG_NAMESPACES=y-CONFIG_USER_NS=y-CONFIG_CHECKPOINT_RESTORE=y-CONFIG_BLK_DEV_INITRD=y-CONFIG_EXPERT=y-# CONFIG_SYSFS_SYSCALL is not set-CONFIG_SOC_SIFIVE=y-CONFIG_SOC_VIRT=y-CONFIG_ARCH_RV32I=y-CONFIG_SMP=y-CONFIG_HOTPLUG_CPU=y-CONFIG_VIRTUALIZATION=y-CONFIG_KVM=m-CONFIG_JUMP_LABEL=y-CONFIG_MODULES=y-CONFIG_MODULE_UNLOAD=y-CONFIG_NET=y-CONFIG_PACKET=y-CONFIG_UNIX=y-CONFIG_INET=y-CONFIG_IP_MULTICAST=y-CONFIG_IP_ADVANCED_ROUTER=y-CONFIG_IP_PNP=y-CONFIG_IP_PNP_DHCP=y-CONFIG_IP_PNP_BOOTP=y-CONFIG_IP_PNP_RARP=y-CONFIG_NETLINK_DIAG=y-CONFIG_NET_9P=y-CONFIG_NET_9P_VIRTIO=y-CONFIG_PCI=y-CONFIG_PCIEPORTBUS=y-CONFIG_PCI_HOST_GENERIC=y-CONFIG_PCIE_XILINX=y-CONFIG_DEVTMPFS=y-CONFIG_DEVTMPFS_MOUNT=y-CONFIG_BLK_DEV_LOOP=y-CONFIG_VIRTIO_BLK=y-CONFIG_BLK_DEV_SD=y-CONFIG_BLK_DEV_SR=y-CONFIG_SCSI_VIRTIO=y-CONFIG_ATA=y-CONFIG_SATA_AHCI=y-CONFIG_SATA_AHCI_PLATFORM=y-CONFIG_NETDEVICES=y-CONFIG_VIRTIO_NET=y-CONFIG_MACB=y-CONFIG_E1000E=y-CONFIG_R8169=y-CONFIG_MICROSEMI_PHY=y-CONFIG_INPUT_MOUSEDEV=y-CONFIG_SERIAL_8250=y-CONFIG_SERIAL_8250_CONSOLE=y-CONFIG_SERIAL_OF_PLATFORM=y-CONFIG_SERIAL_EARLYCON_RISCV_SBI=y-CONFIG_HVC_RISCV_SBI=y-CONFIG_VIRTIO_CONSOLE=y-CONFIG_HW_RANDOM=y-CONFIG_HW_RANDOM_VIRTIO=y-CONFIG_SPI=y-CONFIG_SPI_SIFIVE=y-# CONFIG_PTP_1588_CLOCK is not set-CONFIG_DRM=y-CONFIG_DRM_RADEON=y-CONFIG_DRM_VIRTIO_GPU=y-CONFIG_FB=y-CONFIG_FRAMEBUFFER_CONSOLE=y-CONFIG_USB=y-CONFIG_USB_XHCI_HCD=y-CONFIG_USB_XHCI_PLATFORM=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_UAS=y-CONFIG_MMC=y-CONFIG_MMC_SPI=y-CONFIG_RTC_CLASS=y-CONFIG_VIRTIO_PCI=y-CONFIG_VIRTIO_BALLOON=y-CONFIG_VIRTIO_INPUT=y-CONFIG_VIRTIO_MMIO=y-CONFIG_RPMSG_CHAR=y-CONFIG_RPMSG_VIRTIO=y-CONFIG_EXT4_FS=y-CONFIG_EXT4_FS_POSIX_ACL=y-CONFIG_AUTOFS4_FS=y-CONFIG_MSDOS_FS=y-CONFIG_VFAT_FS=y-CONFIG_TMPFS=y-CONFIG_TMPFS_POSIX_ACL=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_CRYPTO_USER_API_HASH=y-CONFIG_CRYPTO_DEV_VIRTIO=y-CONFIG_PRINTK_TIME=y-CONFIG_DEBUG_FS=y-CONFIG_DEBUG_PAGEALLOC=y-CONFIG_SCHED_STACK_END_CHECK=y-CONFIG_DEBUG_VM=y-CONFIG_DEBUG_VM_PGFLAGS=y-CONFIG_DEBUG_MEMORY_INIT=y-CONFIG_DEBUG_PER_CPU_MAPS=y-CONFIG_SOFTLOCKUP_DETECTOR=y-CONFIG_WQ_WATCHDOG=y-CONFIG_DEBUG_TIMEKEEPING=y-CONFIG_DEBUG_RT_MUTEXES=y-CONFIG_DEBUG_SPINLOCK=y-CONFIG_DEBUG_MUTEXES=y-CONFIG_DEBUG_RWSEMS=y-CONFIG_DEBUG_ATOMIC_SLEEP=y-CONFIG_STACKTRACE=y-CONFIG_DEBUG_LIST=y-CONFIG_DEBUG_PLIST=y-CONFIG_DEBUG_SG=y-# CONFIG_RCU_TRACE is not set-CONFIG_RCU_EQS_DEBUG=y-# CONFIG_FTRACE is not set-# CONFIG_RUNTIME_TESTING_MENU is not set-CONFIG_MEMTEST=y
From: Guo Ren <redacted>
Make TASK_SIZE from const to dynamic detect TIF_32BIT flag
function. Refer to arm64 to implement DEFAULT_MAP_WINDOW_64 for
efi-stub.
Limit 32-bit compatible process in 0-2GB virtual address range
(which is enough for real scenarios), because it could avoid
address sign extend problem when 32-bit enter 64-bit and ease
software design.
The standard 32-bit TASK_SIZE is 0x9dc00000:FIXADDR_START, and
compared to a compatible 32-bit, it increases 476MB for the
application's virtual address.
Signed-off-by: Guo Ren <redacted>
Signed-off-by: Guo Ren <guoren@kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
arch/riscv/include/asm/pgtable.h | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
From: Guo Ren <redacted>
If the current task is in COMPAT mode, set SR_UXL_32 in status for
returning userspace. We need CONFIG _COMPAT to prevent compiling
errors with rv32 defconfig.
Signed-off-by: Guo Ren <redacted>
Signed-off-by: Guo Ren <guoren@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
---
arch/riscv/kernel/process.c | 5 +++++
1 file changed, 5 insertions(+)
@@ -16,6 +16,7 @@/* The array of function pointers for syscalls. */externvoid*constsys_call_table[];+externvoid*constcompat_sys_call_table[];/**Onlythelow32bitsoforig_r0aremeaningful,sowereturnint.
@@ -367,6 +367,15 @@ SYSCALL_DEFINE4(sync_file_range, int, fd, loff_t, offset, loff_t, nbytes,returnksys_sync_file_range(fd,offset,nbytes,flags);}+#if defined(CONFIG_COMPAT) && defined(__ARCH_WANT_COMPAT_SYNC_FILE_RANGE)+COMPAT_SYSCALL_DEFINE6(sync_file_range,int,fd,compat_arg_u64_dual(offset),+compat_arg_u64_dual(nbytes),unsignedint,flags)+{+returnksys_sync_file_range(fd,compat_arg_u64_glue(offset),+compat_arg_u64_glue(nbytes),flags);+}+#endif+/* It would be nice if people remember that not all the world's an i386whentheyintroducenewsystemcalls*/SYSCALL_DEFINE4(sync_file_range2,int,fd,unsignedint,flags,
@@ -0,0 +1,68 @@+# SPDX-License-Identifier: GPL-2.0-only++# Absolute relocation type $(ARCH_REL_TYPE_ABS) needs to be defined before+# the inclusion of generic Makefile.+ARCH_REL_TYPE_ABS:=R_RISCV_32|R_RISCV_64|R_RISCV_JUMP_SLOT+include $(srctree)/lib/vdso/Makefile+# Symbols present in the compat_vdso+compat_vdso-syms=rt_sigreturn+compat_vdso-syms+=getcpu+compat_vdso-syms+=flush_icache++# Files to link into the compat_vdso+obj-compat_vdso=$(patsubst%,%.o,$(compat_vdso-syms))note.o++ccflags-y:=-fno-stack-protector++# Build rules+targets:=$(obj-compat_vdso)compat_vdso.socompat_vdso.so.dbgcompat_vdso.lds+obj-compat_vdso:=$(addprefix$(obj)/,$(obj-compat_vdso))++obj-y+=compat_vdso.o+CPPFLAGS_compat_vdso.lds+=-P-C-U$(ARCH)++# Disable profiling and instrumentation for VDSO code+GCOV_PROFILE:=n+KCOV_INSTRUMENT:=n+KASAN_SANITIZE:=n+UBSAN_SANITIZE:=n++# Force dependency+$(obj)/compat_vdso.o:$(obj)/compat_vdso.so++# link rule for the .so file, .lds has to be first+$(obj)/compat_vdso.so.dbg:$(obj)/compat_vdso.lds$(obj-compat_vdso)FORCE+$(callif_changed,compat_vdsold)+LDFLAGS_compat_vdso.so.dbg=-shared-S-soname=linux-compat_vdso.so.1\+--build-id=sha1--hash-style=both--eh-frame-hdr++# strip rule for the .so file+$(obj)/%.so:OBJCOPYFLAGS := -S+$(obj)/%.so:$(obj)/%.so.dbgFORCE+$(callif_changed,objcopy)++# Generate VDSO offsets using helper script+gen-compat_vdsosym:=$(srctree)/$(src)/gen_compat_vdso_offsets.sh+quiet_cmd_compat_vdsosym=VDSOSYM$@+cmd_compat_vdsosym=$(NM)$<|$(gen-compat_vdsosym)|LC_ALL=Csort>$@++include/generated/compat_vdso-offsets.h:$(obj)/compat_vdso.so.dbgFORCE+$(callif_changed,compat_vdsosym)++# actual build commands+# The DSO images are built using a special linker script+# Make sure only to export the intended __compat_vdso_xxx symbol offsets.+quiet_cmd_compat_vdsold=VDSOLD$@+cmd_compat_vdsold=$(LD)$(ld_flags)-T$(filter-outFORCE,$^)-o$@.tmp&&\+$(OBJCOPY)$(patsubst%,-G__compat_vdso_%,$(compat_vdso-syms))$@.tmp$@&&\+rm$@.tmp++# install commands for the unstripped file+quiet_cmd_compat_vdso_install=INSTALL$@+cmd_compat_vdso_install=cp$(obj)/$@.dbg$(MODLIB)/compat_vdso/$@++compat_vdso.so:$(obj)/compat_vdso.so.dbg+@mkdir-p$(MODLIB)/compat_vdso+$(callcmd,compat_vdso_install)++compat_vdso_install:compat_vdso.so
@@ -16,6 +16,7 @@ typedef struct {atomic_long_tid;#endifvoid*vdso;+void*vdso_info;#ifdef CONFIG_SMP/* A local icache flush is needed before user execution can resume. */cpumask_ticache_stale_mask;
@@ -66,35 +68,35 @@ static int vdso_mremap(const struct vm_special_mapping *sm,return0;}-staticint__init__vdso_init(void)+staticint__init__vdso_init(struct__vdso_info*vdso_info){unsignedinti;structpage**vdso_pagelist;unsignedlongpfn;-if(memcmp(vdso_info.vdso_code_start,"\177ELF",4)){+if(memcmp(vdso_info->vdso_code_start,"\177ELF",4)){pr_err("vDSO is not a valid ELF object!\n");return-EINVAL;}-vdso_info.vdso_pages=(-vdso_info.vdso_code_end--vdso_info.vdso_code_start)>>+vdso_info->vdso_pages=(+vdso_info->vdso_code_end-+vdso_info->vdso_code_start)>>PAGE_SHIFT;-vdso_pagelist=kcalloc(vdso_info.vdso_pages,+vdso_pagelist=kcalloc(vdso_info->vdso_pages,sizeof(structpage*),GFP_KERNEL);if(vdso_pagelist==NULL)return-ENOMEM;/* Grab the vDSO code pages. */-pfn=sym_to_pfn(vdso_info.vdso_code_start);+pfn=sym_to_pfn(vdso_info->vdso_code_start);-for(i=0;i<vdso_info.vdso_pages;i++)+for(i=0;i<vdso_info->vdso_pages;i++)vdso_pagelist[i]=pfn_to_page(pfn+i);-vdso_info.cm->pages=vdso_pagelist;+vdso_info->cm->pages=vdso_pagelist;return0;}
@@ -203,25 +201,53 @@ static struct vm_special_mapping rv_vdso_maps[] __ro_after_init = {},};+staticstruct__vdso_infovdso_info__ro_after_init={+.name="vdso",+.vdso_code_start=vdso_start,+.vdso_code_end=vdso_end,+.dm=&rv_vdso_maps[RV_VDSO_MAP_VVAR],+.cm=&rv_vdso_maps[RV_VDSO_MAP_VDSO],+};++#ifdef CONFIG_COMPAT+staticstruct__vdso_infocompat_vdso_info__ro_after_init={+.name="compat_vdso",+.vdso_code_start=compat_vdso_start,+.vdso_code_end=compat_vdso_end,+.dm=&rv_vdso_maps[RV_VDSO_MAP_VVAR],+.cm=&rv_vdso_maps[RV_VDSO_MAP_VDSO],+};+#endif+staticint__initvdso_init(void){-vdso_info.dm=&rv_vdso_maps[RV_VDSO_MAP_VVAR];-vdso_info.cm=&rv_vdso_maps[RV_VDSO_MAP_VDSO];+intret;++ret=__vdso_init(&vdso_info);+if(ret)+gotoout;-return__vdso_init();+#ifdef CONFIG_COMPAT+ret=__vdso_init(&compat_vdso_info);+if(ret)+gotoout;+#endif+out:+returnret;}arch_initcall(vdso_init);staticint__setup_additional_pages(structmm_struct*mm,structlinux_binprm*bprm,-intuses_interp)+intuses_interp,+struct__vdso_info*vdso_info){unsignedlongvdso_base,vdso_text_len,vdso_mapping_len;void*ret;BUILD_BUG_ON(VVAR_NR_PAGES!=__VVAR_PAGES);-vdso_text_len=vdso_info.vdso_pages<<PAGE_SHIFT;+vdso_text_len=vdso_info->vdso_pages<<PAGE_SHIFT;/* Be sure to map the data page */vdso_mapping_len=vdso_text_len+VVAR_SIZE;
@@ -232,16 +258,18 @@ static int __setup_additional_pages(struct mm_struct *mm,}ret=_install_special_mapping(mm,vdso_base,VVAR_SIZE,-(VM_READ|VM_MAYREAD|VM_PFNMAP),vdso_info.dm);+(VM_READ|VM_MAYREAD|VM_PFNMAP),vdso_info->dm);if(IS_ERR(ret))gotoup_fail;vdso_base+=VVAR_SIZE;mm->context.vdso=(void*)vdso_base;+mm->context.vdso_info=(void*)vdso_info;+ret=_install_special_mapping(mm,vdso_base,vdso_text_len,(VM_READ|VM_EXEC|VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC),-vdso_info.cm);+vdso_info->cm);if(IS_ERR(ret))gotoup_fail;
@@ -253,6 +281,24 @@ static int __setup_additional_pages(struct mm_struct *mm,returnPTR_ERR(ret);}+#ifdef CONFIG_COMPAT+intcompat_arch_setup_additional_pages(structlinux_binprm*bprm,+intuses_interp)+{+structmm_struct*mm=current->mm;+intret;++if(mmap_write_lock_killable(mm))+return-EINTR;++ret=__setup_additional_pages(mm,bprm,uses_interp,+&compat_vdso_info);+mmap_write_unlock(mm);++returnret;+}+#endif+intarch_setup_additional_pages(structlinux_binprm*bprm,intuses_interp){structmm_struct*mm=current->mm;
@@ -261,7 +307,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)if(mmap_write_lock_killable(mm))return-EINTR;-ret=__setup_additional_pages(mm,bprm,uses_interp);+ret=__setup_additional_pages(mm,bprm,uses_interp,&vdso_info);mmap_write_unlock(mm);returnret;
From: Guo Ren <redacted>
Implement compat_setup_rt_frame for sigcontext save & restore. The
main process is the same with signal, but the rv32 pt_regs' size
is different from rv64's, so we needs convert them.
Signed-off-by: Guo Ren <redacted>
Signed-off-by: Guo Ren <guoren@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
---
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/compat_signal.c | 243 ++++++++++++++++++++++++++++++
arch/riscv/kernel/signal.c | 13 +-
3 files changed, 256 insertions(+), 1 deletion(-)
create mode 100644 arch/riscv/kernel/compat_signal.c
@@ -0,0 +1,243 @@+// SPDX-License-Identifier: GPL-2.0-or-later++#include<linux/compat.h>+#include<linux/signal.h>+#include<linux/uaccess.h>+#include<linux/syscalls.h>+#include<linux/tracehook.h>+#include<linux/linkage.h>++#include<asm/ucontext.h>+#include<asm/vdso.h>+#include<asm/switch_to.h>+#include<asm/csr.h>++#define COMPAT_DEBUG_SIG 0++structcompat_sigcontext{+structcompat_user_regs_structsc_regs;+union__riscv_fp_statesc_fpregs;+};++structcompat_ucontext{+compat_ulong_tuc_flags;+structcompat_ucontext*uc_link;+compat_stack_tuc_stack;+sigset_tuc_sigmask;+/* There's some padding here to allow sigset_t to be expanded in the+*future.Thoughthisisunlikely,otherarchitecturesputuc_sigmask+*attheendofthisstructureandexplicitlystateitcanbe+*expanded,sowedidn'twanttoboxourselvesinhere.*/+__u8__unused[1024/8-sizeof(sigset_t)];+/* We can't put uc_sigmask at the end of this structure because we need+*tobeabletoexpandsigcontextinthefuture.Forexample,the+*vectorISAextensionwillalmostcertainlyaddISAstate.Wewant+*toensurealluser-visibleISAstatecanbesavedandrestoredviaa+*ucontext,sowe'reputtingthisattheendinordertoallowfor+*infiniteextensibility.Sinceweknowthiswillbeextendedandwe+*assumesigset_twon'tbeextendedanextremeamount,we're+*prioritizingthis.*/+structcompat_sigcontextuc_mcontext;+};++structcompat_rt_sigframe{+structcompat_siginfoinfo;+structcompat_ucontextuc;+};++#ifdef CONFIG_FPU+staticlongcompat_restore_fp_state(structpt_regs*regs,+union__riscv_fp_state__user*sc_fpregs)+{+longerr;+struct__riscv_d_ext_state__user*state=&sc_fpregs->d;+size_ti;++err=__copy_from_user(¤t->thread.fstate,state,sizeof(*state));+if(unlikely(err))+returnerr;++fstate_restore(current,regs);++/* We support no other extension state at this time. */+for(i=0;i<ARRAY_SIZE(sc_fpregs->q.reserved);i++){+u32value;++err=__get_user(value,&sc_fpregs->q.reserved[i]);+if(unlikely(err))+break;+if(value!=0)+return-EINVAL;+}++returnerr;+}++staticlongcompat_save_fp_state(structpt_regs*regs,+union__riscv_fp_state__user*sc_fpregs)+{+longerr;+struct__riscv_d_ext_state__user*state=&sc_fpregs->d;+size_ti;++fstate_save(current,regs);+err=__copy_to_user(state,¤t->thread.fstate,sizeof(*state));+if(unlikely(err))+returnerr;++/* We support no other extension state at this time. */+for(i=0;i<ARRAY_SIZE(sc_fpregs->q.reserved);i++){+err=__put_user(0,&sc_fpregs->q.reserved[i]);+if(unlikely(err))+break;+}++returnerr;+}+#else+#define compat_save_fp_state(task, regs) (0)+#define compat_restore_fp_state(task, regs) (0)+#endif++staticlongcompat_restore_sigcontext(structpt_regs*regs,+structcompat_sigcontext__user*sc)+{+longerr;+structcompat_user_regs_structcregs;++/* sc_regs is structured the same as the start of pt_regs */+err=__copy_from_user(&cregs,&sc->sc_regs,sizeof(sc->sc_regs));++cregs_to_regs(&cregs,regs);++/* Restore the floating-point state. */+if(has_fpu())+err|=compat_restore_fp_state(regs,&sc->sc_fpregs);+returnerr;+}++COMPAT_SYSCALL_DEFINE0(rt_sigreturn)+{+structpt_regs*regs=current_pt_regs();+structcompat_rt_sigframe__user*frame;+structtask_struct*task;+sigset_tset;++/* Always make any pending restarted system calls return -EINTR */+current->restart_block.fn=do_no_restart_syscall;++frame=(structcompat_rt_sigframe__user*)regs->sp;++if(!access_ok(frame,sizeof(*frame)))+gotobadframe;++if(__copy_from_user(&set,&frame->uc.uc_sigmask,sizeof(set)))+gotobadframe;++set_current_blocked(&set);++if(compat_restore_sigcontext(regs,&frame->uc.uc_mcontext))+gotobadframe;++if(compat_restore_altstack(&frame->uc.uc_stack))+gotobadframe;++returnregs->a0;++badframe:+task=current;+if(show_unhandled_signals){+pr_info_ratelimited(+"%s[%d]: bad frame in %s: frame=%p pc=%p sp=%p\n",+task->comm,task_pid_nr(task),__func__,+frame,(void*)regs->epc,(void*)regs->sp);+}+force_sig(SIGSEGV);+return0;+}++staticlongcompat_setup_sigcontext(structcompat_rt_sigframe__user*frame,+structpt_regs*regs)+{+structcompat_sigcontext__user*sc=&frame->uc.uc_mcontext;+structcompat_user_regs_structcregs;+longerr;++regs_to_cregs(&cregs,regs);++/* sc_regs is structured the same as the start of pt_regs */+err=__copy_to_user(&sc->sc_regs,&cregs,sizeof(sc->sc_regs));+/* Save the floating-point state. */+if(has_fpu())+err|=compat_save_fp_state(regs,&sc->sc_fpregs);+returnerr;+}++staticinlinevoid__user*compat_get_sigframe(structksignal*ksig,+structpt_regs*regs,size_tframesize)+{+unsignedlongsp;+/* Default to using normal stack */+sp=regs->sp;++/*+*Ifweareonthealternatesignalstackandwouldoverflowit,don't.+*Returnanalways-bogusaddressinsteadsowewilldiewithSIGSEGV.+*/+if(on_sig_stack(sp)&&!likely(on_sig_stack(sp-framesize)))+return(void__user__force*)(-1UL);++/* This is the X/Open sanctioned signal stack switching. */+sp=sigsp(sp,ksig)-framesize;++/* Align the stack frame. */+sp&=~0xfUL;++return(void__user*)sp;+}++intcompat_setup_rt_frame(structksignal*ksig,sigset_t*set,+structpt_regs*regs)+{+structcompat_rt_sigframe__user*frame;+longerr=0;++frame=compat_get_sigframe(ksig,regs,sizeof(*frame));+if(!access_ok(frame,sizeof(*frame)))+return-EFAULT;++err|=copy_siginfo_to_user32(&frame->info,&ksig->info);++/* Create the ucontext. */+err|=__put_user(0,&frame->uc.uc_flags);+err|=__put_user(NULL,&frame->uc.uc_link);+err|=__compat_save_altstack(&frame->uc.uc_stack,regs->sp);+err|=compat_setup_sigcontext(frame,regs);+err|=__copy_to_user(&frame->uc.uc_sigmask,set,sizeof(*set));+if(err)+return-EFAULT;++regs->ra=(unsignedlong)COMPAT_VDSO_SYMBOL(+current->mm->context.vdso,rt_sigreturn);++/*+*Setupregistersforsignalhandler.+*Registersthatwedon'tmodifykeepthevaluetheyhadfrom+*user-spaceatthetimewetookthesignal.+*Wealwayspasssiginfoandmcontext,regardlessofSA_SIGINFO,+*sincesomethingsrelyonthis(e.g.glibc'sdebug/segfault.c).+*/+regs->epc=(unsignedlong)ksig->ka.sa.sa_handler;+regs->sp=(unsignedlong)frame;+regs->a0=ksig->sig;/* a0: signal number */+regs->a1=(unsignedlong)(&frame->info);/* a1: siginfo pointer */+regs->a2=(unsignedlong)(&frame->uc);/* a2: ucontext pointer */++#if COMPAT_DEBUG_SIG+pr_info("SIG deliver (%s:%d): sig=%d pc=%p ra=%p sp=%p\n",+current->comm,task_pid_nr(current),ksig->sig,+(void*)regs->epc,(void*)regs->ra,frame);+#endif++return0;+}
@@ -123,12 +124,18 @@ config ARCH_MMAP_RND_BITS_MINdefault18if64BITdefault8+configARCH_MMAP_RND_COMPAT_BITS_MIN+default8+# max bits determined by the following formula:# VA_BITS - PAGE_SHIFT - 3configARCH_MMAP_RND_BITS_MAXdefault24if64BIT# SV39 baseddefault17+configARCH_MMAP_RND_COMPAT_BITS_MAX+default17+# set if we run in machine mode, cleared if we run in supervisor modeconfigRISCV_M_MODEbool
@@ -406,6 +413,18 @@ config CRASH_DUMPFormoredetailsseeDocumentation/admin-guide/kdump/kdump.rst+configCOMPAT+bool"Kernel support for 32-bit U-mode"+default64BIT+depends on64BIT&&MMU+help+Thisoptionenablessupportfora32-bitU-moderunningundera64-bit+kernelatS-mode.riscv32-specificcomponentssuchassystemcalls,+theuserhelperfunctions(vdso),signalrt_framefunctionsandthe+ptraceinterfacearehandledappropriatelybythekernel.++Ifyouwanttoexecute32-bituserspaceapplications,sayY.+endmenumenu"Boot options"
These now come from the generic definitions I think. The flock definitions
are just the normal ones, and AFAICT the RLIM_INIFINITY definition here
is actually wrong and should be the default 0xffffffffu to match the
native (~0UL) definition.
Arnd
I would make these endian-specific, and reverse them on big-endian
architectures. That way it
should be possible to share them across all compat architectures
without needing the override
option.
Arnd
I would make these endian-specific, and reverse them on big-endian
architectures. That way it
should be possible to share them across all compat architectures
without needing the override
option.
I hope it could be another patch. Because it's not clear to
_LITTLE_ENDIAN definition in archs.
eg: Names could be __ORDER_LITTLE_ENDIAN__ CPU_LITTLE_ENDIAN
SYS_SUPPORTS_LITTLE_ENDIAN __LITTLE_ENDIAN
riscv is little-endian, but no any LITTLE_ENDIAN definition.
So let's keep them in the patch, first, Thx
On Sun, Jan 30, 2022 at 6:54 AM Guo Ren [off-list ref] wrote:
On Sun, Jan 30, 2022 at 6:41 AM Arnd Bergmann [off-list ref] wrote:
quoted
I would make these endian-specific, and reverse them on big-endian
architectures. That way it
should be possible to share them across all compat architectures
without needing the override
option.
I hope it could be another patch. Because it's not clear to
_LITTLE_ENDIAN definition in archs.
eg: Names could be __ORDER_LITTLE_ENDIAN__ CPU_LITTLE_ENDIAN
SYS_SUPPORTS_LITTLE_ENDIAN __LITTLE_ENDIAN
riscv is little-endian, but no any LITTLE_ENDIAN definition.
So let's keep them in the patch, first, Thx
The correct way to do it is to check for CONFIG_CPU_BIG_ENDIAN,
which works on all architectures. Since nothing else selects the
__ARCH_WANT_COMPAT_* symbols, there is also no risk for
regressions, so just use this and leave the #ifndef compat_arg_u64
check in place.
Arnd
These now come from the generic definitions I think. The flock definitions
are just the normal ones,
Yes, it could be removed after Christoph Hellwig's patch merged.
Rgiht, I keep forgetting that this is a separate series, so this is fine.
quoted
and AFAICT the RLIM_INIFINITY definition here
is actually wrong and should be the default 0xffffffffu to match the
native (~0UL) definition.
Yes, native rv32 used ~0UL, although its task_size is only 2.4GB.
The rlimit range has very little to do with the virtual memory address
limits, it is used for a number of other things that are typically more
limited in practice.
I would remove #define COMPAT_RLIM_INFINITY 0x7fffffff
On Sun, Jan 30, 2022 at 7:32 PM Arnd Bergmann [off-list ref] wrote:
On Sun, Jan 30, 2022 at 6:54 AM Guo Ren [off-list ref] wrote:
quoted
On Sun, Jan 30, 2022 at 6:41 AM Arnd Bergmann [off-list ref] wrote:
quoted
I would make these endian-specific, and reverse them on big-endian
architectures. That way it
should be possible to share them across all compat architectures
without needing the override
option.
I hope it could be another patch. Because it's not clear to
_LITTLE_ENDIAN definition in archs.
eg: Names could be __ORDER_LITTLE_ENDIAN__ CPU_LITTLE_ENDIAN
SYS_SUPPORTS_LITTLE_ENDIAN __LITTLE_ENDIAN
riscv is little-endian, but no any LITTLE_ENDIAN definition.
So let's keep them in the patch, first, Thx
The correct way to do it is to check for CONFIG_CPU_BIG_ENDIAN,
which works on all architectures. Since nothing else selects the
__ARCH_WANT_COMPAT_* symbols, there is also no risk for
regressions, so just use this and leave the #ifndef compat_arg_u64
check in place.
From: Christoph Hellwig <hch@infradead.org> Date: 2022-01-31 12:21:37
On Sat, Jan 29, 2022 at 08:17:14PM +0800, guoren@kernel.org wrote:
From: Guo Ren <redacted>
There are 7 64bit architectures that support Linux COMPAT mode to
run 32bit applications. A lot of definitions are duplicate:
- COMPAT_USER_HZ
- COMPAT_RLIM_INFINITY
- COMPAT_OFF_T_MAX
- __compat_uid_t, __compat_uid_t
- compat_dev_t
- compat_ipc_pid_t
- struct compat_flock
- struct compat_flock64
- struct compat_statfs
- struct compat_ipc64_perm, compat_semid64_ds,
compat_msqid64_ds, compat_shmid64_ds
Cleanup duplicate definitions and merge them into asm-generic.
The flock part seems to clash with the general compat_flock
consolidation. Otherwise this looks like a good idea.
From: Christoph Hellwig <hch@infradead.org> Date: 2022-01-31 12:22:04
On Sat, Jan 29, 2022 at 08:17:15PM +0800, guoren@kernel.org wrote:
From: Guo Ren <redacted>
Make "uapi asm unistd.h" could be used for architectures' COMPAT
mode. The __SYSCALL_COMPAT is first used in riscv.
Signed-off-by: Guo Ren <redacted>
Signed-off-by: Guo Ren <guoren@kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
From: Christoph Hellwig <hch@infradead.org> Date: 2022-01-31 12:23:14
On Sat, Jan 29, 2022 at 08:17:16PM +0800, guoren@kernel.org wrote:
From: Guo Ren <redacted>
Let's follow the origin patch's spirit:
The only difference between rv32_defconfig and defconfig is that
rv32_defconfig has CONFIG_ARCH_RV32I=y.
This is helpful to compare rv64-compat-rv32 v.s. rv32-linux.
Fixes: 1b937e8faa87ccfb ("RISC-V: Add separate defconfig for 32bit systems")
Signed-off-by: Guo Ren <redacted>
Signed-off-by: Guo Ren <guoren@kernel.org>
Wouldn't a common.config that generats both the 32-bit and 64-bit
configs a better idea?
On Mon, Jan 31, 2022 at 1:23 PM Christoph Hellwig [off-list ref] wrote:
On Sat, Jan 29, 2022 at 08:17:16PM +0800, guoren@kernel.org wrote:
quoted
From: Guo Ren <redacted>
Let's follow the origin patch's spirit:
The only difference between rv32_defconfig and defconfig is that
rv32_defconfig has CONFIG_ARCH_RV32I=y.
This is helpful to compare rv64-compat-rv32 v.s. rv32-linux.
Fixes: 1b937e8faa87ccfb ("RISC-V: Add separate defconfig for 32bit systems")
Signed-off-by: Guo Ren <redacted>
Signed-off-by: Guo Ren <guoren@kernel.org>
Wouldn't a common.config that generats both the 32-bit and 64-bit
configs a better idea?
I thought that is what the patch does, there is already the normal 64-bit
defconfig, and the new makefile target makes this shared with 32-bit
to prevent them from diverging again.
Arnd
From: Christoph Hellwig <hch@infradead.org> Date: 2022-01-31 13:00:41
On Mon, Jan 31, 2022 at 01:48:58PM +0100, Arnd Bergmann wrote:
I thought that is what the patch does, there is already the normal 64-bit
defconfig, and the new makefile target makes this shared with 32-bit
to prevent them from diverging again.
I ment using a common fragment and the deriving both 32-bit and 64-bit
configs from it. The 64-bit specific fragment will be empty for now,
but we will sooner or later have an option that can only go into the
64-bit defconfig.
On Mon, Jan 31, 2022 at 2:00 PM Christoph Hellwig [off-list ref] wrote:
On Mon, Jan 31, 2022 at 01:48:58PM +0100, Arnd Bergmann wrote:
quoted
I thought that is what the patch does, there is already the normal 64-bit
defconfig, and the new makefile target makes this shared with 32-bit
to prevent them from diverging again.
I ment using a common fragment and the deriving both 32-bit and 64-bit
configs from it. The 64-bit specific fragment will be empty for now,
but we will sooner or later have an option that can only go into the
64-bit defconfig.
Ah right, that should work as well, not sure if it makes much of a difference.
I suggested this method because it is the same thing we do on powerpc.
Arnd
On Mon, Jan 31, 2022 at 8:26 PM Christoph Hellwig [off-list ref] 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.
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
On Mon, Jan 31, 2022 at 8:21 PM Christoph Hellwig [off-list ref] wrote:
On Sat, Jan 29, 2022 at 08:17:14PM +0800, guoren@kernel.org wrote:
quoted
From: Guo Ren <redacted>
There are 7 64bit architectures that support Linux COMPAT mode to
run 32bit applications. A lot of definitions are duplicate:
- COMPAT_USER_HZ
- COMPAT_RLIM_INFINITY
- COMPAT_OFF_T_MAX
- __compat_uid_t, __compat_uid_t
- compat_dev_t
- compat_ipc_pid_t
- struct compat_flock
- struct compat_flock64
- struct compat_statfs
- struct compat_ipc64_perm, compat_semid64_ds,
compat_msqid64_ds, compat_shmid64_ds
Cleanup duplicate definitions and merge them into asm-generic.
The flock part seems to clash with the general compat_flock
consolidation. Otherwise this looks like a good idea.
Okay, In the next version, I would rebase on general compat_flock
consolidation v4.
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
From: Christoph Hellwig <hch@lst.de> Date: 2022-02-01 07:45:05
On Mon, Jan 31, 2022 at 09:50:58PM +0800, Guo Ren wrote:
On Mon, Jan 31, 2022 at 8:26 PM Christoph Hellwig [off-list ref] wrote:
quoted
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?
On Tue, Feb 1, 2022 at 3:45 PM Christoph Hellwig [off-list ref] wrote:
On Mon, Jan 31, 2022 at 09:50:58PM +0800, Guo Ren wrote:
quoted
On Mon, Jan 31, 2022 at 8:26 PM Christoph Hellwig [off-list ref] wrote:
quoted
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.
On Tue, Feb 1, 2022 at 10:13 AM Guo Ren [off-list ref] wrote:
On Tue, Feb 1, 2022 at 3:45 PM Christoph Hellwig [off-list ref] wrote:
quoted
On Mon, Jan 31, 2022 at 09:50:58PM +0800, Guo Ren wrote:
quoted
On Mon, Jan 31, 2022 at 8:26 PM Christoph Hellwig [off-list ref] wrote:
quoted
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.
Arnd
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(-)
On Tue, Feb 1, 2022 at 5:36 PM Arnd Bergmann [off-list ref] wrote:
On Tue, Feb 1, 2022 at 10:13 AM Guo Ren [off-list ref] wrote:
quoted
On Tue, Feb 1, 2022 at 3:45 PM Christoph Hellwig [off-list ref] wrote:
quoted
On Mon, Jan 31, 2022 at 09:50:58PM +0800, Guo Ren wrote:
quoted
On Mon, Jan 31, 2022 at 8:26 PM Christoph Hellwig [off-list ref] wrote:
quoted
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.
On Tue, Feb 1, 2022 at 11:26 AM Guo Ren [off-list ref] 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
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
On Tue, Feb 1, 2022 at 7:48 PM Arnd Bergmann [off-list ref] wrote:
On Tue, Feb 1, 2022 at 11:26 AM Guo Ren [off-list ref] wrote:
quoted
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
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.