From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40082.outbound.protection.outlook.com [40.107.4.82]) by sourceware.org (Postfix) with ESMTPS id D2D133857C66 for ; Fri, 7 May 2021 10:38:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D2D133857C66 Received: from AM5PR0601CA0070.eurprd06.prod.outlook.com (2603:10a6:206::35) by PA4PR08MB6095.eurprd08.prod.outlook.com (2603:10a6:102:ec::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.24; Fri, 7 May 2021 10:38:12 +0000 Received: from AM5EUR03FT043.eop-EUR03.prod.protection.outlook.com (2603:10a6:206:0:cafe::cf) by AM5PR0601CA0070.outlook.office365.com (2603:10a6:206::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25 via Frontend Transport; Fri, 7 May 2021 10:38:12 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; sourceware.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;sourceware.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT043.mail.protection.outlook.com (10.152.17.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25 via Frontend Transport; Fri, 7 May 2021 10:38:12 +0000 Received: ("Tessian outbound 8ca198b738d3:v91"); Fri, 07 May 2021 10:38:12 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 098f9f9af2ce8f66 X-CR-MTA-TID: 64aa7808 Received: from 009b28558006.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 011375F7-BDE3-4006-96EE-38E9BB2EE94E.1; Fri, 07 May 2021 10:38:05 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 009b28558006.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 07 May 2021 10:38:05 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CniQ7HM9MfEz2+JUjWFsnh9utgccBAXQRSFQppK3rHLGeZhbkzd48BetNcrg0EBcrBzxWcYBzi1KCagGtKNiiVL92gNyPwnRudRoB3Wnaj7BzBVcq638oxq7SsfU8X3+CynjuO18rbPgeza4tGiujX50V0xgRhiaxsFUbVpwf2Wnl0ydjKQzwaquDiOp1ECQlaY5vGs+G0gu6mgXiuSuddP3xkUhk2TYT7U6XGa2CVJKgjg2N1WvrJ80A9s2Psw6d1o40eth/fZ1xHB1hyoqYDJjafxUYGhM05vEwlDCTzlcN1J+3jn5uUyIfqSlvzDXUQf3DrmdQ/L8BNr/ndn53A== 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-SenderADCheck; bh=GEIAa+rOrqoPdXtrlQIBIk7C1hFDUQmkV+LXr+NNicQ=; b=gYVjmJz6ii7JlbXhs9wfPRrIqCUHhksyJhomZPd0DhbMlV1qwMbFO88l0qIHSoYn4xdOEJm4ZA4GfGFsgr5PwR5dLxQ4CwVrmyVFLTUjyPUWML1c3nDzL44g7vCgxfYoh3BW+pyWUrM9enX8S7R/lGYzdV+Cs/DTUjhjONSOVOZJOiAI/i0VrQEtqPQh/wOL4U0eVeyzM0NDQUsJBZiMw75hOQzBMQwHEOZIZG2jdUd69rn8yF53p+z+6GgEZkDPNwU33NPX4wzDOtSYGtIEG8OTu1/q5n503WOEyXU4O/wgAFvWAPrs1Tk/aFSiKpXoE8vaxBiNRtl+l3mjkvsrHQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none Authentication-Results-Original: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=arm.com; Received: from PA4PR08MB6320.eurprd08.prod.outlook.com (2603:10a6:102:e5::9) by PAXPR08MB6477.eurprd08.prod.outlook.com (2603:10a6:102:12d::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.29; Fri, 7 May 2021 10:38:03 +0000 Received: from PA4PR08MB6320.eurprd08.prod.outlook.com ([fe80::c99f:671d:bb2c:f20b]) by PA4PR08MB6320.eurprd08.prod.outlook.com ([fe80::c99f:671d:bb2c:f20b%7]) with mapi id 15.20.4108.028; Fri, 7 May 2021 10:38:03 +0000 Date: Fri, 7 May 2021 11:38:00 +0100 From: Szabolcs Nagy To: Florian Weimer Cc: libc-alpha@sourceware.org Subject: Re: Programming model for tagged addresses Message-ID: <20210507103758.GB9028@arm.com> References: <874kffeysx.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <874kffeysx.fsf@oldenburg.str.redhat.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Originating-IP: [217.140.106.55] X-ClientProxiedBy: LO2P265CA0007.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::19) To PA4PR08MB6320.eurprd08.prod.outlook.com (2603:10a6:102:e5::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from arm.com (217.140.106.55) by LO2P265CA0007.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25 via Frontend Transport; Fri, 7 May 2021 10:38:02 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 02a730b9-0739-4ede-d7d0-08d9114436f8 X-MS-TrafficTypeDiagnostic: PAXPR08MB6477:|PA4PR08MB6095: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: kXYQrWHhuXk1vT7YmWAzymRKluMjEgYRAOA35Vs5lLHksakRFHXLIGzNkn3gEkc+Ubq/owfzRAet9wmbNWwubXRNR6aYB6uNwtPHlYUvdyaugd3osSIZCQEkaq0uSJA5AinXe89lWGYoeZFDyz71O3xXlwWwgM1Px94KzfnAdyTtyM2zsd7E2T9WLkfxKaQG/hQAUG5Qo+pDx7fJar/4ZZP8BCC6dGcP8l1PkTCannXg3Vd3Zm3PM1tF2Bxdx1+aSvGPC6hOnoKlHXK8phpkMGforTGCq+2Un749SaE/Myr7Y+50xwPUN8vDMvXywFwN0wd4MVlP01TbCD0+TXXqvLbNDYi45sk73UzJCXB5W+uNxrGN76OBUnw0+B0QB1PBR29pQXnZ7FBbvc/li8Gf4YTVVzyn1uPUkILQL8zCw8DFRjRevL8Nb4B7oz9paXqnKMR3LwqfjIQ6pA7bP3x6Hfhjq0vbbtKTBWBtv+MGiXJV77FGvBZK9lEbkhjfsaLwCahEPUkM4lI3YkKb/ria7P0TowKAXGJ0AlWc3ibtkivCVuGRxLeiqCYtXEoF/+fW+bG/EDhW8/L52nMGUWPlBBVayDNlt0Sm3n7ssVk/j5NwQvHSR2WiOE4wzf/Mj17veNi3uTuaXdkX3Dm8EfPvayO/oMDtqcLnvQ8+fjkFEy5j+B2K6VHFMWku96u0BeToE/CiORsI9G+1tVTFssBSSh4YEzvxlOgZZz4wwQWPOEM= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PA4PR08MB6320.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(376002)(366004)(39850400004)(346002)(478600001)(16526019)(8676002)(6916009)(186003)(36756003)(4326008)(8936002)(5660300002)(66556008)(66476007)(66946007)(1076003)(316002)(55016002)(2906002)(38100700002)(33656002)(38350700002)(52116002)(7696005)(83380400001)(44832011)(8886007)(26005)(86362001)(956004)(2616005); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?SG51SS9YdFRtamFzeWZiZjVJMjI3M0ZMeEh3Zkl5dUNrK0pkcnBBd1RKOXpj?= =?utf-8?B?Z3QxamEyblhCUEJTamNOaFI5cU9kNFZRbVZLcXdNN1RPZmlteWFNUUVNSlRT?= =?utf-8?B?ZWxDT3c1ZThORHozd05ieElLZCtjdVZ3YlJhTTVxekRpZ211ZnY5MzF0bjRt?= =?utf-8?B?dGluejQ5c0RETkNlUHc3L3NGTWlGaHh4ZGV2QkRxZFY2YVZNRE5mdWV3WEZl?= =?utf-8?B?WlV0VjdlTTdvQWR4ZktBeU1sbVJaV21oMFF4N0NjR21MUGlEMmxtYUlLcVFv?= =?utf-8?B?bkhmOWRrQnk0UVVIRURZeFRpVit5RzhJUGl0ZDZaT0FIY2FMdjdJMVB6R21m?= =?utf-8?B?OURqM0lwZ2pGOUJCVmNSZTBDRVgyVUlYV29sSGJlSVptT3MwQXNiak9XQjM5?= =?utf-8?B?bkluby92eTNYdmNla0ZWdk1QSTZXSTQvS2xPNzdKUlVFaDJnZlBIZlc0Qm83?= =?utf-8?B?YXRhMVZCZ0xXZFp3WTZzbDUzaVBKQjd1eXdaNDB2YzMyWG9QWTFnSE0zSjhn?= =?utf-8?B?NWdjWnFSYkRHRHZPckp6eEdaTWRJcy9lS2c1UkJYZ3BVRHZCRnZhSE5rM1U3?= =?utf-8?B?TWdaUTRWaDhQN29aTzlwTXgzN2lra1hlNUd4QmdNVUc0c2Z1aUhnajIwdkZ0?= =?utf-8?B?c3B0VXlRSTlRUDliemNqb1FCLzFicituYTRPZDZaNmJFWktlOHNqM3p5Qity?= =?utf-8?B?am1HNmlSc0lpSWxxbXBKRzU4YXg4UkZZaFg4N0ExdkVyQUhLdE5YR2w4UjVh?= =?utf-8?B?Y3d4Q01LYWd1MEQ1WktYbis4cHhJTVRSWUtZWTVWT1krQUY2RkFaYkVEREhH?= =?utf-8?B?NXFwN29hYjV6SmhVWFJqYXZFOVpmS2FjZWNFbHhYQi9MV1pVUmdGU1FXV2h3?= =?utf-8?B?K0FyZWxlVmNmc0JPZ2pzaW5VbXJ1Mi9iR3NWaTI4U0ZTUkJHbDFVNjBQWHAw?= =?utf-8?B?MVoyMDlCZ0wyalF2KzA4OGFUMTdGczhZQkxyLzZHaHpCWFpucTBPQm9sMllQ?= =?utf-8?B?M0NSTStZK29FUjI4bU1iUFJqZktEMldydmtYdHpZVjBtcjRBbEdjb1NuRkhB?= =?utf-8?B?NnJUSmtIaHhuZVVIY2F1WHRHUlNZU2VBL0xUcXJEVW1yRGtZTTR1bEJPMzND?= =?utf-8?B?WVUyZFlGK0htTUhadkVjdlZ4c0VUR0dCZlR5L1ZlTXVERUJWelcvdEtpNE52?= =?utf-8?B?ZVA3dnIybzJKRXd6L2szTVBmWTVaZklSNXFLYzkxN2FQaFpiMm1vQlMzQllP?= =?utf-8?B?WDB1T3JCL3lDTzh3czdZZC9YNTBKeTBLR01oQUtxbUtnQ3RVN25kcVNNNmhr?= =?utf-8?B?YkRhVG9VUnFHWkdZZzhNZDUwL3VoTWUrNTR5bXF2UkF1RG9iQisrTjFmL0pF?= =?utf-8?B?bkNkV3FTVW9obHZuUDI2M2tGaER5K0RWTnNRcDhIRDRYdmplOVovcG5YbnRU?= =?utf-8?B?ZzUvWHRXWEora0hQUm94ckJkNEw3Tm43elBnYjd4QmhQVXUyYUpjMXBVMnMw?= =?utf-8?B?aGtDY0FaalIyUUJWV000ZU4rQk05YzB2aFBrVUVOVVRGNi9XY1JnTnpaR0pV?= =?utf-8?B?YnI4Nmx4L2x4NFF2dEdaZUtzS09Vb3NKc2V4WEg2eHk1MFYwejloUWRCVmtl?= =?utf-8?B?OEVOOWFUU0dPYnMvS25FSFFadWQvbUxuNUhhS2NBUUY3RTROTVNpaDBaWk15?= =?utf-8?B?REtZbk52VE9sK0RZTm8yRDJTQ0F5b0lPd0ZTSTl1d1F4aVVxTlI3dzdreGRN?= =?utf-8?Q?79RhqPZR7vlShx7TdjlroAoHhnNzdCOW0+bbMSm?= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR08MB6477 Original-Authentication-Results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT043.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 61a3b04d-58d2-4d80-ee51-08d9114430b4 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: EopwVLxP4tXY1L4onn0VhxjMKY724ZzzRS9qckVq1T5z9SJLc++l0nDVH4hdp3Dwvl3NeabyEBpfnd/cjsyteNdA5peumb3rU5JU6u6B5PzgZ9FPUzEZSYYMGlBmXtjP7F/5svYzw4x+wvEVjWqEz2qbYfMEl7OqRXw7DIEGyS95IawoySOAApUmoFIf9OgLCtbGkkPYLTy9gULokXfvxvRKE8oWxr1QsvvbkPCe1d+s8vM0070wuNgoiGPGP7Z7QDhvWrd2ocDl/TwmnbOK+uPque49J2pa0jeZXHH8Vsb+e3aIQK1+cdPiRzlBsNzoUJCoxKPn4KG9zmSr46bQswy/EdG/23aDzW4vJ43xKjigiOQ402S0eh/wHx03Ks0TFzzlo70DmmCpDF+qyj/44HFCQ1uzDmc4QTgTKCUr0xnoZsVYdYA3XUR2Rfk1uioCOxoNigREJzDwvcUn9zLtxVFIrnpILFBGpAyBVCnXWQUrqLnMEE4kylLsPw8yq0Oz+k4lHhBujL1r65WGOg8U5y0hfnvRTYBXvDU2yNpCiY17xR+IEFVaSJYd3VxWfQeXYRk1SJC5xX6VvlsVdmwUVGqxIB9tPPa7TZTUpEqUio+Me0kMENqJfUm4saPimb2c9rCr4YH+Z/ZMdhnb1yXAoIQ8fkT7F94GCg9qP5tLsfecIRs+YAOMAmSxTSMA1VYvcFhsdkcrnStiE3fbM8QgmqCEshDRyWtmK2OHgwjpD58= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(39840400004)(346002)(376002)(396003)(136003)(36840700001)(46966006)(4326008)(478600001)(82310400003)(70206006)(33656002)(8936002)(36756003)(186003)(336012)(7696005)(356005)(70586007)(2616005)(8676002)(55016002)(36860700001)(956004)(81166007)(16526019)(83380400001)(86362001)(47076005)(316002)(1076003)(26005)(2906002)(6862004)(44832011)(8886007)(5660300002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 May 2021 10:38:12.6783 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 02a730b9-0739-4ede-d7d0-08d9114436f8 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT043.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB6095 X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, MSGID_FROM_MTA_HEADER, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2021 10:38:19 -0000 The 05/07/2021 10:24, Florian Weimer via Libc-alpha wrote: > This is related to this bug: > > memmove doesn't work with tagged address > > > The bug is about detecting memory region overlap in the presence of > tagged addresses. This problem exists also with address tagging > emulation using alias mappings. > > If tags are fixed at allocation, I do not think these comparisons are a > problem. The argument goes like this: Backwards vs forwards copy only > matters in case of overlap. All pointers within the same top-level > object have the same tag, so the existing comparisons are fine. > Overlapping memmove between different top-level objects cannot happen > because top-level objects do not overlap. So you have to copy multiple > objects to get an overlap, but that copies data between the objects as > well, which is necessarily undefined. > > Things change when applications are expected to flip tag bits as they > see fit, including for pointers to subjects. This leads to the question > whether it's valid to pass such tag-altered pointers to glibc functions > and system calls. Many objects have significant addresses (mutex and > other synchronization objects, stdio streams), so the answer to that > isn't immediately obvious. thanks for bringing this up. on aarch64 we also need to work out a heap tagging abi, which necessarily relies on an address tagging abi. we were already asked how suballocators can use tagging i.e. fine grained memory tagging within a big malloced chunk, and our answer so far was that is not allowed. (our original concerns: - libc internals assume one tag per malloc allocation, e.g. free can scan the entire range to check the tags. - user code may use the malloc returned allocation as a whole as well as the suballocated objects separately and those two layers can't be mixed. - we don't want to guarantee that tagging works on all malloc returned allocations, e.g. it makes sense to optimize large allocations to not use tagging just guard pages. without PROT_MTE, munmap can be faster. - if user code wants to tag, it should use separate mmap. which implies munmap/madvise/.. are special: they need to cope with mixed tags. exact abi is TODO) more generally the heap tagging abi so far relies on the tags never changing during the lifetime of an object: there is only one valid user pointer to an object and it never changes. for plain address tagging this may be too restrictive: user code wants to tag pointers of existing objects, when there may be pointers escaped with different tags. this breaks c language semantics: pointer compares no longer work (multiple different pointers may access the same object and they compare unequal). i think we need to either - design a c language subset for tagged pointers and then ensure the libc follows that subset and supports user code that does so too, - or only allow limited use of pointer tagging, with requirements like one pointer tag escaped per object. > > The next question is tag bits coming from glibc and the kernel are > always zero initially. For example, for malloc, we currently use two > bits in the heap to classify chunks (main arena, non-main arena, mmap). > These bits do not change after allocation, so it is tempting to put them > into the pointer itself. But this means that some of the tag bits are > lost for application use. i think reserving tag bits/values for implementation use is reasonable abi choice. so far we did not do that for heap tagging because of the limited tag space and no pressing need.