From owner-svn-src-all@freebsd.org Thu Nov 8 20:12:43 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95B9D1103BF8; Thu, 8 Nov 2018 20:12:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD75D6A25D; Thu, 8 Nov 2018 20:12:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id wA8KCVhh075820 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Nov 2018 22:12:34 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua wA8KCVhh075820 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id wA8KCVPo075819; Thu, 8 Nov 2018 22:12:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 8 Nov 2018 22:12:31 +0200 From: Konstantin Belousov To: John Baldwin Cc: Ed Schouten , src-committers , 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> References: <201811071832.wA7IW3VI045865@repo.freebsd.org> <081a4dfe-c95e-f8f1-ffc6-04ed5173999d@FreeBSD.org> <20181107230832.GZ5335@kib.kiev.ua> <60a839f8-9830-7d6e-98a2-a7aa596e68e9@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60a839f8-9830-7d6e-98a2-a7aa596e68e9@FreeBSD.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: BD75D6A25D X-Spamd-Result: default: False [-5.02 / 200.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.99)[-0.994,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-2.02)[ip: (-1.99), ipnet: 2001:470::/32(-4.48), asn: 6939(-3.54), country: US(-0.09)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 20:12:43 -0000 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 : > >>>> 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).