From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11406 invoked by alias); 6 Dec 2017 20:41:38 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 11396 invoked by uid 89); 6 Dec 2017 20:41:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=magnitude, H*r:40.107.0, H*r:sk:EUR02-A, Hx-languages-length:2716 X-HELO: EUR02-AM5-obe.outbound.protection.outlook.com Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs.Nagy@arm.com; Message-ID: <5A2855F9.8040901@arm.com> Date: Wed, 06 Dec 2017 20:41:00 -0000 From: Szabolcs Nagy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Wilco Dijkstra , Florian Weimer , GNU C Library CC: nd@arm.com, Jeff Law , Richard Earnshaw , Rich Felker , James Greenhalgh Subject: Re: [RFC] nptl: change default stack guard size of threads References: <5A1ECB40.9080801@arm.com> <76c38ecf-6497-c96c-5c8c-95cceed100a5@redhat.com> <5A1EFF28.9050406@arm.com> <5c796246-1907-8cf4-00fc-eee11614b092@redhat.com> ,<91691187-15ae-e740-bea6-94eff4172263@redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM5PR06CA0030.eurprd06.prod.outlook.com (2603:10a6:206:2::43) To VI1PR0802MB2496.eurprd08.prod.outlook.com (2603:10a6:800:b8::23) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f97f89b9-9259-4a46-5918-08d53ce9bc0e X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603286);SRVR:VI1PR0802MB2496; X-Microsoft-Exchange-Diagnostics: 1;VI1PR0802MB2496;3:nunuNgiHNMzGQOGzt4xwJnx8uwaiiakHhEKRhNkGqvrwqO1Bpa3Eqz387J27rODrltg6qJuoxjsJFUeaoviuwRrW2wtzNLk8T+a/lKL2LefU2fpGvadU+BA3PPRrARMX51HavQazuFzxQzCbxOpJvBsvZh8q4T5CZa8ZmhKdk9gyCO1kbvXsdhyasEEEvyZVsnaFF5NOnIeVJPsNBWubCzRU2ft9UxUM8lYG2XOyo9mv4F2e0/3isJUzDdpCGYPz;25:rchzy1hQF1rnJtiVE85Pnr3IQn0TWGNvqYcYUe86VIwrhOqDw6C36O9Z6GSdCKhTpjLIEySh44rFPk7Kb78WdX9FiPYw3alMgDlA3RV273kasc61SCQHonyWmZoR+rTxUAPjlNsg+3G/6qhDtrz1StZSzjPcuTIlA/X5P0U1Q662g3FZrThkD5i81zLb0tVdOngKoRca3K/AQwV5dzuplwWebU61Hk9ZNyLs4uJek0pPRp6iO9xI8BBypN4r5NkUbVCj/B9XbyV6kIJn5xwec8aIrEncBoo7BYnKEzBU3nM5/KnUsFgz11lCquYOKRAS8C7J5o/nav55X75PS5txCQ==;31:/rChLVqQbK9KcIXfTqFop7uT3bRycDipZ1iCjM4AVkj46WHAHb8V8JntFMxR/X3oYdOVY9CYmGI3YC8gc8lWOPe4DheVFLrDqfm0QKe1BlQ1yW631KYHl0gVP6zaRBKEUczyUQODaUXgMvTQF+e/FskKm6sloXskaafJKgOpKTwRqQFLAo/OSDlU6PeTyHecU8QAdi4UqceyV08pMSGf3xyG/1cOPWmYFAIFgJ2LNpw= X-MS-TrafficTypeDiagnostic: VI1PR0802MB2496: NoDisclaimer: True X-Microsoft-Exchange-Diagnostics: 1;VI1PR0802MB2496;20:2UTVVeLQmfYj1aeKpt3QFO3nCh/nDtHd1bRebBzsXY/1Bu42Suo4YFchmE3g9XZJ/CpbQ7MvWnc4spVbjO6ww1eBb16VNqC8DsgYW6R2ktlw2B40uqbJ8cygomM0KoDbXKUY2RJlNp1hXNgoidTNoDXsmtWS9YieKFejgxpBjI8=;4:sM2cjtFYlj+cjh5ViwwI03YojCPRJF6uhlMQIhrJQiXAZlq6WKXy9B4byIEs4cwpermWg8gv+OlAU+f5aMaFrV+Fi26zZSQJk8SW4Akwvm7oOhqg8aoPw+/4Ar3entihTj4sU4CmP+bSOij6d21xo3wIqWXGAVEDjDypINdfqNmVDfB8YxRfF/zvlQk0adBnIwxMnBcq73p6umAi8Vouq9FGpyJ0YDIQpZRJYnHbVlcqRIe6hquzcunz0M7djeGrE0x5e0r/Zpn4oAwK5Dr93cHHmbd2bxAkHN1XNE9DK/yNsCE/KI28lw/Ux6Tfm4AOxUfDX3sw3jKUBEl7C47ct4o/I2whIyM2FcJ+Pv2Uenw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040450)(2401047)(5005006)(8121501046)(3231022)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011);SRVR:VI1PR0802MB2496;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:VI1PR0802MB2496; X-Forefront-PRVS: 05134F8B4F X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6049001)(376002)(39860400002)(346002)(366004)(24454002)(189003)(199004)(5660300001)(4326008)(16576012)(33656002)(81156014)(53546010)(305945005)(229853002)(6486002)(77096006)(81166006)(59896002)(7736002)(50466002)(23746002)(6246003)(72206003)(47776003)(8936002)(25786009)(316002)(54906003)(101416001)(68736007)(80316001)(105586002)(110136005)(16526018)(86362001)(52116002)(64126003)(106356001)(65956001)(65806001)(97736004)(478600001)(2906002)(2950100002)(87266011)(66066001)(8676002)(6116002)(3846002)(58126008)(36756003)(230700001)(53936002)(65816011)(93886005)(76176011)(83506002);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0802MB2496;H:[10.2.206.69];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; Received-SPF: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;VI1PR0802MB2496;23:5LPvCwUHqHWvxIgs8sbO5pZnUQ3xEA3DHzD?= =?Windows-1252?Q?3rMTKlWWZXPyArWr7O+Wls+S0fk5zGY4IAcLtBThKxylTRFhny+BpEXz?= =?Windows-1252?Q?4M0fMHDowjd6v4B1DLsvNqLzIg4fB3QFnwGry9Gv3xx2DG7wYD5FNGUe?= =?Windows-1252?Q?muaU3/v02l75e+gu/QQ6pdTogPgN9Ab20NDR+JFKeIzYnYHH7fAHJ7X3?= =?Windows-1252?Q?duby77HmoI8AlACnHioKhnbvGbZfUpRPvYsBIVaZLhBhPb5hXM6+tSSh?= =?Windows-1252?Q?JbIQ1mq8r1m+KzFdHI68e5+Ahs3MrwcYpBLKH2/eZPqICHE+7HZw/acn?= =?Windows-1252?Q?72uuP8UQDUdr7EswxQWZZuuXKMlgHbamKqg0ntqcRvRm+hfa4PyV/tyw?= =?Windows-1252?Q?puFxy7m9YPX2CjOe78OyfYO+z9CxK7CE/GKH/UEsqgbCXfZamqz6CRGX?= =?Windows-1252?Q?j68BUn9Xk3rozzayUTznRPMghNyJQz74CIEIceuDKh1it9HRkvioYUl4?= =?Windows-1252?Q?bMquU4gf0kACm/NvhvjVqIRALgJsD2Isk430ruj4VeLlKaVAcJQ+fMc7?= =?Windows-1252?Q?rW6rWRpfCrPUbs5rYGpFohyxSIkJn/TeS1MtOFLMoFbxAH7mjoXREBHT?= =?Windows-1252?Q?1q+enP3leaEI3hjJPKREoEqBs5Vhl8xOMqAeQiYCDCOz5FJNh4smTxYz?= =?Windows-1252?Q?opMWpCf9pVD3kPDQ3kZNhX4AV3CYgC9NrWqEMVtoS49/0TLZj6lg1g+q?= =?Windows-1252?Q?AHQvlblKlur8zbyV61z0y4TYfXAiQaKEa+jdb9kc3HJ53GkSiFGNv3Bk?= =?Windows-1252?Q?coGphaENXVgWaXSWYeAJ2fFAXQpB34vZlR6DcgbbMV3nXW96igyaEQzU?= =?Windows-1252?Q?ElaVAguJA1VR6tI+n3vq3AE89Dlh47Qsf+eTWwN79NSUtPyVpBVgKnsx?= =?Windows-1252?Q?k3vQ9VKNaMKbk7AdoPqdUtgUmMOEdTIN+gFU1pekUNNXIygDHombPDBB?= =?Windows-1252?Q?mDOQgwIp+O9kDqxnpGpGxW99beXJUr9+fxCMdwwcXyUcQa35tYxF/y+C?= =?Windows-1252?Q?GDtMQHpe08vWKqR0nigQ6Wc6spGULJF6mwSO6vB+ows0aSCwjz6m6g4v?= =?Windows-1252?Q?qULXjxyDfG7fY1kFtLpIhlha/b/pcdEQjnpdeK0PjfR33jMlbkeBNrki?= =?Windows-1252?Q?HV2AsQzD/o+KfEdZ+ltCLjXzG2n2pcdblJJMlOwZW6fEq3bIBuNrAqaS?= =?Windows-1252?Q?2jb28sTDdcPEt192YRUUcEj6jP62/h4fXbOchkRIfb1ygHJLErvxPoyp?= =?Windows-1252?Q?Bi0Qh9PgNBPXPn1cwavr2lFd9I0jgQ1i2+i3HNaz7aulOYZW4FPITS6O?= =?Windows-1252?Q?yZhee7sgXYeJ4JH13GFR1rmar9MS7en8YBW3IBOIU1B6AePldXfFvhfS?= =?Windows-1252?Q?Hb502Jk6OAoudWQwtIVGgJTbr8FZx5m8j6DnaarN/Fw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;VI1PR0802MB2496;6:/o3V+q1UD49ZIi4hqgcEHBFr4f6l+uza/SXx0dUTYYDTGa7Zv0j/7gIVQLEFKmWXTblxC2Az1rIJATFfZLcCz5B3SXplT0EgvZrtS9W9p7qC35XNlWWGGRltbZEajwbM56zKBmq5w5pC2kazRvB305eEPM26zheMBwYBWxI5IzIdMJvwHp3EZJqACdByTfc29OhJdO8MsaNDyKOS+pEXsrDHOiGc8r9fpFtudG4OTTbmWuGeNV4oRdG7tRj/fArgwyDPMtyWbpcI/jar3fCkvpPtTjs40bT8rcAHBiXhuqIXaS5EViueS3ceGsDM3zIQ2+Uf3AiQV59aZMGxYUr1ZiqH1gBiH6FS7/iyofAyAUQ=;5:JYrYtr8EgOhoolcjOMZVN3DgcGhX+pMLml7+qUqgcJ7xDOJe8bUK35BFOVFwIm3sNZISQLvXIHh9gIPoWFyQh2W/Ez4bHkSxmYvmBqLS8ACPvUT8pEzoOko8f1HwFtxkYjeYfVgV9evqj9cSBPUhzFSGkGeLBj6z/MAfAvqNdEk=;24:WEvEucGWuMpP6ENT/mlJFiYxoT0noYUc8fx9T4ZEIWtWUSgymknz8/DdS+mDkgZF/MZDloiZMymrXIXVIvpLuu1xWNHfaew980sz1oY2S3E=;7:NAWKpgmzJQf1By/CrL189qXUHbGPur7gWY6B27uyWzMvxUABpu4bbj4RWnEG8uHTkaxkPI6CsFUWw0AYa1sh3Kokv8S/42/P7ZALgvegOffrazhNVDOk109dCA+WQbEQUIQhYCimbiYANwPhZJLNKO0dvg1QVKguAFKxmDLozDAppzkv1ESGNItANFzvVM/wVBB7Cx5lcfZz+UHGD6PySlGZWRhUX9eNEwQhWxwo2Uki6ETYsMIs8wK6n9HRYZB9 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Dec 2017 20:41:31.8678 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f97f89b9-9259-4a46-5918-08d53ce9bc0e X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0802MB2496 X-SW-Source: 2017-12/txt/msg00182.txt.bz2 On 06/12/17 14:27, Wilco Dijkstra wrote: > Florian Weimer wrote: >> On 11/29/2017 11:28 PM, Wilco Dijkstra wrote: >>> It's not related to what GLIBC needs, but GLIBC, like Linux, must continue to >>> run old binaries so a larger guard size is definitely beneficial. No existing code >>> uses probing, so increasing the guard size means far fewer functions could >>> jump the guard. The dropoff is exponential, each doubling of guard page size >>> halves the number of functions with a stack larger than the guard size. >> >> That's not actually true in the sense that the math doesn't work out >> that way. If you have a weird function which skips by a really large >> amount, you can double the guard size many, many times until the number >> of unprotected functions drops further. >> >> And there is definitely a long tail here, due to GNU's affinity to >> variable-length arrays and alloca. > > The math works fine for most of the curve. The measurements I did > show that the number of functions with really large stack allocations is > extremely small. So it's a long tail only in terms of maximum stack > allocation, not in number of functions. with 4k probe interval about 1% of functions need probes with 64k probe interval about 0.01% (order of magnitude, alloca not included), so increasing the default guard can be useful for existing code. however i have doubts about mandating 64k guard page size on aarch64. in principle 64k guard on aarch64 should not cause problems since there are systems with 64k page size already, but there are some glibc issues: bug 11787 needs fixing (at least the guardsize accounting part) to avoid wasting stack. some applications control their own memory use via RLIMIT_AS which means we cannot arbitrarily waste address space either. the right logic for pthread_attr_init, __pthread_get_minstack, pthread_getattr_default_np, pthread_getattr_np, allocate_stack, __libc_alloca_cutoff is not obvious. and backporting a change with minimal impact may be difficult. but more importantly glibc cannot fix everything: there are user allocated stacks where the user presumably allocates the guard too and we cannot affect that. there are other libcs and all of them use single guard page now (bsd systems, bionic, musl, ..) other language runtimes may explicitly set single guard page too (openjdk, erlang,..?) and providing reduced security guarantees on all those systems is suboptimal. (can we round up the guardsize setting?) so the question is whether pagesize < 64k systems sometimes getting reduced security because of small guard is worse or users turning probing off because of 4k probing overhead.