On Thu, Nov 08, 2018 at 11:49:28AM -0800, John Baldwin wrote: > On 11/7/18 3:08 PM, Konstantin Belousov wrote: > > On Wed, Nov 07, 2018 at 01:35:57PM -0800, John Baldwin wrote: > >> On 11/7/18 1:01 PM, Ed Schouten wrote: > >>> Op wo 7 nov. 2018 om 19:32 schreef John Baldwin <j...@freebsd.org>: > >>>> Modified: head/sys/kern/imgact_elf.c > >>>> ============================================================================== > >>>> --- head/sys/kern/imgact_elf.c Wed Nov 7 18:29:54 2018 (r340230) > >>>> +++ head/sys/kern/imgact_elf.c Wed Nov 7 18:32:02 2018 (r340231) > >>>> @@ -120,7 +120,8 @@ SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), > >>>> > >>>> int __elfN(nxstack) = > >>>> #if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit > >>>> */ || \ > >>>> - (defined(__arm__) && __ARM_ARCH >= 7) || defined(__aarch64__) > >>>> + (defined(__arm__) && __ARM_ARCH >= 7) || defined(__aarch64__) || \ > >>>> + defined(__riscv) > >>>> 1; > >>>> #else > >>>> 0; > >>> > >>> Are we getting to the point that it might make sense to invert this > >>> logic, i.e., just list the architectures that require executable > >>> stacks? > >> > >> It's not clear. The remaining set is i386 (should be able to use nxstack > >> when using PAE and PG_NX is supported), MIPS (no X permission in PTEs), > >> 32-bit powerpc (no X permissions in PTEs AFAICT), and sparc64 (no X > >> permissions in PTEs AFAICT). For architectures without X ptes, removing > >> VM_PROT_EXECUTE from the stack permissions is a no-op and would be > >> harmless, so we could perhaps just default this to always on at this > >> point? > > AFAIR sparc64 ABI defines its stack as nx always (and PTEs do allow to > > control exec permission). > > Hmm, I couldn't find any uses of VM_PROT_EXECUTE in pmap.c that seemed to > affect permissions. There is a software TTE bit that is used to know which > address ranges require icache flushing, but it seems to only be used for > that. AFAIR TLB faults are software-assisted and there are different faults for instruction and data TLB fill. It seems that exception.S immu_miss handler checks the TD_EXEC software bit before loading TTE into instructions TLB.
Later versions of sparcv9 arch specification define optional hw execute bit in TTE. > > Regardless, for the purposes of this sysctl, is there any reason we can't > just define it to 1 always now? It is only honored if the architecture > is using a shared page to hold the signal trampoline and only has an effect > if the pmap honors VM_PROT_EXECUTE. That would at least fix i386 with > PAE to DTRT I think. i386 PAE already handles it, see i386/initcpu.c:754. Unconditionally setting the vars to 1 would break any arch that 1. does not allow to use shared page 2. honors VM_PROT_EXEC in pmap 3. not using local hacks for signal trampolines, like sparc64 does. We might not have any such architecture now (ia64 certainly was such case). _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
