From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from CAN01-YT3-obe.outbound.protection.outlook.com (mail-yt3can01on2071.outbound.protection.outlook.com [40.107.115.71]) by sourceware.org (Postfix) with ESMTPS id EBA5E384BC2D for ; Fri, 16 Sep 2022 14:36:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EBA5E384BC2D 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=Q33si7XzNOs9YRSvjUYWBjZFm+VOz8JmU1ZF6mkCKwwMp9Zl7Vv2Y4xcumLZxzevp/gJ4OPF6abNJG6up+pi7rITDnFzSklUi+ynsUDQdXmglCm88wrVEu9MyLKv/2ZapNjK/DPyXelH3PjBTaONVhf66xNx5nsnfPnbemQ+MDQDNywZHG3YUfBaZjF95rC0YJFIucbWtOQpH7JioqSVrsd7y5S32y2/YpVveUHGF7vKuXf+JTtHAU6m/N+hKdpWQFNjMWRjuaYTlVfPprkSOehq76vvCfoyx1oT73Jb78uvbypa+1W/VredEubtSEXBtmZ0fyixTS3BX1kJ5rfSNA== 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=/0/OY1iAHMDYD2iUrMmNVDZwPJhfB5mgmH/iWDRK6iU=; b=Tj+g7aNyJL+3nVi076PKb8HvUqjzU7bMxxwuRD2xSNYEDpgJlrq8AtyNmbaD4fISYXj4C/yFlDm2ulTn9CCPcEo9nKGEc3NOcboaNY4uHWfI9H/vxHsjw65SYgjagRDJnVu1C7707kXWKESkjbY+ItVFqfGwTv6LnQJ1NNv3AniFcm6B4A+HpWJx/aR22xiMuitAkZw5cdlEbhVlvr+QI9TFacrVSTrefJEYVaIKNuIvQyUcEB/BSY1TavJMXwxKRIh+uJjER0Y1PxiWMHVT8xlWSIX1m3bvdXMhRq/7PonbqUhH2JkGNbmQ9bNmHeTBlDsbAXqCfdYiW8XwnzkBNg== 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=/0/OY1iAHMDYD2iUrMmNVDZwPJhfB5mgmH/iWDRK6iU=; b=c0g9JTKkxRWO4ftqyZM4txnYZNgBt/TooxtgXdLkUM8xwkEhk1rG5MokFDlZVtfkFHAALld4gSswKtuVWLUqmeBOrirMam+N8/ItT+TPuzpH5xO6RP3nDLRroYB61zExadRsE/1QOqSqxdtVkCjTZqCBx+/WuaeYTSr4RjOU4ZhHBnq+SPsLl8VK03Ci3Q66/aZ8fP72Ym08twJ+C4vnjM+sJDOo4/gn1LD5vD87n8tDIrAGlLZrUcjpKGBETSmrqYdCUAJ/xPsPhy7JtU+U4uXSkkcc2FPdrou4hrWNAzhu3w+nQ1ggpGOiU0mbU2heQKOH65Lb/b+AE5JGQppv6Q== 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 YT2PR01MB5951.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:5b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.21; Fri, 16 Sep 2022 14:36:07 +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; Fri, 16 Sep 2022 14:36:07 +0000 Message-ID: Date: Fri, 16 Sep 2022 16:36:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Content-Language: en-US To: Florian Weimer , "carlos@redhat.com" , libc-alpha , szabolcs.nagy@arm.com, libc-coord@lists.openwall.com From: Mathieu Desnoyers Subject: RSEQ symbols: __rseq_size, __rseq_flags vs __rseq_feature_size Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: VI1P190CA0044.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:1bb::16) To YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:be::5) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: YT2PR01MB9175:EE_|YT2PR01MB5951:EE_ X-MS-Office365-Filtering-Correlation-Id: df0b2d56-b2d5-4279-a1b5-08da97f0ca77 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 7azIo2Fls0OtqaMNQkOaSphH5O+Ct64oJh3cEWbL/nmoLWTwr5bNs2+gJKWMtXHXA7RKnQcsQb7/RLyeo+lJ0iS5h1ZddXP4UGNswu0AiTSsvc2mxg64yEIA0IHkkeRHqxZebKER8ZaD6A/WfT1BZ6jzne8c0qVwTQVhJVuFNmu9OiTszEo4Mz2j6R3CqmOI6FbI2d3dsb2sdz+SnKo0Xu2nO+VWSsVuzBRadt9CIBkfSi6UQQ4jxg67mwgsMuetK6W/JpEFdg7ZUsoGPxOXdAGsysOQDQMn21koU+Uv6LUV3fYPSJhCbrGTomHe7DZjb4GVa22wnzwICOdiJEcwAqIMOMxvLoa1hFTGg7tp1GVKNMQERvxcFsQt3pv5gPznFcH0LdZYkwO0hBPCAmxwTWE/+vtKBxs7GgosvXTooYPY70JDUcuJAULMCu2Kr9Ex8qZo0NsU3o6iBOk9R7qauBHUAL3ZyDU/MUGs2DMIUN4WndIjT8esFdvJISkKPNpfzVZMHEGpVAnYHIkg/S0etkP8N3igxy/bcE1yYJM8frDGdMI+QLYliHrUBEX+h/ySqWJhzlGQ3kwJv09wrEY7d8QVm5qUyUyNvfCaqFue//iqQbVEx5VVJtCek3d8FpGf4n5nk/mr9x/cR5Z5q1aIoaMlROJJdtZh8mv41C0bK5wEgqncKSvxDCtCi67l5k/nKaumLWwQr4VsT6ITiLbcJ7M5OZzYPvTRh1LBVngPnoKy2Eq8i2EFlDl6GKtfSkPVbsZXhEnIwNRoZtuvLJ5SePm+nrxpMOFCc/rYVPK8AxroO3r/3JR2zYBDw5vu1yZa 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)(136003)(346002)(39830400003)(376002)(34096005)(366004)(396003)(34036004)(451199015)(8936002)(31696002)(31686004)(66476007)(86362001)(41320700001)(6666004)(41300700001)(36756003)(66946007)(6506007)(83380400001)(2616005)(8676002)(186003)(44832011)(66899012)(6512007)(2906002)(26005)(5660300002)(66556008)(6486002)(586005)(966005)(498600001)(38610400001)(38100700002)(110136005)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bU8xMTVUT0k3TGdXSW9DNGF4L3NXbnJqVlNyZkF4SkFNVkRVcldXU0hScEdH?= =?utf-8?B?TlB3TzZUUjd0N09USkxUaU9TVHJxL2hyVi82YUp4ai9aYWxsVkVmaGVIc2U5?= =?utf-8?B?OEFnWmppek5PM1hMOFZJNkZIbCtzcDZsOGY3a21sZytTTmoyQ3QyOTVjVmxJ?= =?utf-8?B?cXlCejc2Y0I2Z0QwVjZ5TlFHMVM0TGkyZy9XSjlxNlJIODh3NnNrdUo4UzFh?= =?utf-8?B?WDUwVEUrUDZuaGk5MkxkbHY0Tldtd01DMFBIcTVPYnpXeGQzWmV4VW5JN2J1?= =?utf-8?B?QlJkY1ZGMnNaeWorM3hZK3o2R2pYd050dWErb25MbnlWVGo5TzFOYkZrYWdB?= =?utf-8?B?WER1U2U5UjlWRXZ2RHQySHVDbUpVeVFFdUpPMDdYVWF6T0d5N3drUTlRTC9J?= =?utf-8?B?amJtckhGSzlPdjRZb2dzUHJGeGd5MHVhc0IvblpuUThkQVBuK0FoQ2NWRGZQ?= =?utf-8?B?UFl3UXBUUmxYZ0RLa1MxQlhGRzRJZ2ZrLzRTcUR6NXRzdUpTTjljdDRpV1do?= =?utf-8?B?ZExpc1lUOFlIekJsWXNXaG1NYU1VaGhaRWlncFVVVjJ1OEo3czF3VHB3bkNl?= =?utf-8?B?WG5XS2M1K2lWUFVJeTJMdWFhVHpjU3VBMXNkeW5ybWhCeHZBYzRxZ3AyNkVQ?= =?utf-8?B?aUlkazRSM1RGWkNrWFdJczlsYWRvdFFvTDhIQVhKODlRZ3FWeG85VnlveEZJ?= =?utf-8?B?eG52Um9VUHMyaVpEaDhoSkJrUjlSMCtBVEJCMlJCT3RncWprcEs3VTNyd25K?= =?utf-8?B?YU1kalJVMGM0dlRXRm1FUDBXWmhaMjgxU1ZPL3hhSDBqZi9OeEpCTjlqUEUw?= =?utf-8?B?a3JNMlVLVXB5UUxtaUZDQlIyQTdlendGb2o4MWhvWU9QNGhIU1BNYTYwNXB6?= =?utf-8?B?TU5KWmt3Yk40REQvUzg3VDkzMktuWnFyUDJvdUZRc1FScnlTVXZkWjZ5QSto?= =?utf-8?B?L3RBRHEzWW9HMlF2MFYwL0pQNWxSaHlGYWUvT3NrTEpZTVkzSTBlUFRWVWFH?= =?utf-8?B?dWJzdGRlREZRTEkvdlpsSTVHSkhYNmZnUWhvY08vSml4SXMySFdnOWp0alJl?= =?utf-8?B?L0FXbXhmdEN6VnVERTZzL3dpZ24xTm5KeDBYZUgrRStFSGVITStvL1V5Nisz?= =?utf-8?B?SjdrNXNBWjM2NWdoQWNva3hNZkV2TU5WbDZMMWM0V1duVXVzMThWV04zL0RZ?= =?utf-8?B?RXVIU3Q1bDhrNmZ5QTdzL0ZySWlQakZLc08vVnFMcS9WYUh3a0RldElCMVZN?= =?utf-8?B?Z2d4R2NBaHpiWHN0RzZyU1RoV0tQbVhIQ1k0bll3Ukh0QkJoOXVzVzV2dHdW?= =?utf-8?B?VWN2OFA1RlNaZ0dnWmtDUDNQWlBkR0tsY0s1Wmo5aStYTUtwWndNT0MxbWZx?= =?utf-8?B?cXRPaVpDS29zd0h6VDhXTVUwMytVQ3B6Si94cEFzcmxzelJMZllQVjd3NW9P?= =?utf-8?B?dXBxUU85bHJqQUg5UDBLNk9TZXV0SEthQzZtR3g0cjFtdE1LeG4zT2ZQRTBB?= =?utf-8?B?SFFmNWR0U3JBeklpZW9mbmxGTGsyYmxJOHNnOGpIVjZZUVltakVNZzI0S0FM?= =?utf-8?B?WFZsa1RXQk91aEg5eThnR1QrUHhFUWo3UkxlZFAzTGdzMEFvU1pNZG1TQndU?= =?utf-8?B?MVZSMjFUVldKNGhwTVU1Z3JzOXpwS1NLanBZekhYb3I4aW4xaVJaUC8vSDRS?= =?utf-8?B?SHZiRUd0WGhQMGExWlloVjdsY0NmSE1BcFNWMGlJN3FQdjM1bjFxQU9KbWFS?= =?utf-8?B?YytXcUZxa2RRbHg2UVJSSHZxazZxdURNVkp6OFlua1Zsc1VTR0tTZXliTEEr?= =?utf-8?B?Q3dvWmpnZEs2QUpXekY3ZXVmd2RFUHliSVh2K0taemlBNUpzMkp6ZXA4VjZK?= =?utf-8?B?QlA1MnA0dVJSTmMwenJVOTNYSUlVU2tlR1haejVLYkE3OWNZT2lLS1ZMZURS?= =?utf-8?B?M1YyRHBadmdBL1U4alZrbDNVM2ZlUld4SEE0RmhTd1FrNzZ1WEc1U1RQTElG?= =?utf-8?B?dGZBOTY1VzVNOWlrTVF0VE1pMmZDZVkzanVpc1ZZK1VoZFQ0N25uV3RNdHlU?= =?utf-8?B?b0t5cHlkd0lyUDJkRUpFNkVvUEVKVzhJS1ZXYjhCK1BtUmV2ZkFKNmJRdkwr?= =?utf-8?B?NHhBdFB5QWxSQmlIdWd2aDN5ZzdZcnB2UFhlY1hOZDVWbW9WUGg2b0JjN1pp?= =?utf-8?Q?/GbliNfe+/iElgx3EABKeJc=3D?= X-OriginatorOrg: efficios.com X-MS-Exchange-CrossTenant-Network-Message-Id: df0b2d56-b2d5-4279-a1b5-08da97f0ca77 X-MS-Exchange-CrossTenant-AuthSource: YT2PR01MB9175.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2022 14:36:07.3246 (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: WWCIICQqjjLMu+00PmJJKmU18E+GDNsuFmz0j9pLy9a/RhBzDiPFnB2nusQDYyjFKLDltV3fzPry81y9psL4umwuTC3/1wFzSqHDMZiObWc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT2PR01MB5951 X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: Hi Florian, I wanted to clarify by email what we each have in mind with respect to exposing the RSEQ feature set available to the outside world through libc symbols. I have 3 different possible approaches in mind, shown below with 3 examples: #include #undef likely #define likely(x) __builtin_expect(!!(x), 1) #undef __aligned #define __aligned(x) __attribute__((__aligned__(x))) #undef offsetof #define offsetof(TYPE, MEMBER) __builtin_offsetof(TYPE, MEMBER) #undef sizeof_field #define sizeof_field(TYPE, MEMBER) sizeof((((TYPE *)0)->MEMBER)) #undef offsetofend #define offsetofend(TYPE, MEMBER) \ (offsetof(TYPE, MEMBER) + sizeof_field(TYPE, MEMBER)) #define __RSEQ_FLAG_FEATURE_EXTENDED 0x2 #define __RSEQ_FLAG_FEATURE_VM_VCPU_ID 0x4 typedef uint32_t __u32; typedef uint64_t __u64; /* Original: size=32 bytes */ struct rseq_orig { uint32_t cpu_id_start; uint32_t cpu_id; uint64_t rseq_cs; uint32_t flags; uint32_t padding[3]; } __aligned(32); /* Extended */ struct rseq_ext { uint32_t cpu_id_start; uint32_t cpu_id; uint64_t rseq_cs; uint32_t flags; /* New */ uint32_t node_id; uint32_t vm_vcpu_id; uint32_t padding[1]; } __aligned(32); unsigned int __rseq_flags; unsigned int __rseq_size; unsigned int __rseq_feature_size; /* A) Check extended feature flag and size. One mask and two comparisons. */ void fA(void) { if (likely((__rseq_flags & __RSEQ_FLAG_FEATURE_EXTENDED) && __rseq_size >= offsetofend(struct rseq_ext, vm_vcpu_id))) { /* Use rseq with vcpu_id. */ asm volatile ("ud2\n\t"); } else { /* Fallback. */ asm volatile ("int3\n\t"); } } /* * B) Check rseq feature size. Feature number only limited by size of * uint32_t. One comparison. */ void fB(void) { if (likely(__rseq_feature_size >= offsetofend(struct rseq_ext, vm_vcpu_id))) { /* Use rseq with vcpu_id. */ asm volatile ("ud2\n\t"); } else { /* Fallback. */ asm volatile ("int3\n\t"); } } /* * C) Check only rseq flags. 32 features at most. One mask and one * comparison. */ void fC(void) { if (likely(__rseq_flags & __RSEQ_FLAG_FEATURE_VM_VCPU_ID)) { /* Use rseq with vcpu_id. */ asm volatile ("ud2\n\t"); } else { /* Fallback. */ asm volatile ("int3\n\t"); } Here is the resulting objdump: rseq-flags.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 : 0: f6 05 00 00 00 00 02 testb $0x2,0x0(%rip) # 7 7: 74 0f je 18 9: 83 3d 00 00 00 00 1b cmpl $0x1b,0x0(%rip) # 10 10: 76 06 jbe 18 12: 0f 0b ud2 14: c3 retq 15: 0f 1f 00 nopl (%rax) 18: cc int3 19: c3 retq 1a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) 0000000000000020 : 20: 83 3d 00 00 00 00 1b cmpl $0x1b,0x0(%rip) # 27 27: 76 07 jbe 30 29: 0f 0b ud2 2b: c3 retq 2c: 0f 1f 40 00 nopl 0x0(%rax) 30: cc int3 31: c3 retq 32: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1) 39: 00 00 00 00 3d: 0f 1f 00 nopl (%rax) 0000000000000040 : 40: f6 05 00 00 00 00 04 testb $0x4,0x0(%rip) # 47 47: 74 07 je 50 49: 0f 0b ud2 4b: c3 retq 4c: 0f 1f 40 00 nopl 0x0(%rax) 50: cc int3 51: c3 retq I can think of 4 approaches that applications will use to detect availability of their specific rseq feature for each rseq critical section: 1) Dynamically check whether the feature is implemented at runtime with conditional branches. Those using this approach will probably not want to have the overhead of the two comparisons in approach (A) above. Applications and libraries should probably use their own copy of the glibc symbols for speed purposes. 2) Implement the entire function as IFUNC and select whether a rseq or non-rseq implementation should be used at C startup. The tradeoff here is code size vs speed, and using IFUNC for things like malloc may add additional constraints on the startup order. 3) Code rewrite (dynamic code patching) between rseq and non-rseq code. This may be frowned upon in the security area and may not always be possible depending on the context. 3) JIT compilation of specialized rseq vs non-rseq code. Not generally available in C. I suspect that glibc may rely on approaches 1+2 depending on the situation, and many applications may use approach (1) for simplicity reasons. Ideally I would like to keep approach (1) fast, so I'd prefer to keep the check to one single conditional branch. This eliminates approach (A) and leaves approaches (B) and (C). Approach (B) has the advantage of not limiting us to 32 features, but its downside is that we need to introduce a new __rseq_feature_size symbol to the libc ABI. Approach (C) has the advantage of using __rseq_flags which is already exposed, but limits us to 32 features. Did you have in mind an approach like (A), (B) or (C) for exposing the rseq feature set or something else entirely ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com