From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id E9BE3A050D for ; Tue, 26 Apr 2022 18:08:06 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E0CD742805; Tue, 26 Apr 2022 18:08:06 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id 8E566406A2; Tue, 26 Apr 2022 18:08:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650989283; x=1682525283; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=3S0Q80pvBS7YdPjpCuc+0UgwUesbQjJDG7HdUg/mPww=; b=hwVewGR+nB1zBKx+31ysU7TkyRwLYlHuKalIybbH91IjlPcyjXFOdmtJ we8Zfkbcwl/9k7Xs2Zm2mPJkozplki5tjEEAsqnPZDRIBY0GUKvtmnKiu UJyfpyPdeAGbetUgZhdAd127zAcqWfXzHajg+t9y2ZQd0un1FVX0dVke5 qff0txuHzemDXO1fYw/3tFb8Q1rFs17nROk0sQKLbmWqynXIYTsqv9fNg hRAbIUk7MayjaVEOaaOSf+Z9DjS7ulGewF8ueisUEPDsiFCdBdGUWhcYd SNSgUDRxgNYfzbQtGLZNCZp5F3IuqSI5O3gWPlkzZ04P+OUfWlOz5wgOK w==; X-IronPort-AV: E=McAfee;i="6400,9594,10329"; a="290773116" X-IronPort-AV: E=Sophos;i="5.90,291,1643702400"; d="scan'208";a="290773116" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2022 09:08:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,291,1643702400"; d="scan'208";a="538908098" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by orsmga002.jf.intel.com with ESMTP; 26 Apr 2022 09:08:00 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Tue, 26 Apr 2022 09:08:00 -0700 Received: from orsmsx603.amr.corp.intel.com (10.22.229.16) by ORSMSX611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Tue, 26 Apr 2022 09:08:00 -0700 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27 via Frontend Transport; Tue, 26 Apr 2022 09:08:00 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.177) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.27; Tue, 26 Apr 2022 09:07:59 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ME1MrWQwQA6p29rjFvFe7hLKr0FLIqk9Gu80iG9HHc9OUdF85Lmu3d2E4tc9vxR4qs+IEi1tKRPnST3QLAkHcbLtUU4NDuS+2fmdZyv3z48h/EOj4cOy72dv0WNG2dt3Crrrqlz0lvhJ6sNs0gjybTnGXfMR4J/6sTZvaIfHkZ4clbl4LZV5eXCDY9oim+ZfouShu/1rsQ95kYeCZ+XQOi5pByxIJ89Nqa8XlmjmSWoZ4LbkW4ZGBmA1I1EqkE0CxfvOXNeQhzerBQIsaM2gd7N8fhmKswrNFAS3jckwWyYvwzCldz1P2ZxG7C2TWDk5Cb/qNRRRNCInU3OaHSrTcg== 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=XLC+0rlZRg7j5pErNZ2M62NTi2hbXKdrOLBfqtcWdJY=; b=ZLbA7aBXbIsFdhKVQYVCNOyLlRS3r3nnhSRuG/7ez3eMlVNISwgGk6VwlMAJx++yCW7J/JV81DK6JQJdMdV7THLsmwfXyzDCFd9HINp7cfmHSdSnSf+i6LbxBueNs/xS4Jw6n+NvllT0aP9rAy2ReknjSJMgel4sLxoOBTWcDGXQ0a5xlVpr0NvoJ2rv9B8p3jWI0lz6t0lCZ1DU4Mlhu/Rt1ie/sNyAI0Zku6/cRBx+N5iydPNQhN62OTa5B+TIMla3i7PZ+e7Fs3I50+on3V80/WkbrxXL4s4s9LO1zBZ1JDGm1xMh77rTzhLW6cPqOzd86iHD11SN6m44XPG8oQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5093.namprd11.prod.outlook.com (2603:10b6:510:3e::23) by BN6PR11MB1314.namprd11.prod.outlook.com (2603:10b6:404:47::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5186.14; Tue, 26 Apr 2022 16:07:58 +0000 Received: from PH0PR11MB5093.namprd11.prod.outlook.com ([fe80::28af:8ec5:1817:1af1]) by PH0PR11MB5093.namprd11.prod.outlook.com ([fe80::28af:8ec5:1817:1af1%3]) with mapi id 15.20.5186.021; Tue, 26 Apr 2022 16:07:58 +0000 Message-ID: <36f82439-a251-d095-ca9b-c14fe4a32430@intel.com> Date: Tue, 26 Apr 2022 17:07:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.8.1 Subject: Re: [PATCH 2/3] mem: fix ASan shadow for remapped memory segments Content-Language: en-US To: David Marchand CC: dev , "Mcnamara, John" , "Dmitry Kozlyuk" , dpdk stable , "Xueqin Lin" References: <20220415173127.3838-1-david.marchand@redhat.com> <20220415173127.3838-3-david.marchand@redhat.com> <419bb7fc-cb04-10cf-a40a-5dba39323f9e@intel.com> <249b5c3e-513b-af96-399a-01d60ff93d26@intel.com> From: "Burakov, Anatoly" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0300.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:196::17) To PH0PR11MB5093.namprd11.prod.outlook.com (2603:10b6:510:3e::23) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5fedce65-873b-4667-d86e-08da279eedf6 X-MS-TrafficTypeDiagnostic: BN6PR11MB1314:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NlDrgd1pfxpKE2zTdQFCmeRoVZrx1b/18nH54eYSp7PucB/sBBpKupQOeupUXqmBweP9cY1tFvN3iCcB97RpRPOMhfUfjIcd27BUv6/nHYhRQnyjM23APXbkUoap91r+eo+86lJKy8ixmp1yczxmrTWo9w082Ve9/AgtJSzjo9qWkcTQM2hXmJNmvzF9a22Nv5ah/DTxrTDxErgoOKhgvOQEjWQ1Gcun0syf7T8fAv7PignAeXniv7f25sB/ruaPEFt0rbn4omp7UbvtgcVcHHDKl715mtyp85M3krXchxoKuQsj/VkaQaoCles06ot7jIRuoOpO1/AKcfZnDowKPAUMZ1aK8ko/PPzgiEivlmTmBwzwF4MRjuN7VHvfakrfvXH2rv027SjrcbNLxjjuaLSNSgOvHXetE0dmA+z5c/AwfhLJi1yDvUOpE+0zISkg1YZM/H+f711KCl33LtbYjtHG9LxpqCoteGwlsMcdtSIo9u7Q/dnMnkd+iUF360l0RlkaRYYEHvBvBfEMWZc+xPV+cUHi0snIrdw3UQGDsAcfNtydsqw+lArA5z7OuB3LsKu3q5o4SDaaL2aSQGa3EEMIWR61k66/fCEyWfAVYRhb/2HRrrX9J/6kvjHY74/ykjQOfjCnCACCncwfWNlbaS3/YAtN8vR6rI3Kn9/GoeT8Uo7iAgoPhiEeLYCN1zjx1KNHbvtKfePCiOX3ODolAfNw/ZH+JJ15awVl2g1Vk/A= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5093.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(8676002)(4326008)(66946007)(66476007)(83380400001)(2616005)(82960400001)(107886003)(31696002)(316002)(54906003)(6916009)(86362001)(186003)(38100700002)(53546011)(508600001)(6486002)(6512007)(66556008)(6666004)(6506007)(26005)(8936002)(31686004)(5660300002)(36756003)(2906002)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Z2Zjeko4cGt5REY3ZDB0KzhuUXhPQTFkVlFYVU9TeU1VMExqTkc3VXFSeUlD?= =?utf-8?B?TE94aGFZOG1kMnpSK1FXbnpERWhmcnJwMXl4QzN3aGMreGZvOXFodklNZzl5?= =?utf-8?B?U2xveFRVWHhPc0hEOVoyNWZBcEw3WUpmYTBZYWVoMlExWWU4MlhxVEV2YlpE?= =?utf-8?B?bHlnY2dFYWtqSE9NbHk2UVlENHJqbVVHLzJVcXduVUdORWRoSGhMRnQ0MUFs?= =?utf-8?B?OGxIYVlGbVBQd3krcVM0N29NRlVxb2Q4RzRGWjN1NGxwMmM0dnlTM3FrSHRQ?= =?utf-8?B?V25QM3pvK3p1Vk92b21yenJEYkltcENiVHJzNWRUTW42WHgvdzR5dUNCS2tl?= =?utf-8?B?eUVzVU4rM0ZBNTRaUnRTSmd4bitBa0d1N3VnMUZXc3RVWmk4cUlVT2dBQ0Fi?= =?utf-8?B?SXpMZFUrZzN1T1d0MjU2TGRFQmFTSW5iWWs3V2lIRFZ5MHViWFEvNHlmSnI3?= =?utf-8?B?SWI4ZTJPd2FzTnl3aTJSanBQQW9mOG9PcTdvVUNmRW9xMWloWG1xMkE3U0VY?= =?utf-8?B?b2Z0K2gyWFNlQjNvYnBzRmRIVVh6VU9Ed0crMWlBU1VLZm9UYkFnZTE5S29h?= =?utf-8?B?UTNRVUdJQ0FzZ2J1eTF1dlNqSldGUjkvdEpvL1crdTc2ZXcwMnJIcG5jUnB2?= =?utf-8?B?MlY5RmY1ZlZPWldyQUtBeUMxZThWSjJheVViV2drMTlnWU1QaVVOY1g0UlJN?= =?utf-8?B?dExNMmZxbkRlUlZDR0ZSeGJScml4dTlzT2RjMm9FWVY5WGFVM1MzL1RlenEw?= =?utf-8?B?UkxnR1NBZXIxMTBUZnFBVmhJZHdjbEs2bDk4cUx3Q013dklhSUUwY2dKWmNB?= =?utf-8?B?MGg0Y3ppWG9ITHdkazliSUtKMC82bUVKMG1FRC9SMmFkWU9hODZhNHpHZlgw?= =?utf-8?B?SmREZU5Oa3REY3JlWXBlRGhaMDJVZlRKNk9ERitlMmk5bTcxc1JxaWNxVnlI?= =?utf-8?B?QjYwcC9abUJZZStEcE16NEUxbmhpSGpPT29nMmZkQldsRngvVUthbmdKeXM2?= =?utf-8?B?cEx2V1dqVVdyTlBET0FScXlTV3gxY0VqSEFmUTArcVYrNzRKZjNiU1FMUVVm?= =?utf-8?B?ZHFDUWxpeXNsTHVvdTNiZ2xsL0RWTE9mZGJ1d0ZXTHdYcGY3QUdQT2tiWlZE?= =?utf-8?B?SFd4b25zNDhReG8rVFUvWS9zQ3IxYnpWSldQTVlIdG80ZE0xUmsyb0QxS3FC?= =?utf-8?B?RzJSSzlaaFdpRmM1UWhxeTlwTnkwYWt5N1VSaitWL1FLa1dWbEU3QjdKa3gz?= =?utf-8?B?QUNUVmIrTzduVjhQNitZRlk0U3pIUEliUWR1aE9YRVUxb3huYWJYOEpqeEQ5?= =?utf-8?B?cStaYURtQkp1eWpHTmF5b29aVWpGMWcvc3VtNHZRZTdnZjJhSDdwR3Z0V1FK?= =?utf-8?B?dWVIN3FCRDJmUXhvOG9ZblpPaWY2RWRWT0Z5d21DQXhOYXJuZTJtSlJFaHNW?= =?utf-8?B?NEtmMVhyb0lIQUtIRTE2YlJXa2JvMDErZVFjclJ3SkQ4OWZRYjVLR3BkMERx?= =?utf-8?B?ZWZ3Q3MvZWtCUWJJZUZHZzhUZmhPdVJLRzJzV1JjemlKMm5LUW9rZm5rYjI2?= =?utf-8?B?TTlDaTh2SFRYTVhxZFJXNEtRL1RQK0VBbmVLMC9VR2djTmxnMmpRZllyWEpj?= =?utf-8?B?R0xNdFRZUlh2bW56a09PZ0lIZi93R1lyc1AzYWNZTDhac1M0U01HNzVYTUJp?= =?utf-8?B?ZC9ydGVrUVNvdVd2Z1E0N01Id281eDUrYzliOVhJdmVad1FJbk9SQWM3bWVV?= =?utf-8?B?SUZVYkJzV0xwSXRiUEh4KzZxODMvcHRsOWdUNThsNG45UUZaZklyaFJ0bXF5?= =?utf-8?B?YkRDT2JVaU5XOU1WTkRGTWFzRlZTMUdZZVBibnBuWmFKbERENEMxalYwQmhy?= =?utf-8?B?QVNlbnUrRm1KeEgxaXhEdDdGNkNjMjFJT3c2ZkNTL1N0RWV2R3Q0T1JTMUtC?= =?utf-8?B?dFYxV1dzVmx4dU5yMjh6NWNZMzlzcVhBSzY3Ry93MDI0d2dLMmVJUVo3a2Z2?= =?utf-8?B?dU5BRDlsTjg3Q2pHVHNSdFVHVGxRZlZwOW0xSDQ2MjVyaVl0MXhZUWhFb25M?= =?utf-8?B?U2FqL1lXb1pBazlPYTI3Wmdzb0JNSFFKS0kxek9hYXJaZGZFWkJDK0k2Y3Az?= =?utf-8?B?bW9tWlJ0d2laZm9RRFZ2RmtsaHNYREtaSjcxdWwvSWptaG1MemdMaGRmNXJU?= =?utf-8?B?emRKWGxidTIvZ3hkTlZjdzhhQkhkZUN6QXBGVjZ4SVhob1YrRnVFdUxoRkZ2?= =?utf-8?B?OXBxVEVlVWRWZ3RGTk9UU0xZSE1EM1IvSTZvdmNTVUNmeEwwUFVrUGlaOXYy?= =?utf-8?B?L2RoeTQwT25kZnc2OW1HN0VwbnowV0RnVThQYkpDbWxiZlpVSEhoNWRsY3BI?= =?utf-8?Q?oj8raGx5OyGJ3/14=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 5fedce65-873b-4667-d86e-08da279eedf6 X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5093.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Apr 2022 16:07:58.0164 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: nTrHhFV/db3ZMAP4gdSGi2+B2Qp+wauEhd2pfHGd0UDzMsfbvbSY2efW9A+HShbfMkdarUp1VDsRyJQWDuKpTfcftMhxgE2Xc6uOPKLcQVE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1314 X-OriginatorOrg: intel.com X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On 26-Apr-22 3:15 PM, David Marchand wrote: > On Tue, Apr 26, 2022 at 2:54 PM Burakov, Anatoly > wrote: >>>> @@ -1040,9 +1040,25 @@ malloc_heap_free(struct malloc_elem *elem) >>>> >>>> rte_mcfg_mem_write_unlock(); >>>> free_unlock: >>>> - /* Poison memory range if belonging to some still mapped >>>> pages. */ >>>> - if (!unmapped_pages) >>>> + if (!unmapped_pages) { >>>> asan_set_freezone(asan_ptr, asan_data_len); >>>> + } else { >>>> + /* >>>> + * We may be in a situation where we unmapped pages >>>> like this: >>>> + * malloc header | free space | unmapped space | free >>>> space | malloc header >>>> + */ >>>> + void *free1_start = asan_ptr; >>>> + void *free1_end = aligned_start; >>>> + void *free2_start = RTE_PTR_ADD(aligned_start, >>>> aligned_len); >>>> + void *free2_end = RTE_PTR_ADD(asan_ptr, asan_data_len); >>>> + >>>> + if (free1_start < free1_end) >>>> + asan_set_freezone(free1_start, >>>> + RTE_PTR_DIFF(free1_end, free1_start)); >>>> + if (free2_start < free2_end) >>>> + asan_set_freezone(free2_start, >>>> + RTE_PTR_DIFF(free2_end, free2_start)); >>>> + } >>>> >>>> rte_spinlock_unlock(&(heap->lock)); >>>> return ret; >>>> >>> >>> Something like that, yes. I will have to think through this a bit more, >>> especially in light of your func_reentrancy splat :) >>> >> >> So, the reason splat in func_reentrancy test happens is as follows: the >> above patch is sorta correct (i have a different one but does the same >> thing), but incomplete. What happens then is when we add new memory, we >> are integrating it into our existing malloc heap, which triggers >> `malloc_elem_join_adjacent_free()` which will trigger a write into old >> header space being merged, which may be marked as "freed". So, again we >> are hit with our internal allocator messing with ASan. > > I ended up with the same conclusion. > Thanks for confirming. > > >> >> To properly fix this is to answer the following question: what is the >> goal of having ASan support in DPDK? Is it there to catch bugs *in the >> allocator*, or can we just trust that our allocator code is correct, and >> only concern ourselves with user-allocated areas of the code? Because it > > The best would be to handle both. > I don't think clang disables ASan for the instrumentations on malloc. I've actually prototyped these changes a bit. We use memset in a few places, and that one can't be disabled as far as i can tell (not without blacklisting memset for entire DPDK). > > >> seems like the best way to address this issue would be to just avoid >> triggering ASan checks for certain allocator-internal actions: this way, >> we don't need to care what allocator itself does, just what user code >> does. As in, IIRC there was a compiler attribute that disables ASan >> checks for a specific function: perhaps we could just wrap certain >> access in that and be done with it? >> >> What do you think? > > It is tempting because it is the easiest way to avoid the issue. > Though, by waiving those checks in the allocator, does it leave the > ASan shadow in a consistent state? > The "consistent state" is kinda difficult to achieve because there is no "default" state for memory - sometimes it comes as available (0x00), sometimes it is marked as already freed (0xFF). So, coming into a malloc function, we don't know whether the memory we're about to mess with is 0x00 or 0xFF. What we could do is mark every malloc header with 0xFF regardless of its status, and leave the rest to "regular" zoning. This would be strange from ASan's point of view (because we're marking memory as "freed" when it wasn't ever allocated), but at least this would be consistent :D -- Thanks, Anatoly