From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam02on20602.outbound.protection.outlook.com [IPv6:2a01:111:f400:7eb2::602]) by sourceware.org (Postfix) with ESMTPS id 9DBD83858D35 for ; Thu, 16 Mar 2023 14:41:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9DBD83858D35 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=azul.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=azul.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CnuYe74Tl0EPxA40K++30voaVP27zdVQLHEEdMOZldysUvxk+HIt5iRPu9ws5xPDP0XGdjChjj3445A+zDakj1xpeB9Z3eQpKMLzrAU2Wkd/e/4YKBXS6TZKsZZO+QcYhY0615IPodTqnD4rmWngR6DfDJaZmDYksAstrpP9gvw6u9H9MnDFQJEPP02VVTQsK8ibMnFjjPT89HMwZfcsXJpds+xeHs9B+xukul0Agi1yS+P5GHB7NMnlm1BrUm3HSy4nhaUuinK1fK3KSrn1ZqI09aUpxWks+966Pd1xA5VSHHLhlF50HPJuznbvcQfYHc6c+aC4a7sRfusku/D59g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DP1IG+WTVm1u04jGsFLzNVWcnRt3HJnH/v88KA45WdQ=; b=X2YpeuiQb5v6+hClrgkYPNUPySebGHbTcVQZpxUisZbkw3bOGZlD/8N+jug0YYx9TErGG1cHewyeojNZwsQAXrqXV87bpAsLyaOGSNtanRyOICGMsmHKFv8SndcnVC17cJ7hwcyCN7SVnoOXla9tyBMW1OaIPI6877WNUBZcPiwITF9rIvkvpqfc1eFRBvHQ6RYYyq/5guUbqU4hv8ga2e6fiFfS1x1do9/WYBm6C/4vIfdOR8W97x5hLhZAk6tAqC2JLxjF98CL/rWTL7sM1HN7dG8ALLJxPgip+8Q9qB1iaO6ysgOhOOpe9+pOVxXpBILXIEBzPrDya5nXdAwqWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=azul.com; dmarc=pass action=none header.from=azul.com; dkim=pass header.d=azul.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azul.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DP1IG+WTVm1u04jGsFLzNVWcnRt3HJnH/v88KA45WdQ=; b=kn0R2iVJYz7iinfBM+HfQFR2L7iGJ2HDMvUxRzVhmex6+UHzaFMkecrTCyuFA93CRGu1z8A8p4zCXQLwyiSlUS25k1iCeJPUzT5sXaeNzwzD6aowkp6GE9imKxpSGLBe4R2DeSvGD3b8fxX8pBcfJfvt1pyjU+LKDYJmfYPngmbWLXCvTLUDNdaNNozzirvje2LFpzfQyWnOnqySlS+VNMK7CFgUyeP7pNoYWJIgU5GwkGd1dv8o5lR8SZnrZnn67u9LMAfBvd9b9SP3+/PtMgaji3snaX8MqKj9zcbBtdwM1ednu1iMS/BtMazpNBKfzjVCzEs5Tw0l52SKzUGsOg== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=azul.com; Received: from DM6PR11MB4073.namprd11.prod.outlook.com (2603:10b6:5:19f::22) by SN7PR11MB7592.namprd11.prod.outlook.com (2603:10b6:806:343::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6178.31; Thu, 16 Mar 2023 14:41:12 +0000 Received: from DM6PR11MB4073.namprd11.prod.outlook.com ([fe80::8476:1cf6:afeb:c285]) by DM6PR11MB4073.namprd11.prod.outlook.com ([fe80::8476:1cf6:afeb:c285%3]) with mapi id 15.20.6178.029; Thu, 16 Mar 2023 14:41:12 +0000 Resent-From: Jan Kratochvil Resent-Date: Thu, 16 Mar 2023 22:41:05 +0800 Resent-Message-ID: Resent-To: adhemerval.zanella@linaro.org, jkratochvil@azul.com, fweimer@redhat.com, libc-alpha@sourceware.org, akozlov@azul.com Date: Thu, 16 Mar 2023 15:38:36 +0100 From: Jan Kratochvil To: Adhemerval Zanella Netto Cc: Jan Kratochvil , Florian Weimer , libc-alpha@sourceware.org, Anton Kozlov Subject: Re: [PATCH] RFC: Provide a function to reset IFUNC PLTs Message-ID: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <676ee95e-9981-a0cd-36b3-231b64b82673@linaro.org> User-Agent: Mutt/2.2.7 (2022-08-07) X-ClientProxiedBy: VI1PR07CA0215.eurprd07.prod.outlook.com (2603:10a6:802:58::18) To DM6PR11MB4073.namprd11.prod.outlook.com (2603:10b6:5:19f::22) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6PR11MB4073:EE_|SN7PR11MB7592:EE_ X-MS-Office365-Filtering-Correlation-Id: e0da4a03-2b92-4370-2123-08db262c7d0d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 6eqP3iSxtgnPNynOjTlpBJriWEgXSABQ4OmkrxlJ0gvdJnqz3933+gPziNM8K+2QKlLxttvrF7/LFEep5FpETlNmOGRDf8aOP0ub/YJZ4G1ySbNYq6i8g4cSLDAOTZ7t1/Z41M/4B2WiXpJpI8/LOMO+/0P2r40xaGf1dxZQLml/2bOt3INch3ZS/rFKszB5MQcih1rhb8jk0n6blnGuGir5Emk+VIYx9iFuMoDPWM2SaedOZJakF2dMwWcV/cQMWB3tU42am8IMSv0QXrSBwFtuBuXTAR8JQnZrU4Ap6r0LfIHlfVtE7d42IdCmrNAVM36Tx+2tO3CKXzbQHHszjqrbJQu6//A262exIGI9yRwFxgjxAFipeuN6wfONmEVgsYrHEm6gnBbSTlnEi8UZBGLWqhllrY+JsjsJxiDo654A38qZ0GBYGcyr+1G95NABhQKvaKjhiZeV0CnzbZAelrxdbw5xabNadm9PEjLJfIMj+HWqz/CMswZ4y764IpHkGsox7s17jBPmtQ+Xo65uklr0WPZxLYGTWH8V+SHVWz8wjU0uWC7ctlYz3uTack8aMmT0Lkcp52NU7wmDb61amfdZUO8j3xg7c6bDIHZ0uEi8A1lRRKjOCYcHibzTjZfX X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR11MB4073.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230025)(4636009)(376002)(366004)(346002)(39850400004)(136003)(396003)(451199018)(38100700002)(86362001)(5660300002)(2906002)(41300700001)(4326008)(8936002)(6916009)(186003)(6506007)(9686003)(83380400001)(54906003)(6512007)(316002)(66556008)(8676002)(66946007)(66476007)(478600001)(107886003)(6666004)(966005)(6486002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?wC6WSzIKVPFYNlCu0QJHNT7GigYwgiL8Cl3+x0M7o3FkI6HS+7K7TnE+8E7h?= =?us-ascii?Q?kztshVb7ujznEK/zx6kEtPXVeGLPrVgHLoAqLFt3Lzny1eswOzZIe+hJ84EQ?= =?us-ascii?Q?fTGFDUahWaoe/9GZ6g59i3jb1s3z+bwHwEr2W8XhubVK1RWjmX7qjvZEpRYC?= =?us-ascii?Q?kPVl/nL1NcoBOLMi/MlKQMDCkQ+Cu16oOZiES+V6i9eZ/2/8SsKdRCIm0dQ4?= =?us-ascii?Q?XgoAcVgSqAYhZMV93myvrw5OWJFMZz0J4KsMJ4olhbPtONSDBolDH5h3b9w3?= =?us-ascii?Q?n0r1OOJRenQPhMFPmmoRjN7iA1hucv8wbtXCiZebEsR/p/L/NAyXwmuq80jY?= =?us-ascii?Q?2zNAOK3PtO+fRDaX4x3P48m60vXJ5fLn2YCJ0LbC0IYxbFwVntaQCSjIXWvu?= =?us-ascii?Q?PKIHO1JfHfkxnNE1P6yGWLLaCU561f9AyqqXN7j+fg7Y4Aj/0HdCJz194Rjw?= =?us-ascii?Q?foAiLi0aFp8TpbgetbFz3nrLLHOc+dYe2Kj2cHz53He1Q0tMWHa2kECbU1ZV?= =?us-ascii?Q?Or7KIg98pMPoqmoCa60abf26b7Sfzlfd+vYbt7YsfEbZUgZbS6a+ZTdvMiPK?= =?us-ascii?Q?z4E4Im4Am861bioiLXbTk1zAZxEU1Hmdi50PimcjUcMf+1nMLvC6Ka6wmfCH?= =?us-ascii?Q?MF8QPsrCjb4hJhLUke87F6w9Zxyj374HwP3LXpiJM8HAKhxLFspxT1xb/jLv?= =?us-ascii?Q?/CQbIqwrp8/QY/RUQrirZZAF+uqI7F6jjGNwELRWXUqMLR9Di0TY8jOmdVnh?= =?us-ascii?Q?EmP2DqcZIFAL3RRwwQKvCUJKVGuhzCeEWXyfcBF9meWcg24hBUTFNXLlDsGQ?= =?us-ascii?Q?YNEVr6IfGqB+BT41Jbr7VtxE7J8EHGynDfFpN7JCMwS2htUVYChYILrys9Q1?= =?us-ascii?Q?fXZHPZaWzefLA0zfP55XLfs5XrilcOjTyvosxtpxgymbizitYNRjhNcTZ5Ut?= =?us-ascii?Q?cKAEgYnsszcqiyjqsRYHloq/0GXrcDObFL+UgQqORS8faTokmVA9s4Vuf3fS?= =?us-ascii?Q?ai+rchWnRb7yhaw6H7/Lqk7lbbQrQ0SnQtJN3Cut3UNFd9WLt4echaZKfAGS?= =?us-ascii?Q?xu/lLSNCPHNPuqVo25H5o9BIzY+lK0Hk4nAVVOSegbxK1L7wzklJ3q2bSxt8?= =?us-ascii?Q?8hGCrdVNN/Mo9iZ8f2haq1yl5V0r7CWgQf8cwxzVzDLSLWhop44LzhOe0KwK?= =?us-ascii?Q?6pdyxAPtR4r7IF66DqAKZrwaIVtPJhtlolzuBifvaiXQ3q1/z9JdZzqMbfPz?= =?us-ascii?Q?dcDgNndvVBxA7YsLPuoPHm2kyToWWSitxnMncSpQAHaaxxdAEDBpez8oFPyn?= =?us-ascii?Q?zkvEN8qUb6wNAxTQEGJssyFqepEJxDGAdc/xUJONqA+Wy49OJx77r4oFVRLA?= =?us-ascii?Q?noU7MqCmL3c2vJaJ8BJ7MT/J1DpY1Ji6xR56+z37oEPjyx7fn0CErp3uB8JX?= =?us-ascii?Q?VkAx+KHVkVJYVBAy/A51VPMXjrRzYWi6waVnvD4iaPFjf8kewZ/q6AtTLJgB?= =?us-ascii?Q?hnmYHFjmNUQsJPrP78yWCO42d6Yb+RFJAK+V+jHdHdvJc3sPimR83IK1y+nL?= =?us-ascii?Q?KbVjfXaDXIntZ/5EbLz+oUirnL9LxzTQRc2rTV5J6OZ1wVJABSRHba3RkFwF?= =?us-ascii?Q?hQ=3D=3D?= X-OriginatorOrg: azul.com X-MS-Exchange-CrossTenant-Network-Message-Id: e0da4a03-2b92-4370-2123-08db262c7d0d X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB4073.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Mar 2023 14:41:12.4454 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: c480eb31-2b17-43d7-b4c7-9bcb20cc4bf2 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 5JeFsSH1mDZeozBIpWmiSfufX2GFy8R0UcrWTGQVfawmzlyI7wCm8qttk3dAg1attMgH/ODF2gLaj1kLHv+8eA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR11MB7592 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FAKE_REPLY_C,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 09 Mar 2023 16:47:49 +0100, Adhemerval Zanella Netto wrote: > I am not sure how the kernel would enumerate new tasks that are created > while iterating over /proc/self/task. I have updated the code as you have found a race there. Now this is no longer relevant as all known tasks are already verified as stopped. So there is no more running task to create another task. While iterating /proc/self/task: (1) either there must be already an unstopped task when opendir() was called, in such case the iteration of /proc/self/task will be retried anyway. (2) or all tasks are stopped and therefore no task can create any new task. > On closefrom Linux fallback we have > a similar problem, where the code iterates over /proc/self/fd, and everytime > it closes a file descriptor it lseeks back to beginning. It works because > eventually there will be no more entries on /proc/self/fd, so either you > will need to certify that kernel adds new tasks at the end of the getdents > call (used by readdir, or lseek and keep track of all tasks already signaled. That is not needed, see above. > While it might work on the JVM where you can not fully control who change > SIGUSR1 disposition (and I am not sure JVM would prevent a JNI call to do so), > so you can't really make it generic without explicit reserve a signal to do so, > similar to what glibc does for SIGCANCEL and SIGSETXID (used to synchronize > setuid functions over threads). Meaning that callers of sigaction can't > not explicit set such reserved signal. > > This is similar to what we do for SIGSETXID, so I think a proper way to > do it would to do always install a new signal handler to this on pthread_create, > on signal handle synchronize with proper async-signal-safe interface > (pthread_mutex_lock is not, you might accomplish with sem_post but most likely > you will need a atomic+futex way similar to a barrier), iterate over all > dl_stack_used (so the interface can work without access to procfs), issue the > signal handler or each thread, operate on the maps, then synchronize to resume > threads. We can't really make it generic without accessing the internal > glibc thread states. Good to know, if the patch gets a serious consideration for upstreaming I understand the signal number needs to be handled better. > And you will also need to reallocate not only glibc, but potentially *all* > libraries (since ifunc can be used by any function). This is what the patch already does by _dl_relocate_object(). > > So the only remaining option is that all the programs will be doing > > setenv("GLIBC_TUNABLES=glibc.cpu.hwcaps=...") and re-exec(). That is > > a peformance kill and definitely not nice compared to any method of an IFUNC > > reset. > > Assuming you don't reset env variable on process spawning, you can set it as > default for the session. The /usr/bin/java program needs to setenv("GLIBC_TUNABLES=glibc.cpu.hwcaps=...") and then it can either system("itself") or exec("itself"). This is what you mean by the session? > Another option would to deploy a glibc built with > --disable-multi-arch; it will disable ifunc generation. That is not an option. OpenJDK must be compatible with normal existing Linux OSes. > And IMHO this is way nicer because this IFUNC reset as-is, without a proper > stop-the-word support, is not safe and adds another corner case for the already > over-complicated ifunc interface. stop-the-world is already implemented modulo possible bugfixes. https://github.com/openjdk/crac/pull/41/files#diff-aeec57d804d56002f26a85359fc4ac8b48cfc249d57c656a30a63fc6bf3457adR6029 > > In Java world the other libraries (in general, there are some JNI exceptions) > > do not matter as they are a Java code JIT-compiled by JVM. > > And this won't be a Java specific interface, but rather a GNU extension for C > library. So we must make it as concise as possible, without adding any other > security or undefined behavior. I agree. Handling IFUNC for other libraries is also possible but it has to be a next step. It does not make sense to handle IFUNC in other libraries when glibc still crashes first. On Thu, 09 Mar 2023 18:43:08 +0100, Adhemerval Zanella Netto wrote: > And the 'handler' signal handler has some potential shortcomings as well: > > * backtrace is not async-signal-safe: glibc implementation on first call > issues dlopen, which calls malloc; and libgcc_eh.so *might* also calls malloc. I do not see it in practice: Temporary breakpoint 1, main () at backtrace.c:5 5 backtrace(buf, sizeof(buf)/sizeof(*buf)); (gdb) b dlopen Breakpoint 2 at 0x7ffff7c88f20: file dlopen.c, line 77. (gdb) c Continuing. [Inferior 1 (process 825695) exited normally] And neither in the sources: glibc$ grep dlopen $(find -iname "*backtrace*") > * pthread calls are not async-signal-safe either. There are no pthread_* calls, everything is based on kernel tasks. > * it only handles libc.so, other libraries that uses ifunc for function > selection also fails. You are right, I have mostly implemented this hard-coded "libc.so.6" to make it general (for any libraries containing at least one STT_GNU_IFUNC) although I haven't finished this implementation due to the last paragraph below. > * the syscall heuristics do not handle partial results (for instance if > write syscall returns do EINTR). I do not think EINTR would matter. The syscall heuristics is there expecting that any library function which contains syscalls is not an IFUNC function. > So this code has the potential of deadlock, specially if you have another > thread issuing malloc. I may have missed something but I do not see it so according to the answers above. According to the other reactions here I doubt this functionality would get accepted to glibc so we have decided to give up on its upstreaming and use the setenv("GLIBC_TUNABLES=glibc.cpu.hwcaps=...") + re-exec workaround instead. That would need to be coded for compatibility with existing/old glibcs anyway. Thanks, Jan