From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73327 invoked by alias); 12 Dec 2017 18:07:26 -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 73257 invoked by uid 89); 12 Dec 2017 18:07:25 -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= X-HELO: EUR01-VE1-obe.outbound.protection.outlook.com Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs.Nagy@arm.com; Message-ID: <5A301AD1.7040006@arm.com> Date: Tue, 12 Dec 2017 18:07: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: Rich Felker CC: nd@arm.com, Jeff Law , James Greenhalgh , Florian Weimer , 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> <5A2FC0BB.8050506@arm.com> <20171212163649.GC1627@brightrain.aerifal.cx> In-Reply-To: <20171212163649.GC1627@brightrain.aerifal.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: HE1PR0401CA0072.eurprd04.prod.outlook.com (2603:10a6:3:19::40) To HE1PR0802MB2489.eurprd08.prod.outlook.com (2603:10a6:3:d8::23) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 6e6b83c5-d17f-4dac-9e10-08d5418b2ed1 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(2017052603307);SRVR:HE1PR0802MB2489; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0802MB2489;3:MKP60i2UJzT47GuAfWpoJs0hdW/WlsWKHYzMIip///4qlKcf+CYw063xPIGGBtu3hBJQ6XUx7cl2bfVXny0n+5yYRvuTvVBbpe24MVrZyrPd1E7fW702D3/4SUGiR7fZGC+zgQ58ss5rejM9BBC8XU9MDeALaqWn7t7pMrzWPHEoyRWCScY9SDMcG1+7hJl/FcR+1uzXfL6KUOKWQZrk1+ToXzENVNyTsyACtjQeKnYFyakTLr8ozfCBr5FcfZ81;25:VxlbkvgJsrMHCLXGvsx5c5LboZWevKcE2JrOzdIVwiDUNAqmfOp45dmG8iLp20JZHhiNOj1Ss76Y40vdfspAEn3HfhbXlnuDzUfm9GP/KB5LJtAg6/SXF0kcMk1qyYVoPvuxzyQFLSlro8rlUJr/2e3fAQXHAMP/Fb7B4mJ0BaVJjwSy4/NUMXQUDreWNP0+UIfwNEum4VSio/G7i8bNfgXuwqpx+2r+57qx62A24CWf8RgnAxGHYXjY+/NnBPXBHixWShtHhSTHSzfqaibO/xv8I95fQVYIOt7lq4AxQaWoG6CP79dCtX5EEJMbqV3OCmsW2bNxyJ9AewBwKCNjrQ==;31:U1vtsr4KCY28vG+nt1XFmstKShQCzfGa8XhxkcdPkAYn0eeWwTwlGm3nP/AA87W4SXNSl6qu2ieCzopRUO8a8xpEczd0VYxbxRvC62yxpjXrObYC4Qa1X3np4XqhU1N4SQiAIgBMrbFMG4WRS1rfne1yMLMmLvRVrpD2xZaLu4gNSkntvKYPF4mPcdi3ZIcQ9hSpBgC9rQuQ1cJA1MpLAQadXddWoEzhhc1603KEWkc= X-MS-TrafficTypeDiagnostic: HE1PR0802MB2489: NoDisclaimer: True X-Microsoft-Exchange-Diagnostics: 1;HE1PR0802MB2489;20:N5VEeyo4kMdnNIRL+C9sAUzV+YRCH2cBtNDZkL5ZDSh3fmb3NZucbG/zcC0MevqIp6zDBH+xUQoswKwwg1h5ZbcrJgopxQTqdoOicnbos1iRVuIPmYGQSzF6a9vBGrp5QwM6swo2fzhMUrGfgmrPSZGd8i/uzapp5dv1iUXcR94=;4:kicsygI6swmegeK2U7ziqnv0IhNpjjqxWWX9T2YovabOy9p92dqx6ezryd7sMQshB8gGDDboybOt2vAbxJY6/AcTLrzu620imj9z3wBV6dFwz5tbWqIeX0p4ZtELWZTo4w7lcDAh0lqF0oFIBRFR7m9VySMIbjQUF0VomS6U2GBM+X7kU/pCTdUhNWt+zn5K6rQjQVm3FRaW5R3Iq93HMuLMagLlxPIAdgK+l4QqLVSgqR6/DPsqP+LlL4Oiw0zaXx6lCAfQHwFve6LqCjuCLw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231023)(10201501046)(6055026)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011);SRVR:HE1PR0802MB2489;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:HE1PR0802MB2489; X-Forefront-PRVS: 051900244E X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6049001)(376002)(39860400002)(346002)(366004)(24454002)(189003)(199004)(2906002)(80316001)(8936002)(47776003)(478600001)(25786009)(68736007)(65956001)(64126003)(53936002)(36756003)(33656002)(97736004)(50466002)(230700001)(66066001)(65806001)(72206003)(6486002)(86362001)(54906003)(58126008)(229853002)(65816011)(8676002)(87266011)(76176011)(316002)(93886005)(4326008)(83506002)(16576012)(16526018)(6116002)(3846002)(59896002)(305945005)(81156014)(52116002)(7736002)(77096006)(105586002)(6666003)(23746002)(81166006)(53546010)(5660300001)(106356001)(6916009)(2950100002)(6246003)(59450400001);DIR:OUT;SFP:1101;SCL:1;SRVR:HE1PR0802MB2489;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;HE1PR0802MB2489;23:je8jluT+9Hme1m6xNc7P2f9pJa0xOlFfsPN?= =?Windows-1252?Q?1iH8RHufUpEtotRAr3TrdJL0wVoR+BvoBgBBubNuS/KFEjUT7GAZcxwB?= =?Windows-1252?Q?OEvDnGml5Op1TgKUNZbZ6zeuVYvOA+yZY3c8e87HQCz6LeyWIxD+bade?= =?Windows-1252?Q?HtVRowSrHQnHwvfdXcle3d/fupBKCgziwBUZGu8uQWpKco/4xDAS79fC?= =?Windows-1252?Q?0G41LjZV/LT4np6zcMgbCOAIG28q4PP9haW6HpjUMRwz9rHTzygjSkXd?= =?Windows-1252?Q?gF0o0WQTs/wEaJL1vJ7eIU4uzMxJYrQIlJXWZX/cvhZE67JmspjTUVAn?= =?Windows-1252?Q?w61Lelypc2+f1ZRXkSUb6C7r2XE61Cp8YWrAb0sD8CRpBUPYmCgucZ2x?= =?Windows-1252?Q?sf3fZyXIZUurUEb4i82XCD34KlASPu2LuBdwg9IXwrPAZNf1hoTQLgv0?= =?Windows-1252?Q?YYNYiEELSav2wJdN1+WLrDrUet95P25dGdnOXJdPeozUKlwaWICIXflP?= =?Windows-1252?Q?oN04hjs0JLIqw34iKMtzOXkAVZbZc36kvQwEh3CIGT+86CxEcwOLRSeY?= =?Windows-1252?Q?Slx3pWuTRgWS5CxVx2z+a/wX+OQqCHRUzGKh/zN5C6cccy4GlatLUP/n?= =?Windows-1252?Q?Amsm4+nNSN+S0ZVkdQTIhRiUVs+tLoV05gipNFo3rQd6ydUlXVDxx/9S?= =?Windows-1252?Q?WNkFOQj9OIc3H3LxUppghvgrwvwy/Zuhi8r9sNAWGYwWFCfG1W/R/Aky?= =?Windows-1252?Q?R7AtP/ZmRB3Pn7dpowXFgxRnXbBy3OAfHjQZZJGPrWRAiasoZuQ4HJTH?= =?Windows-1252?Q?E4N3T5qHLnY6tGT1FNnpP8EonT9vFIXzxt+5Eelzz6cyUs450QOlF2W+?= =?Windows-1252?Q?b2dA7C+2fmtMEjFQMw+daQs69J0eY2Rv1Jjrq2rt3hkvoUMKE6C4tiOy?= =?Windows-1252?Q?wweJNjo9RrQQqBwX+W7Cffm1qknmuHp70+md9tKa6Ci25BFr2tNJ8Exd?= =?Windows-1252?Q?k00XJUM3FhjchI/jVsPWaYswd1pEU7xGz6j3rWatGfPm4Omr4utRj7DT?= =?Windows-1252?Q?U7DGyBuDUnIC9hFUeMiUFda0eutvtVnV4zBYTcsEjRBw+iK/UI8nZI1n?= =?Windows-1252?Q?mOmRbNZfLLoqSmou8SrQLca8MPWANJOsVDJ0X6BRuyuB9+TWvgTW6AW4?= =?Windows-1252?Q?3Lys2NdymVMOgJa1cbqqvstalBF8vdZMbVaekS8h/asTFG2jIPpP31QL?= =?Windows-1252?Q?sNnWUfeD1SIDqYTqO4Liulm/gvqnCNI3uDYDCOtMQi/rOGB0DK2FTK+Q?= =?Windows-1252?Q?DzCElhZC287c3O9A9a/ItEzjiMGCRIjaKFNKhGy+GRR9lZtAJASAddGf?= =?Windows-1252?Q?5JAYTBOScBREmbCmGP3YgL2ExrtkNBxIz38yS0jF4sUw7Jho6OY93vnI?= =?Windows-1252?Q?cHqG+JGpxW+SS9hWay9S5DvFj2KFw+US03bR2BlEX8++dtGwYmj1KQY0?= =?Windows-1252?Q?KM8eb+dE=3D?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR0802MB2489;6:fmEmlNuxRlwXm5CA5TicDK+MZ/UFvTcJxBFgeoSrAkUXHeUpmSd/z9xWIcykRr0NVFVk+MYNnQJ+oMBrVLfoNOG25wCjkeFjyHZmIgrgRL30krinPqn11V6FOau08zgQL90OTg6Z45mtccx7Ihy6hks+0xge8RDRpZA16CZA8ptpyZyKITe27H+/7vVy06KneM95HwE+O9OVaEcmM2F3/C35DwyEqu8Gpw/DqaE23BvRT9NuuR9GKQZcjE8c/4R+CbE91Eb3SjtavKw0IlMQtX8qfi/Vsm2G7q3YiFz4gdHuOGzYV6w4cfv7hvnjpfuPyXIfhokoYObD5W0OrELJmlSZbi1s0Gr983l0d7mx9rg=;5:WsJ3S0qP7wF+1zTMI/s9GPpVyAwKaP7NBzmXPtGfK0IakH2hidtiXpsogiKUyV5br6jsENEC0o8j+ColaEsF5GT5EU/CZg+ag24Vb0ZqHW9Djz0sXp6865y6w3YjsCg8CYz7Jq+vf+xhu9xN3jy93thixAf2S07Cr6eJSlxXvTQ=;24:g0RY9FyJAOOozKc1hukHC/UBsspi6CwprdDHwusBB9UDLkwuJwz4lxiIzKmk9Lvc+W+6fXKM1UYE9tFgXulAEKRNGN0OM053jVx1ozPzCt0=;7:W/qP+9lDCtRPfD9OwNg/Raat5kheWFfjlqOllMsWEbXzW+/OGkNd/u8lqa84npHkGhFkXOuHONoCE4jywJnRYkFW8O3T86AeTjWf5m0XcPnCPgzDTBUTn+yHn5bWdzoJDbK5aIg9uGGPY2mBF7MTfEVgJxJ/tbJAwQviZs4pKXCb63M2MmWzb4mIS+plKPZt6/kHAy5CcsASxKAf0CeGtjWNWS6TsFhOzMInncu1wvW3Fz7SISrk6Vt9bWeCQsVJ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Dec 2017 18:07:17.9542 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6e6b83c5-d17f-4dac-9e10-08d5418b2ed1 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0802MB2489 X-SW-Source: 2017-12/txt/msg00380.txt.bz2 On 12/12/17 16:36, Rich Felker wrote: > On Tue, Dec 12, 2017 at 11:42:51AM +0000, Szabolcs Nagy wrote: >> On 11/12/17 23:49, Jeff Law wrote: >>> On 12/05/2017 03:55 AM, James Greenhalgh wrote: >>>>>> GCC needs to emit probe intervals for the smallest supported page size >>>>>> on the the target architecture. If it does not do that, we end up in >>>>>> trouble on the glibc side. >>>> >>>> This is where I may have a misunderstanding, why would it require probing >>>> at the smallest page size, rather than probing at a multiple of the guard >>>> size? It is very likely I'm missing something here as I don't know the glibc >>>> side of this at all. >>> I'm not sure where that statement comes from either. I guess the >>> concern is someone could boot a kernel with a smaller page size and >>> perhaps the kernel/glibc create their guards based on # pages rather >>> than absolute size. Thus booting a kernel with a smaller pagesize would >>> code with less protection. >> >> historically posix required a single page guard at the >> end of thread stacks, that's what all existing libcs >> implement and glibc internally assumes this at several >> places where stack/guard size accounting happens. >> (so larger guard is not conform to posix-2004, only >> to >=posix-2008) > > I don't follow your reasoning about how a conformance distinction can > be made here. There is no formal model for "does not have additional > guard pages"; that's just an implementation detail of the memory > layout. As a thought experiment, a hardened kernel might always put > giant randomly-perturbed guard zones before and after every mmap. > > If the default size was actually specified to be one page in old POSIX > and pthread_attr_getstacksize exposed a larger size for the default, I > suppose this could be a conformance distinction, but I'm not aware of > such a requirement. > pthread_attr_getguardsize must return the user setting or the default value (which was required to be 1 page), glibc has tests for this. of course it can lie about the guardsize (internally use large default guard size but only report 1 page) >> users can also set the guard size explicitly when creating >> threads (at least openjdk and erlang do this for threads >> that call c code) and that's not something glibc can change: >> it is allowed to round this up to pagesize but not to >> some arbitrary larger value. > > Likewise I think this is mistaken, for the above reason. If the > rounding-up happens at pthread_create time rather than when setting > the attribute, it's certainly not observable as a conformance > distinction. Of course it is a QoI distinction in both directions: > > - Rounding up reduces the available virtual memory space, possibly > limiting the size of an application (detriment to QoI). > well glibc has non-standard apis (pthread_getattr_np) that makes the guardsize of a thread visible (again this can lie) if rounding up the guardsize to some large value actually break existing setups then it is problematic even if there is no conformance distinction. i think such breakage is very unlikely (running into a limit because of 64k guard would mean the code was extremely fragile and would not work on a system with 64k page size). otoh if the pthread_attr_get/setguardsize apis do not get/set the actual guard size then these apis don't have much point (i.e. users who "know what they are doing" and need to set the guard size can't use them) so i'm not sure if doing something different internally that is visible via these apis is what users would want. > - Rounding up may limit the impact of stack overflow bugs to a crash > rather than something more severe (QoI advantage). > > There are also other safety improvements that could be made at the > expense of virtual memory space and run time costs. For instance in > musl I've considered a hardening option to put guard pages (maybe > repeating the requested guard size? or just one page?) between the end > of the stack and the TLS area so that stack-based overflows can't > clobber TLS/TCB. But this is rather costly since it doubles the number > of kernel VMAs needed, so I'm very hesitant to do it without evidence > that it would thwart real-world vulns. > >> glibc has another problem that it does stack accounting >> incorrectly and thus increasing the guard size can easily >> make existing code fail with stack overflow and fixing >> this is non-trivial since many users already expect the >> buggy behaviour (with glibc specific workarounds) > > This indeed needs to be fixed, whatever is done with regards to > default guard size. > > Rich >