Date: Thu, 8 Nov 2018 22:12:31 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Ed Schouten <ed@nuxi.nl>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r340231 - head/sys/kern Message-ID: <20181108201231.GA5335@kib.kiev.ua> In-Reply-To: <60a839f8-9830-7d6e-98a2-a7aa596e68e9@FreeBSD.org> References: <201811071832.wA7IW3VI045865@repo.freebsd.org> <CABh_MKm_g%2BZ6m2LQWjEDcQZdki6JeVLJ%2BZ-q3Y=EaxaJm7DHjQ@mail.gmail.com> <081a4dfe-c95e-f8f1-ffc6-04ed5173999d@FreeBSD.org> <20181107230832.GZ5335@kib.kiev.ua> <60a839f8-9830-7d6e-98a2-a7aa596e68e9@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181108201231.GA5335>