From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from CAN01-YT3-obe.outbound.protection.outlook.com (mail-yt3can01on2064.outbound.protection.outlook.com [40.107.115.64]) by sourceware.org (Postfix) with ESMTPS id 4F5D9382CC40 for ; Sat, 17 Sep 2022 11:51:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4F5D9382CC40 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=efficios.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lsk94V3CBHlKGQFgIu3hRWDw2vvyYbrF3z/GiMXKxo4MyuxHzdI2YqosfAvQYxIIe+69M2/s/S1NfLYDirQQSBA40y91stjRWfmxpCgGU/YskBSNejpFw2ofT8utJj5BonXP6MUUj5l5Dzvu4FVlp/jS9qMPPGDlBBeUrWICyESWfaER3T5zo6PUftLLcDqiDuuKn89JHdaDJQw0mPG/+e0dNvumDJkUhrGWFMEWXmRapvtioRhy2mXLfSW437H0wnJdWTLaq9fv9zV9DKtXmPAsrljhJugMv+sZQ8yaoQGbjlEBvFMhbU5+YktF1pThdXjP5DL0/ba57Ic7eESBxQ== 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=4TvV4AuTWJ/SkSz2wYsXj40t30YFZdSU/Ko7X1orsQc=; b=Rj4bfIrOnqeJq8lH2lviJ4SZngY+pkoc8mja54RjpiZrabMEguy8SCkYcxZFc5krAUK9Xu/rkOE7OHwIaDUBf3GKl88nU1EzHbrxhDbY4JgjMIhL25gbf1ngTXKiD1f0UoV0FGbEgvOLryIyvL+jESkuzLY/BfLqsB+tNx+b6ADVbbTyZwZHsDp2LxGwtF4axsogimBocccTkJNf9a77Kmmn2A7K9I3JMSQ897eK9h0hnjFRDkxQRC7Wk9CHi7d/W+0qpVIo4TEhZGjJWvTWmWy4nVOL1nCrv7+JMLAAu6HeyqtIvYHihed1IWTC0q0PN1n/yYgV75DOluRJuKi7nA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=efficios.com; dmarc=pass action=none header.from=efficios.com; dkim=pass header.d=efficios.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4TvV4AuTWJ/SkSz2wYsXj40t30YFZdSU/Ko7X1orsQc=; b=B+KyGns2dG76hBZYb3ChsQrVjmIKnWaqLDg2INFi9haWT6drcpA437q89XZxxocHvrUqH/xEfH6MFIR5isML2EIa/5utvW0AGz8WH0pR8kMAMokpUaAW7V/e3qeMBWUXRDlkj7WMgeHndKjBKF1keisHFQ9mgct+jFfbB1TBDgZ+USFBCdtYdd4j99I95DV/ywYGGgwX+Hw249HxXKOrgPZ8NqNS1sOPBQxwumegJARpRdxz9nTrtEFany2cn0Rj1Q56is38jtX9pxknHaT6qY5Zp8IRvgKsJWHU6WHQJpjBaawtN4DV8MWzDTmvCW7+VHNpke1Ykfu7yBdc2m3osg== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=efficios.com; Received: from YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:be::5) by YQXPR01MB6589.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:43::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5632.17; Sat, 17 Sep 2022 11:51:04 +0000 Received: from YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM ([fe80::bd25:7243:1b45:3fb9]) by YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM ([fe80::bd25:7243:1b45:3fb9%5]) with mapi id 15.20.5632.016; Sat, 17 Sep 2022 11:51:04 +0000 Message-ID: Date: Sat, 17 Sep 2022 13:51:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [libc-coord] Re: RSEQ symbols: __rseq_size, __rseq_flags vs __rseq_feature_size Content-Language: en-US To: Florian Weimer , Chris Kennelly Cc: libc-coord@lists.openwall.com, "carlos@redhat.com" , libc-alpha , szabolcs.nagy@arm.com References: <87y1uj49t4.fsf@mid.deneb.enyo.de> <87fsgryphl.fsf@mid.deneb.enyo.de> From: Mathieu Desnoyers In-Reply-To: <87fsgryphl.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: VI1PR0502CA0005.eurprd05.prod.outlook.com (2603:10a6:803:1::18) To YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:be::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: YT2PR01MB9175:EE_|YQXPR01MB6589:EE_ X-MS-Office365-Filtering-Correlation-Id: f2602a72-77e9-4e7b-4923-08da98a2e66f X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: cFBN+PvZkX+OBK9GfjBCARpA1P7pET9iujI4KD77e7A3u0/o83WTmAcd6vPHU4q6G7RkkZ6dXNTra0einojTJkEne3zngn43LuB0kiTfN4tQFtUFwG5kfYi68DDEXesuflfLe/5w5vzReZoGZb88afv10rMDXkke2bfERpm7HNl60Oba4ZfHJGIhcGXskhoFqAljOQnzhOcAhV+JB1i20YO/6Nio1mkXQd6JM+fSc7G2y/r1pThIq2BXCb7QSls7wGY94VXjugDO8wVJ1VA+fKgd9bcgUs0JkzJROgEjPIsjqBAv6/7ZWywVIf5bh79yppFynz1ENCKeCaFsgx63mmzAgEoOJDmpiDUbLBWZBxGoond+7XqxdszilWKQrCdNfw2JWz9BmmTRtzIyIbxVfbwd8yWphEqoCFkF0m6RxYkG83Nk7V8SP6Fp4zfJPtnSFNj/YQl5iFJOf+H7jMJdkkFrcqlzwy9RhfcHx0U9c7v9LxZTWonstEKoA38t5zug1ZC8VM9VHPoxwE+Sa43sMMM9btUD9zAAz+wdPg6HJk9YHvxjAzEh0nR68c/rkFqneozA+MaCTUSjxhr2aL9/jPrlDEjPmn08vsT2ObYp6m8WNU/fSi9Em5QfUguDAFkzOVglj7hwVhQB6Bcd7QTJRwt6wdDe922xbw1r3pbV4M211kTaB20bB0kJYGOtQSS89fLN+CTLHQBVY4Xuf0EJuhecuk5+Bs3a9TccXf9HM1cyk5Sh6RpzMEjh59xPNk+vs+XVekCBpj4JPMf+k2CwxZclvgXTLlANSbRTAeLj60u41LDgk8MTDjy/fQZyY6jf X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(376002)(34036004)(39830400003)(34096005)(366004)(136003)(346002)(396003)(451199015)(31686004)(53546011)(26005)(6512007)(6506007)(2616005)(38100700002)(44832011)(41320700001)(966005)(586005)(498600001)(6486002)(2906002)(5660300002)(86362001)(36756003)(31696002)(186003)(6666004)(38610400001)(83380400001)(41300700001)(4326008)(66476007)(66556008)(66946007)(54906003)(8676002)(8936002)(110136005)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TFFmNCtyNTlRbjgwNEdvdVBqNkRWcDVBMXV2TkJMTFJSU015M3pNTitxcWp6?= =?utf-8?B?bDZWTGdvUW5lNjVDbnpuMjA0MXpaeG44dkhyalB1Y0JTN2trMzJVVWswaVov?= =?utf-8?B?TGVJN2gyVG9FUGdkdFhQbXJTMnpJeHVzdkhXRy9wdlR5a1ZnQThZdkgrakc0?= =?utf-8?B?SmlZSEpTdW13dUdVZE9JMFM0RmFyQXM4ZVRJMlFpNmJkQzNHeUFRNkx6NzFL?= =?utf-8?B?VWxTSFBvY2JrZks2VEExMG5peDF2VGR3bHNaSjRFRmRIbGRZRkUrOCtvYjA2?= =?utf-8?B?MDdkYVNoNzh2ZTAwMHdaWGo2dmVmdUQzL1dneUQvSVh6aWJVQzIzRzZocmFm?= =?utf-8?B?WXgxZm9yaEJqSzVOMzh3dmErVk80ZnU1VHhzT25CUUdSblRPTGNmSHQ1YmxS?= =?utf-8?B?TTJMbmxTTjcwcE9yUmFjUDFsRkMwMVlTRHRIV1kyQ0V6d1NYLzloV1NUcG9G?= =?utf-8?B?WXd4N2VNK1AwcXMvbEVwNFpNUzVoQ3pjSi9zMUpNVU1Bb3RzQzVSTENSYjhD?= =?utf-8?B?U0VDWHI3UHQza1VHY1pyY0t1aE8zc3lIdGxvaVJCZzZwYk51OFY4Mm5CTENa?= =?utf-8?B?RnpwdXVVWU56RVNDM3N6STRmZHcydk1ZTkdaeDZJaVRBYjZ2RDBkQ2RVMDc5?= =?utf-8?B?WEwxYTR3VXlwNE5CYWJkTW9mNTJ0cWhLS0RRVDJVcXhyY016aU9GRHZ2Rnp2?= =?utf-8?B?cUJQblNVUGpLZXRRd1gyWTR3M3U0K0xybm5sbFZxWXlWZzVSeFppTWVDWE84?= =?utf-8?B?eDNsaHZhZFJVNTYvSTFoL3gvSmpUbFRTaEN2d2ZqdUF6R29wNlk2dmFpZDJS?= =?utf-8?B?MXVMN3lQNUdyVWZOenpuUUNDOFdvM1JkaFk4K25tUWRldlNsKzVRUGJWZXdV?= =?utf-8?B?TGJLZjhaendyZVA1K0tEdlM4U3A3bXpDY1JNUGdlbWdtdUdTRmduUzFXVXh4?= =?utf-8?B?RmlSdVFscTR4WlFjK2sxNWVwblQxRnpaM3lsVHJDd3hXODlQT1hNMEVLWGZI?= =?utf-8?B?ZS9acnpDY3VRcmZhM2dtYnVaT3lqcHRBaGVCMFUycnFleitldEYrcVJTS0Y4?= =?utf-8?B?STYra3hJQ3NKSUR5eHpBTENIVVR0K2dHeHpzRnNHNWg1LzlNQXQ0R2dWK0dw?= =?utf-8?B?eHRCUTFCZUlVaU9ENDUrWjdEUS9LRGo2WWV0dHI1OU5pZ2RIT2NRd3ZNWHox?= =?utf-8?B?VmphNis3WGpWaTBtbFM3L050V25idWpFa1llQkdjTzE4NFFKdW44SlMxRWNN?= =?utf-8?B?Nm9xajUvRFd1VTIzMW9jTTBvNVkvS1hIb0E4SDRLWTBzZVJPQmduVFB2SU0y?= =?utf-8?B?NWJ4dTJBcDJ0WVR0MHF2UFdPTk5kV2JlcmVCMVByOUJMK1FkcU1zbnJQeWhs?= =?utf-8?B?MUphR3RYWVhOYUt5U1ByVHgrTzhxbWZmbUVtL3dQSEFDd1grU3RHeFk1ckFO?= =?utf-8?B?TDl5STFVd0hwSHVWZFJ2LzFicnlQcm9yQ01aNXhkT3hVWmRaUVdhWmtlS3gv?= =?utf-8?B?UHdPQ2x2ZVJkRlMwLzMrRGRnVzZNSjFhUG1rVWZxdjlHNVpUdjhLUEpQRnBH?= =?utf-8?B?R3hpL3ZVSU54TkZYZTZaaXdMSTVOS0tkR0RFaTk0TEllVGxPbFJyQTdVT0Ix?= =?utf-8?B?QWVBU3dJNkxBdC9kSWpqNDZMSkhaQUY2bU9DenJ2blZ0dnBvY2lCTHNRWXJS?= =?utf-8?B?ajAvaHJrWU1EUmdiK3kzQ1lmdERoSEI5WmRVc1c3Tk9qYzFQMmtMSkdpYUN1?= =?utf-8?B?Y1dsVVNicjdEcDdxM0lsY3ZvQUhwa1Y4UktsY1YvN0tzdXA1Y3dBa2N3RS9k?= =?utf-8?B?TCtpdlI4QmpPMWQvU2VYeW96aTRQc28ra01makRMeXEvYk80eGxrZEhrUThB?= =?utf-8?B?YmhQRXh4aEJNaVJ2UVlKMDZBbDhmVUp4RTM5SWJWWlVUZ0RBUnZaK01xL0pm?= =?utf-8?B?Q1JmSGdWMGtWT0tGT0FFeW10OWxEYm80Q3B3ejE4UkRORENySnRLcXNpQkZh?= =?utf-8?B?cXVYQWRxVDVpZTU3Z0JWbGcrNVVnY0dRbnQzT0ZpSzR3QnVmUFNkQ2h4cGxk?= =?utf-8?B?aG55SFVWbVNxbmNWaElRaE5HR2UySEYzeTRzdWtRVm5iNmNUTE1UaXk4aHdW?= =?utf-8?B?U0pkQmZBcUtEbWM5SU1hZ3VJZEJpRmp1Q0Zwd2F1N0poNXBORDRnSGZSTWhz?= =?utf-8?Q?x1cDvZHpq4mps7YPPFile1o=3D?= X-OriginatorOrg: efficios.com X-MS-Exchange-CrossTenant-Network-Message-Id: f2602a72-77e9-4e7b-4923-08da98a2e66f X-MS-Exchange-CrossTenant-AuthSource: YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Sep 2022 11:51:04.6552 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4f278736-4ab6-415c-957e-1f55336bd31e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: aoLdaPEQCxq/eQKC6KBRJlqgC4zv7mcgTddBAZeN8C1Kio/l43cia5W6h8WfbcwKPgpSSIbu8WFRk3zoZ+yK0UqPlgMoS8xvvrfSIFyHBZA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB6589 X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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 2022-09-16 23:32, Florian Weimer wrote: > * Chris Kennelly: > >>> If the kernel does not currently overwrite the padding, glibc can do >>> its own per-thread initialization there to support its malloc >>> implementation (because the padding is undefined today from an >>> application perspective). That is, we would initialize these >>> invisible vCPU IDs the same way we assign arenas today. That would >>> cover this specific malloc use case only, of course. > >> If a user program updates to a new kernel before glibc does, would it be >> able to easily take advantage of it? > > No, as far as I understand it, there is presently no signaling from > kernel to applications that bypasses the rseq area registration. So > the only thing you could do is to unregister and re-register with a > compatible value. And that is of course quite undefined and assumes > that you can do this early enough during the life-time of each thread. > > But if we have the extension handshake, I'll expect us to backport it > quite widely, after some time to verify that it works with CRIU etc. I don't think this is what Chris is asking here. I think the requirement here is to make sure that the extensibility scheme we come up with will allow to extend struct rseq simply by upgrading the kernel, without any need to upgrade glibc. (that's indeed a requirement of mine). So a new application and a new kernel can use a newly available extended field, even with an old glibc. Let me bring an example of what I think would be a *bad* way to do things, just to show how we can shoot ourselves in the foot if we don't consider evolution of this ABI carefully. Let's assume we expose a "rseq_feature_size" integer through getauxval(). This allows the kernel to tell glibc about the memory size required to hold all the rseq features. This is information that we _need_ to expose from the kernel to glibc. So if glibc decides to expose each new features through __rseq_flags bits (e.g. one bit per feature), then we run into a situation where for every new feature exposed by the kernel, glibc needs to know the mapping from feature size to feature bit before it can expose them to the rest of user-space, which goes against the requirement that we should be able to extend rseq features by simply upgrading the kernel, without needing to upgrade glibc as well every time. So considering that the kernel needs to let glibc know how much memory to allocate for struct rseq, a getauxval() "rseq_feature_size" is needed. One approach we could consider to allow extending rseq features without upgrading glibc would be to expose an additional "rseq_feature_flags" getauxval(), which could then be used by glibc to populate its __rseq_flags symbol without prior knowledge of the feature-set. This could accommodate 32 features before we need to expose an additional __rseq_flags2 symbol. Exposing a feature flag from the kernel through getauxval() would have the advantage to allow the kernel to "disable" some features in the future, e.g. if we want to deprecate a field. This comes with its own complexity though, as user-space could then not rely that when a feature is present, all prior feature fields are necessarily present, which therefore makes the testing matrix more complex. I personally don't see a need to deprecate rseq fields, but it might just be a lack of imagination on my part. If we want to keep the kernel ABI as simple as we can, then we just expose the rseq feature size (and required alignment), and don't expose any rseq feature flags. This in turn means that glibc would have to somehow expose the rseq feature size in its ABI. If glibc decides against exposing this rseq feature size symbol, then it would be up to the application to combine information about __rseq_size and getauxval(rseq feature size) to figure out which fields are actually populated. It would "work", but chances are that some users will get it wrong. It seems simpler for a user to simply do: if (__rseq_feature_size >= offsetofend(struct rseq, vm_vcpu_id)) to validate whether a given field is indeed populated. The rseq feature size approach would scale to very large feature numbers. It would *not* allow deprecation of fields after they are published, but I see this as a gain in simplicity for users of the ABI, even though we lose a knob as kernel developers. I think it's important that we consider both the kernel and libc ABIs if we want to make sure that we can extend the feature-set without having a mandatory glibc upgrade in the way every time we add a rseq feature. Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com