From owner-svn-src-all@freebsd.org Thu Nov 8 19:49:30 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 7ED2F1102D49; Thu, 8 Nov 2018 19:49:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 00E768F34C; Thu, 8 Nov 2018 19:49:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id DE1CA10AFD2; Thu, 8 Nov 2018 14:49:28 -0500 (EST) Subject: Re: svn commit: r340231 - head/sys/kern To: Konstantin Belousov References: <201811071832.wA7IW3VI045865@repo.freebsd.org> <081a4dfe-c95e-f8f1-ffc6-04ed5173999d@FreeBSD.org> <20181107230832.GZ5335@kib.kiev.ua> Cc: Ed Schouten , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= xsDiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg80eSm9obiBCYWxk d2luIDxqb2huQGJhbGR3aW4uY3g+wmMEExECACMCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIX gAUCRND5wwIZAQAKCRBy3lIGd+N/BNLXAJ9KIb6teuDL1W+FkCgvv+y8PxKTkACeIUfbn3sl cueBzqTcf09idwa8YTbOwU0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Ds gnr31AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh +GojXlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cM SOrHYUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOF QVHOEVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq 1tqzhltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZ TwtXsNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m 7Z164yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioI AjjHaIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbU KWwxQ4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjH uW/CSQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZN wwCfafMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <60a839f8-9830-7d6e-98a2-a7aa596e68e9@FreeBSD.org> Date: Thu, 8 Nov 2018 11:49:28 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181107230832.GZ5335@kib.kiev.ua> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 08 Nov 2018 14:49:29 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-Rspamd-Queue-Id: 00E768F34C X-Spamd-Result: default: False [-106.81 / 200.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ALLOW_DOMAIN_WHITELIST(-100.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[FreeBSD.org]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: mx1.FreeBSD.org]; NEURAL_HAM_SHORT(-1.00)[-0.998,0]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; IP_SCORE(-3.70)[ip: (-9.86), ipnet: 96.47.64.0/20(-4.73), asn: 11403(-3.82), country: US(-0.09)]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] 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 19:49:30 -0000 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. 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. -- John Baldwin