From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64156 invoked by alias); 13 Dec 2017 11:58:04 -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 64128 invoked by uid 89); 13 Dec 2017 11:58:03 -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=Hx-languages-length:1968 X-HELO: EUR03-DB5-obe.outbound.protection.outlook.com Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs.Nagy@arm.com; Message-ID: <5A3115C0.7080609@arm.com> Date: Wed, 13 Dec 2017 11:58: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: Florian Weimer , Jeff Law , James Greenhalgh CC: nd@arm.com, Rich Felker , GNU C Library , Richard Earnshaw , Wilco Dijkstra 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> <20171129205148.GG1627@brightrain.aerifal.cx> <00c123b5-dd46-6777-2c24-d80eae8d35df@redhat.com> <20171205105530.GA12966@arm.com> <50564a65-45dc-062f-46ba-e25d3b76b721@redhat.com> In-Reply-To: <50564a65-45dc-062f-46ba-e25d3b76b721@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM5PR04CA0020.eurprd04.prod.outlook.com (2603:10a6:206:1::33) To HE1PR0802MB2491.eurprd08.prod.outlook.com (2603:10a6:3:d9::23) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 78ebb735-225a-4644-50e7-08d54220bf77 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(2017052603307);SRVR:HE1PR0802MB2491; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0802MB2491;3:hIy+601fKG+aNmMl5AryCCHem5AX8b7gwrH+XpijU+hPCYWM5kWr/eX2TeRC8e80/2ux3JWGLMj+UajN944mLPi853TVWQBWPAeWLq55nAp0aUJlwu5ghf9yh+PSAwNVOzdAzPNDujuMfSknkoa5lGslyW0OUCf0ZdgFOV5xaMb6e3MJ15Ys3yxiFxi661/biklaWJQWg9GoTQwGpbEcHPP+VQllSE9PhppZti03CO6nfVfgH0XqJE/P8ci8kJic;25:Zfp7YJj7vt1W2B3VOadWSk2SMQRwWJP+LXldFO2CP4ddlfPG+Z8e5/10MEBPpEYmjLcSAA0DXXR5NZZOY2jwYaWA2czXQhbtGugyPLQwKM3ZMHGP3djI3Vs7JdWM5/hSQdoiKJWWnU3G0lWTbhhF5w72/fHseg4m5qnkZh+FMmdYmkfl7Cbq70MLKEh7vXrPu6rg46S6NMU5BNn0fMKfBfpmwn5iH2uug1Ofi45GKhIxz8yJsr63NkLOK+FIibr29kXKafx8dGRA3n3LkhCGi/2FLfzZtrcepV6xaSrWaCzZB/5BBmH1xqOAVSHUAtagvkZNsa1zRAD/hGCDKTIQAQ==;31:xjO2QgpsvaNdZhGr/p+wLaX7JU7DRvmf5Y/d5gdrfxk7CBSBxO+/pjYRl36PVcASYZmrSszzSHIRQ9mjHOxQLpoKCZR1dsGiWTDwTxrx26JW/Yn+JaIkLwdvgjpqqZFj0QUvJHcgWyXBOD1LbFyHXz3D2maLOr0sVGns9gkO21HCmkQpzXnsus3myFTYU4mDn6al7yGXEuos/xrKhzc5RTiwnPoX9dA6qq7EbZOFxgQ= X-MS-TrafficTypeDiagnostic: HE1PR0802MB2491: NoDisclaimer: True X-Microsoft-Exchange-Diagnostics: 1;HE1PR0802MB2491;20:Z76koXXYRMi2XntUBoMLd9Ox64Zidcbc5gf5JVXGiqdnAJ1tU93GqGopyz/6GvDIk1IAQCLT2UqfhvBDx60JKuwJ1iaOUe1bzjBdpprNYwR4eYATrud5CeAkyLDNdaDwz5AGUYW+cXKWJkim61+kM7FLH3ZJXn6tUnT203Rf6DI=;4:wQNg2VapNzN3wao+zBZTj8Amy2BlE41+XoXLkNrxPEHCTCZHQT9R8zJHVtoA7xSHclC/6n3u35umZzI8VoIpNvWSSt8dBrlY81a8tsToRt0HEl6p5hyJivHWbCEeWmWNP+1N1hYblypY6nFbJyR5evQXayUmU5E96tXlz0Ezxe9QPyxKfpXDKnQHoJZS6X5pEnI/7SeJiZ8u8ZAQX2JeAt8xDpGicO6/s//HWGtxKhfcImdaeGqg8P5DGEBTIonYrfHWAnXmYtci+qJPHXCyDQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231023)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(6072148)(201708071742011);SRVR:HE1PR0802MB2491;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:HE1PR0802MB2491; X-Forefront-PRVS: 052017CAF1 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6049001)(346002)(366004)(376002)(39860400002)(199004)(24454002)(189003)(2486003)(54906003)(81166006)(8676002)(87266011)(25786009)(50466002)(80316001)(2950100002)(36756003)(6246003)(23676004)(230700001)(5660300001)(52146003)(2906002)(81156014)(76176011)(65816011)(305945005)(86362001)(59896002)(229853002)(16526018)(7736002)(93886005)(4326008)(105586002)(316002)(52116002)(58126008)(47776003)(6486002)(65956001)(106356001)(6666003)(6636002)(66066001)(65806001)(68736007)(53936002)(110136005)(64126003)(16576012)(478600001)(72206003)(83506002)(33656002)(3846002)(6116002)(97736004)(386003)(8936002)(53546011)(77096006);DIR:OUT;SFP:1101;SCL:1;SRVR:HE1PR0802MB2491;H:[10.2.206.69];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; Received-SPF: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA4MDJNQjI0OTE7MjM6bjlFajBISndobEdjVERQMm0zZDh1bFpM?= =?utf-8?B?dEZjREh4b0pFUHRza3NneVdqTzdVM0FEaFJvZTQzU04vZzdTeStxc1BRQ255?= =?utf-8?B?aEpTWXFhQXc2bVR4dWx6R0s0c1pBLzM5bXU4VEc5dnpTcDVYVXRPSlkwMzFZ?= =?utf-8?B?U3JrTjBqUnRZc1hBSWZiM05ib2RuNWhzVzBwYnl6YzU4cmNiOEtkem5oa1c0?= =?utf-8?B?RDNudGFwU0o4VzBvVG5nYlovdk5VanpMQmJ5L3RqbXByK2NXYmNSeVl4UFho?= =?utf-8?B?eFUvUDBwVlA2NkVqTU5EeEZTcHNhTm4vTFBQbmRPcTB6VkNwY0trZlVnTHRq?= =?utf-8?B?UjBEVUdYWENIVCt0eWg4VUpyMkhteFA3SnNoV3V3M0o5dWRrVWdMRTdCUnhr?= =?utf-8?B?TU1aRDduU1hjYnVaMG4wVmM4WHM0cDNoczBLcEVSN2RuU2ZiR2w1aitQWmhW?= =?utf-8?B?ZXZwc0Q3UXVuZU1Lem9QL0ZMMEhvbG4yU21nQXl4b1pjUS9Zbll4L3RxWTdO?= =?utf-8?B?aG56c2xqUUdtalUrc2xqQkhqYnhYY09INkgwaGtlQ3ZaSDNXS3MxZHZXUFlF?= =?utf-8?B?WlhEWE9ldko1TGZ2T1Z5dloyYXczaStmeWZnMXEyeXVUNTgwVC9OQUNJMHlv?= =?utf-8?B?MWE1ZlNjWk10YXhaWHVzMEhWSTJvUjJNWVMzTW5uaExHZy8wdFREaS9EbFFp?= =?utf-8?B?eFlOb25UWlB4dTJQbHFkNFgrcGNmL2ZReXpkYXZPOWllWkFwUmxheUYzejBo?= =?utf-8?B?ZGhoK0g5VUxuTVJzaThVTlFHMXBhREZQVE9YQ2JXL2NwWWxqODZncisyZGlh?= =?utf-8?B?Z1NLQkNiMUdpenVSZkhibXdRaXU3Qyt5Rzg1bXdxYUROeVRBU1FscldiaHVp?= =?utf-8?B?K3YzT2ZnWm0vUGFmWDFQTndJUUhnaXZhb3pyUFdBMWJ0L0p5UmRHemdXUHRN?= =?utf-8?B?WVZxZUI3SWM2c09GZmhJSmxHMTRxenJFRFE5VndDWnB6THJMdFF1MnRDY3Qz?= =?utf-8?B?YllyQ0pWUkFwUERQN25nZ0tjTTNTVWJRaFJIUktqNEZDeXZhRlBPdzlLd1B0?= =?utf-8?B?S3FhTDRzbUZpR2NmaEdWak1Vc0pJNW10dHUxc2FsdzBqc1pQZCtsczdHemo3?= =?utf-8?B?ZjZpdWRPRzlxamd2N1QvR1BXOFhuMkkzc1NQaGFFNVo5elNPaC9pMDg3VW9Q?= =?utf-8?B?WWoyZUUvM3I2L3R5WnBDUUJWdFArTzdOY0hKSDFZOEhjM0ZHYTQ3ZW5PRFpr?= =?utf-8?B?ZjYrQkFrbXpiTnpmQW55c1g1cFNaM0IzMHZvYmJUaTRmaFl0R2NFNzNOR2cr?= =?utf-8?B?ckdJbG13VDBramxtQnVCWVUwcmxOYllPeTBGYjN0aXpTOXBPditMaHBISVhS?= =?utf-8?B?djU2b1Jmay9CR0MrZXd1ZjNkeWcrdWx4WmV4c0lweWpyQU0zdy9jdlZLOG1h?= =?utf-8?B?eXhBMVJUUnNZcDlJZWszMGdoRGFQSGt1c3lPdHcwL0ZVYnBaMzYyUkk4QUd0?= =?utf-8?B?WHZ5dzBLcGN0eVJCVy9iREFKaFd5bEpxY09uMDE5WVpsOUVDNmp5MXpiVHZ1?= =?utf-8?B?QWJRS1J4SVhxZWd6MHZDUlk3dXVjYjZuRzRYa2J1ZHUrL1NPWEU1NGM3Wlkw?= =?utf-8?B?RFNJMFAyQk5pMEtETXhteUlxV2hqbHlOZmc1Rmh3YUhJTEdMUEpqR1dQdkxh?= =?utf-8?B?Q3p6ZFJIalpmQVloRnhDQUJrWGF4bHJrOGRoQ2x0aHAzZjNnUEhwRkVFb1A0?= =?utf-8?B?OGlCQmlNVVppenRZWnQ5Y3BsZndCLzZEVUJJT2x1MTVjbTREbEJ5akVGQ3B6?= =?utf-8?B?S0t2UCtLT001QmdDNFowbGhmSmFZVDNWTWRuOThZU0h4NDR0cVgzL0hHcFB3?= =?utf-8?B?a0RITlJnWUw3cWpPRjl1R2ZKNnpJanN0dzZobW1BSmtiTUJmRkQ2bGcvZ1lY?= =?utf-8?Q?pP4jZs03VbNHHPNB40Xc33QmqjLqsCSo=3D?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR0802MB2491;6:XJDpiNdO1rWFCyCCe2xkaGNxtcLsranIG2gVluQtpO2kChvGXAzzdbu7n12bSGM5ZNVFNTwDP2d/W5fEo7ydoUeGD+dDRbiXdhfD+bumKZVmefgmQk99IV55W1sKK4hNLQl1yAIGw2OJv+btkhDT7a8UescWQvKGEA7Fr/7fIx0RJ8hJ2zvmNWJKgeu9xVjJEBO/dGjrcBn45SqdU+cyVu1EVRp0TMeeU2+tOiD5QiM41qT7HpC6TBudvJoJZGQ+CmbgvAuKR1Snn5AK/3i5KApoFHyCZZtqXqSGxK8p6ZtHFjQsqZ39A4oTPG/fDVluhLwy/Fp6Iqfdh8Qf3++udSB15Vi6u6YrD0qd2r9W3xM=;5:wvI03gV2dcUtWf2l2wPPrCdBzHIC+/fre+ckecxI/CDbS7aKsUGb6BGNsn1u7BJQhQC0fL3Dml2W+FGrGXGaO25R6vEMXuTPTvcpktuKfyHY6FJNQlTGDI7srKlPaJ1EbkZ62Lq6658YIeQ9KXmI2dUH3XVAXvmGtyREwqyo3Eg=;24:UjpAVdLdubmQEtWLeyJelow8dMkOiY/icCEPpkz/ooqQeXOyxELc3vWqXSAxUwn/CyCXS6madOzzfh6fZOYcJeZNHeTKyxAVnw6eicHNi4s=;7:br7X68IQJOZ+WcaHZaw3u1V30Wv1Hvx8u0NUlZDaYW2b8filx1U7ShGIz5Un03VrJfPfhMnd5MeFCRGu53Uv3sa3Z2Cnpa5DterRm35HSP4/HbL42R+VOD6ghBEjDaLEadokwRyHot2Fv/xhBNVrqyzymsn5chWNROxzC5xdUZLMlTXTmVXjV/DE/ZtyWDYXnf37CZ7UYJIWRsiqGziMW5w3OMzXBkfb0nsOrWZiOmqs/UAx0DCu24J4aRkHJWu9 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2017 11:57:55.5510 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 78ebb735-225a-4644-50e7-08d54220bf77 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0802MB2491 X-SW-Source: 2017-12/txt/msg00405.txt.bz2 On 12/12/17 19:30, Florian Weimer wrote: > I'm a bit surprised that the 1K/3K split wouldn't achieve that (i.e., pushing the cost of probing into he > noise). Is this because GCC wasn't built for this and has no way to recognize implicit probes which occur we don't know the exact overhead, the current patch does not emit optimal probing sequences, but >3K stack use is common. > The patch which started this libc-alpha thread applied the 64 KiB gap size to 32-bit architectures as well. > This is the primary reason why I'm objecting strongly to it. that glibc patch added an arch specific knob. otoh i don't think we have different code on the gcc side for ilp32 so it will use the same probing interval in gcc-8. > If aarch64 wants to do their own thing in 64-bit mode, I'm won't complain that much. i can prepare a patch, but it will need to change generic code in glibc. (because a lot of stack accounting code is broken or hard codes 1page guard) > The existing ecosystem offers only one page size. The larger main stack guard region size provided by the > kernel was a stop-gap measure, initially with the intent to patch nothing else, but it did not work out that > way. I don't think 64 KiB would make a significant dent in terms of practical exploitability (all published > exploits used larger frames or alloca-based frames anyway). > > If GCC assumes more than one guard page, a lot of things need to change, and it is difficult to communicate > under what conditions a binary has been properly hardened. If this is the cost for enabling > -fstack-clash-protection by default on aarch64, then so be it, but we should not make these changes on > architectures where they do not bring any tangible benefit or actually hurt (due to address space consumption). glibc can force >=64k guard, no matter what the user setting is, but as i wrote in another mail i don't think that's a good idea.