From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932883AbcFBOwh (ORCPT ); Thu, 2 Jun 2016 10:52:37 -0400 Received: from mail-db5eur01on0109.outbound.protection.outlook.com ([104.47.2.109]:5536 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932702AbcFBOwg (ORCPT ); Thu, 2 Jun 2016 10:52:36 -0400 X-Greylist: delayed 8409 seconds by postgrey-1.27 at vger.kernel.org; Thu, 02 Jun 2016 10:52:35 EDT Authentication-Results: vger.kernel.org; dkim=none (message not signed) header.d=none;vger.kernel.org; dmarc=none action=none header.from=virtuozzo.com; Subject: Re: [PATCH] mm, kasan: introduce a special shadow value for allocator metadata To: Alexander Potapenko References: <1464691466-59010-1-git-send-email-glider@google.com> <574D7B11.8090709@virtuozzo.com> <574EFE0F.2000404@virtuozzo.com> CC: Andrey Konovalov , Christoph Lameter , Dmitriy Vyukov , Andrew Morton , Steven Rostedt , "Joonsoo Kim" , Joonsoo Kim , "Kostya Serebryany" , kasan-dev , "Linux Memory Management List" , LKML From: Andrey Ryabinin Message-ID: <575023EC.9090007@virtuozzo.com> Date: Thu, 2 Jun 2016 15:17:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [195.214.232.10] X-ClientProxiedBy: VI1PR06CA0036.eurprd06.prod.outlook.com (10.162.116.174) To HE1PR0801MB1305.eurprd08.prod.outlook.com (10.167.247.147) X-MS-Office365-Filtering-Correlation-Id: 467dff6f-5959-405d-1e63-08d38adfce9a X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1305;2:lx33QIVPpGqrF12O9iYwiJZBnvPFfAwZAn9Mh2GOvmtNuu3WsF1zZcX4My/GqZWgsAW7D/0awHNEUjx1FmwpadXJ5QDf/q4QFEpDPLxSMDmwMctU0miA9ZSOKiQ1+yDXxFzE6ACqWeuDph+/GQrgxIqZiSLdooYXbFEX4m+yfE3/B9+l125YtQEhmuOU7j/F;3:6CyqlD12YM/JDENpkQZx4Gr63ZvBRx5wA4neMJPFkqxxRtxnChSVa3aN3apT6G3MZpDG/YxK+fcNrE2DodoblWvjClU741VZQUAz2He6GZ8U1NAdAffdT2DO+ur4F7Pn X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0801MB1305; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1305;25:mFeTLTIx2ldmyoUwI7XGPo1U9DtDQC3QhPWSOHEQ5xK9uLfR4RLaMk0VeFHogcEiIqrAQtl5DXfNqk9p4d5rIKA3luDF8YiJLORxEdzaSZwYQSj6ag2InkYvO7lbydT72e9vqKsZnEPwZ36STHGuzw58z0S3WUW5QYd5e5dhXSzP8SdGCJK+ktxhGAuVAlkVvG/GJDGkvvYKkO1yFr8MXmRtR8MwWS9uPcge58TxDY7cFFdeZ39vgIx9x9Rm1oQ3yA7GLWVuD3fDzSq/kt1VwwwN9jvzxAJEgy0zW11C4DPs0apjSXxm7f0G71ovxVzt85cSTtzBkzrDygr/b5t0LcK7xFm/4D482PyyU1GRgJ6c4DuBSnw+hQm6G375YnzWwYyhIiU5+Vr7PPACvwid5oV/zc6cZ9svu5MAaBXZcbvsWX33zc+pn+ktN6oX42Oe2rqZ+joYjoVwgxD6Y04cV9AOo7NuQB/DwJRVVbF76MqtLKByDe816krh9/Cr4XPuR4cMs7YLO7fjog4W0wGod1sEPE/KGxJEbHh9vj40gISiZujJunfzKY0cAmKzVlkZhpQTfOMvE3ygA90FJsENmFPnChK7ARE44Pbpj3zrt3NbjeHR9PRMeWQUBw/FfBzEkE47uh7OwQfEP/o0yuPynshKE5lNMc3ksEPT/+E30F4osVErSY9IsYBTTWB/WJ7oLbUikV+0tFPsD9CbymLkiQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(20558992708506)(211936372134217)(211171220733660); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041072)(6043046);SRVR:HE1PR0801MB1305;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0801MB1305; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1305;4:OrhLI2HTdL8cuSZG/KyziwdFieq0rGxjieSsDmQ6u7E/fNfospyP+bFJLagfU2cOOQHnjit0EWvCJFjfytwzJZc9MqVAcjNoetJToNLK88PolQgkvpBuqIm8kNBGb9wdqF+FBjBiYaVs/9+Bd5ILynEPdgHZTcn7Tza347yC9ULhU0AIIjj73ctEROnko5+ilpgS/yR1eU9xFdLgbVzCZ9CexdecOuKB/CnH+c3fEL+XmuLZySmP4mLOopZ6CK+Gyw8PFderSOb9xsAtvRrZgDNU22g70Md1QPf5eZd9SWXsq3TYoqng+Nygcjp4Ks8AzlXF351XjaCzkX8yI4uvGcMDDcA0PhuKceSlpkl79yOFIa781rmJJrwFOBOkDBRPdAWczpNq8mWdIcQE2dho5EPLjulcE9bHvCX2FF87E4pBG5+UHztc9ena4xn+SYcIs0IsyBf4o173xv7LVzpeG4/vn51SqXoR425A7lcJPaRku8yDR8tSRau5wod7vQ3RJLeHOeRlqveYqXO1UEH2L1dlaucwvDOYc8drXIzLiFs= X-Forefront-PRVS: 0961DF5286 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6049001)(6009001)(24454002)(377454003)(66066001)(86362001)(2950100001)(42186005)(65956001)(77096005)(3846002)(6116002)(2906002)(110136002)(4001350100001)(36756003)(93886004)(23676002)(50466002)(65806001)(5004730100002)(92566002)(8676002)(65816999)(81166006)(47776003)(19580405001)(80316001)(19580395003)(83506001)(5008740100001)(76176999)(33656002)(54356999)(87266999)(50986999)(230700001)(4326007)(189998001)(586003)(59896002);DIR:OUT;SFP:1102;SCL:1;SRVR:HE1PR0801MB1305;H:[10.30.19.223];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA4MDFNQjEzMDU7MjM6VktCeDVFeVVsMzJVeGFiTVo2LytIOEFt?= =?utf-8?B?VEpSazdoSmRkY3FSdklnWEpVVS84NzhDM212T2pBNy9UaGs3eEk4MkZ4OC9U?= =?utf-8?B?VkRzVHo3bFdBdGJTdnl1MFJybVBXV3VnL1RSUE5nT21SN1hiWUxNSjhHcmFO?= =?utf-8?B?bS9wSkFCOVNaMW9CMXBpTFZoaG5MZlhWK01YVVhWVDFZaWJKc2ZkWEVVS1FV?= =?utf-8?B?Z0k4Q2hnVVIzdlFqZTJWL1lSY3lNUFJsNlk5eGUvdE5TWkF4Z0tKRFdsM0xT?= =?utf-8?B?bXVVWWhzNlBQbVpCbnlOc3NqazB0b2VLTTZabzNrVXJmYkh0T0pkRjNHL1FQ?= =?utf-8?B?bjdOQVhiSjhtTFRVc3llR1YxbmxLTEIxd0dqY2o5TlFSWTJnWTNsS0pOWVEr?= =?utf-8?B?alpKdjZMa0lTc0pLbkpncTlNTzJaVDFXOVFsMzg3NDVsTU9zVWdzNFVCRG1F?= =?utf-8?B?NlJTS09TOXF1bWRqb09JZEwrT3M5K1NFaDc0V0dOdnRxUDRaeHhvSE95cFV5?= =?utf-8?B?ZFN1QlRWSVRlMnduKzJCZ1JSelpqSGVsMExHSHprbW9aVE9pNTA5Mm44d1pP?= =?utf-8?B?VTNacjEzYko3azJXaXI2bjBCUTVUR3IvZGIvdlBGZXBoZUNqMUFZMDRLVDRD?= =?utf-8?B?UTdlMkYzTXlLSU1pTytLQ0lGR2dyT0ZpQjNDdkI0TWM0L0txZmJTdVpHRnBR?= =?utf-8?B?aHFoVzNHT3N0d2dzcWh6eFFIMXhCbVFZYytCcFpBc2Q5dklnWXVUQ0NsdGV5?= =?utf-8?B?eXQ1NUc4R1JhdUh2QlBTeXZhaVh5MkphTjdUODJsNnBuc1ZMVUdOSmZRY3JW?= =?utf-8?B?cWJxdTFVSWhOZVFLbmNPL0pqcnN3Um4wajZPYVJDaWhnTiswUUh2dVVEZXVn?= =?utf-8?B?NFFmQjBzMWRGWi80Wnk2YnVDaytGK0dhUW5DOUNoUU5CWGpDVHdpWnJzYWpG?= =?utf-8?B?MUcwTnpvS0J1eWVFTkhGWFk0RmUvOERvTzJoMWdOSXo0VVQrUmxaZm1XaGE5?= =?utf-8?B?VzVoVW14R1ZTNmNLRmloTkd0LzdPSVFTOGdQQmUzTnB4WWJpcFJSclNNbkx2?= =?utf-8?B?blpJOXp0Q0IyN1JQRGxxalBvVWcyMWpUeTVSOUVNSnpYYVdHNDNnd3gxbnZU?= =?utf-8?B?aG5tNUdRT2FaWDc5dkxFK2loZVhCS1RUVTROQnpqbnpuVDllRXg4cDBCN0VB?= =?utf-8?B?VUxxcWdSb1l0SWx0alRtaEdaQ2UzQWVGd3duakx4bEpPb1didnQ4bWkraTlY?= =?utf-8?B?K0NoQ0ZhMXN6N2JnQXFDdTdHUkJNU2VJQ1Z1a09rdzcySVROYXFWK2RiM25k?= =?utf-8?B?TWpqNG9UWnNpcThJVExjcXhUdXh0UFhkMWlpTXVWbVA2Nlh4S1J0SDN3TWhp?= =?utf-8?B?SU9XYWFYTG0xaWJpK0RHUEpoUU9Sa3hkVDMyZWR2RTdqNmk5V0dpSTlSaGRP?= =?utf-8?B?cEFmd3VkYWJOVFYvNUhrR3hrWE5rSG1aSlk1RkwwNUFmb0duMUhEcXFnaHhi?= =?utf-8?B?T1gyaVF3PT0=?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1305;5:Ntsnp+dX5PVRsuq8Ejy8Kfzj2cW01eZDER3sSdpI3Ay2IzY3qV9pXafTm505H8p+eVKzR/Kbr6PxJEIKmidmTRF6VV3FZIYl5iQl3QOKR/NCkoXVu8F78iKDtTBbeso8KxCNeLZDb8XtBUs9h8rbdw==;24:9vx7fb86P1q9oTdQFTdBpQIJVBTtnSYv1rOx5Urh9HhaJxMLqi0GA0C8bqdzwPbSnSV3vUQk4jiyFleyJ8NElIuTnzHrW5waF022RwXf6+s=;7:H0JJtSLwrbDtKAEJVHevpqugGrSVVPwGDG0eQD9nzXA0tgVXe0DsoXrrF0B+icNo45akweEgILIZAQfGVgpGyOXiFng9Ad3JMoCDbY+79GaESXJbL7Yu7eB9Jy3WtTwQ8XAmrqHmZt9OYRppzDg3UhBSjkA65c6XnyMcrqYPEkP93pIFZHin3k122dkDnxqN;20:7glqYd5fbQxzTB/+qIA2Oly1FXNVIsEq/6OoxtCtj0uNRfi4f154A7Yl0mqr/oEYYbUYU7TR+HqLM7KJD8Wx+zjhWyqjtkQzaaoI2MKWcGBbBuTBErE6UsSnFzreObMzMbbNCroKTNW+9dtysSxxuyguGhdTFex0n6hg84to5QM= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jun 2016 12:17:02.3387 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1305 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/02/2016 03:02 PM, Alexander Potapenko wrote: > On Wed, Jun 1, 2016 at 6:31 PM, Alexander Potapenko wrote: >> On Wed, Jun 1, 2016 at 5:23 PM, Andrey Ryabinin wrote: >>> On 05/31/2016 08:49 PM, Alexander Potapenko wrote: >>>> On Tue, May 31, 2016 at 1:52 PM, Andrey Ryabinin >>>> wrote: >>>>> >>>>> >>>>> On 05/31/2016 01:44 PM, Alexander Potapenko wrote: >>>>>> Add a special shadow value to distinguish accesses to KASAN-specific >>>>>> allocator metadata. >>>>>> >>>>>> Unlike AddressSanitizer in the userspace, KASAN lets the kernel proceed >>>>>> after a memory error. However a write to the kmalloc metadata may cause >>>>>> memory corruptions that will make the tool itself unreliable and induce >>>>>> crashes later on. Warning about such corruptions will ease the >>>>>> debugging. >>>>> >>>>> It will not. Whether out-of-bounds hits metadata or not is absolutely irrelevant >>>>> to the bug itself. This information doesn't help to understand, analyze or fix the bug. >>>>> >>>> Here's the example that made me think the opposite. >>>> >>>> I've been reworking KASAN hooks for mempool and added a test that did >>>> a write-after-free to an object allocated from a mempool. >>>> This resulted in flaky kernel crashes somewhere in quarantine >>>> shrinking after several attempts to `insmod test_kasan.ko`. >>>> Because there already were numerous KASAN errors in the test, it >>>> wasn't evident that the crashes were related to the new test, so I >>>> thought the problem was in the buggy quarantine implementation. >>>> However the problem was indeed in the new test, which corrupted the >>>> quarantine pointer in the object and caused a crash while traversing >>>> the quarantine list. >>>> >>>> My previous experience with userspace ASan shows that crashes in the >>>> tool code itself puzzle the developers. >>>> As a result, the users think that the tool is broken and don't believe >>>> its reports. >>>> >>>> I first thought about hardening the quarantine list by checksumming >>>> the pointers and validating them on each traversal. >>>> This prevents the crashes, but doesn't give the users any idea about >>>> what went wrong. >>>> On the other hand, reporting the pointer corruption right when it happens does. >>>> Distinguishing between a regular UAF and a quarantine corruption >>>> (which is what the patch in question is about) helps to prioritize the >>>> KASAN reports and give the developers better understanding of the >>>> consequences. >>>> >>> >>> After the first report we have memory in a corrupted state, so we are done here. >> This is theoretically true, that's why we crash after the first report >> in the userspace ASan. >> But since the kernel proceeds after the first KASAN report, it's >> possible that we see several different reports, and they are sometimes >> worth looking at. >> >>> Anything that happens after the first report can't be trusted since it can be an after-effect, >>> just like in your case. Such crashes are not worthy to look at. >>> Out-of-bounds that doesn't hit metadata as any other memory corruption also can lead to after-effects crashes, >>> thus distinguishing such bugs doesn't make a lot of sense. >> Unlike the crashes in the kernel itself, crashes with KASAN functions >> in the stack trace may make the developer think the tool is broken. >>> >>> test_kasan module is just a quick hack, made only to make sure that KASAN works. >>> It does some crappy thing, and may lead to crash as well. So I would recommend an immediate >>> reboot even after single attempt to load it. >> Agreed. However a plain write into the first byte of the freed object >> will cause similar problems. > > On a second thought, we could do without the additional shadow byte > value, by just comparing the address to the metadata offset. > We could. But still, there is no point in doing anything like that.