From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0969C77B73 for ; Mon, 24 Apr 2023 03:16:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 32338900002; Sun, 23 Apr 2023 23:16:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D4006B0074; Sun, 23 Apr 2023 23:16:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C2DD900002; Sun, 23 Apr 2023 23:16:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 09CDA6B0071 for ; Sun, 23 Apr 2023 23:16:03 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C8FA31A033A for ; Mon, 24 Apr 2023 03:16:02 +0000 (UTC) X-FDA: 80714820564.23.39C5E91 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf19.hostedemail.com (Postfix) with ESMTP id 04E2F1A0003 for ; Mon, 24 Apr 2023 03:15:59 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of gongruiqi1@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=gongruiqi1@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682306160; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=a17Y1mkD7zYjtgGethq1jhAAN4YrghYJaAI1EJlV7Nw=; b=ZSxEaCu2QTzrfC937O08tmRWiliwSDHSqLHpXWxz1zj6ZQJTrHvdmYD3XWgjpjHr2FbmYU dgNTuoXocIELI9B3pD5BoMgmQrCEqHofKbRUIhM0Z/7bBOL1MJLt2DMfUz7bHaKcmvOkW/ RyAVEFntE5boF6znb4j+MuGMkeb/hX8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682306160; a=rsa-sha256; cv=none; b=KKPvnvXTOaXXaG4pC5gV+XjdT5WeLVlS5at86yaw2z/zu5jTAjAhzTnzMGyjr6YoW/u0vV +ayq51eBUX8+h6msafDPDiiZct7c9Zp2TQsUs8lcnguYU5e1x0nE6X9kWfvIdZStGYsUbK kJAstf+ycOndIM9iGXAuF3MjFHU1i2c= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of gongruiqi1@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=gongruiqi1@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from dggpemm500016.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Q4VXY1krXzSvPZ; Mon, 24 Apr 2023 11:11:41 +0800 (CST) Received: from [10.67.110.48] (10.67.110.48) by dggpemm500016.china.huawei.com (7.185.36.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Mon, 24 Apr 2023 11:15:54 +0800 Message-ID: <8768d2ae-99ea-9890-83d9-7e1a35521aa3@huawei.com> Date: Mon, 24 Apr 2023 11:15:54 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH RFC] Randomized slab caches for kmalloc() Content-Language: en-US To: Hyeonggon Yoo <42.hyeyoo@gmail.com>, Dennis Zhou , Tejun Heo , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka CC: Roman Gushchin , Alexander Potapenko , Marco Elver , Dmitry Vyukov , , , , Kees Cook , , Paul Moore , , James Morris , Wang Weiyang , Xiu Jianfeng References: <20230315095459.186113-1-gongruiqi1@huawei.com> From: Gong Ruiqi In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.110.48] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemm500016.china.huawei.com (7.185.36.25) X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Queue-Id: 04E2F1A0003 X-Rspamd-Server: rspam09 X-Stat-Signature: w8pt41ig7e7fygx41x85g1g6idht8ani X-HE-Tag: 1682306159-525314 X-HE-Meta: U2FsdGVkX19eUgIeJs0FVm7ciMprPxLk01lkZs9sQlEyZJU0beXpo36UbRhklY//+oba3o7ZOGV9/+ZeojBVa4Wk4HvEnLILElsQGzIfFffW+nImVx5BYrnBpqKMxxfOHpE/A9gmo08qerkg0qfSwETYCKTV/9UpbnwjMVpwqio0DxZeJhdzO9VGzgx0+aQX03AP5QUyGMu05WeLI4gDOL/UBzb4XrTIthxGOpHga6jWlmUynt1GxM7pdk6EaaJIBphVBOx+GOxSzwdUCv8ULmWMJkOGdgaeRZInG0JaSfz3HZSkJaz3dCeQn+1yYjVRelnmKMPt54jboncuLmHmagmQA8HB52lU+G6YwB6BighT8afoIGntYYS0vSQcUlLI1BcnpuKzUx4/2uLAr69qS7R2lj3yfzq/cPXvNwO77Bwqn4LuCJ9vxslk6wqqoG66ZHkeeT/4zOkGyQJjQ12ey1HM/gQF94/qtsG8/+FFkPCdSBvG4EUdWcScSgkDpmJ+LmGajWl4EJAenUd+VZtuP7+0XnfOSA0wSXBrO8UDZMVnjCA1Vxf53RIh9LpVVZ5SL/LowlWVK2zOxeX1musLjmfVbKAm1j6OjNUnJnf/68TFPd6TeKf9TJRRUHqgqDRVW+KGJhHTXZ3NfEJjy8th6xH0ebwe56JHPZOddX/gsWZmkXwTeO7T3K557mfUmnEbNDShptNPRxDP73RuU3mnKP8lfKaSUbLNrREI8MgqrpuoJnmoIg9Vge2l4+INsu+gStNjID+sh4okQydKkJ76MdMN0WsCALPMgkHuyAm5/zo455yyDWwCABFKrntH+RP6B9aKRaeRVt1/GjxtI1F0mIUdik0uctq90Las8Pto7pdxiZ68zw4MYkXQt+YkemYkInrq/UOLAjGbjyc1UMH2bp2Ytiabiv1vH4o6viB8NpmigPrPO81O4lOD/sY1cCTvrM8NLvdcXYHCTxF5inD gJ+k2dbN rGS9O/cFR5C7fNDrAfIStVLrCObgAW99PLA0v12aB4s+uaFimu/aYS1Pf+Ldm566GG8XGq6UniapDsOblrScWlDEG3+apMU3hzaBGS9NO3iz5z9v3l3gtNXA+R8Ya2XGUekqZ5GCiwWwstiP55kkMKAk7cbAP/ikv1bc2Hdem4sIzAStd5kxOXJ6wLL1zdVFSnnoHfvmtRb+vTQmrN802xW6DTvE5zn+dEZ5UORtRFf9n0QQNqlDrgAZS2eJw+L8lfbJx7AbiajMHVP1hJmCDOzRVPw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Sorry for the late reply. I just came back from my paternity leave :) On 2023/04/05 20:26, Hyeonggon Yoo wrote: > On 3/15/2023 6:54 PM, GONG, Ruiqi wrote: >> When exploiting memory vulnerabilities, "heap spraying" is a common >> technique targeting those related to dynamic memory allocation (i.e. the >> "heap"), and it plays an important role in a successful exploitation. >> Basically, it is to overwrite the memory area of vulnerable object by >> triggering allocation in other subsystems or modules and therefore >> getting a reference to the targeted memory location. It's usable on >> various types of vulnerablity including use after free (UAF), heap out- >> of-bound write and etc. >> >> There are (at least) two reasons why the heap can be sprayed: 1) generic >> slab caches are shared among different subsystems and modules, and >> 2) dedicated slab caches could be merged with the generic ones. >> Currently these two factors cannot be prevented at a low cost: the first >> one is a widely used memory allocation mechanism, and shutting down slab >> merging completely via `slub_nomerge` would be overkill. >> >> To efficiently prevent heap spraying, we propose the following approach: >> to create multiple copies of generic slab caches that will never be >> merged, and random one of them will be used at allocation. The random >> selection is based on the location of code that calls `kmalloc()`, which >> means it is static at runtime (rather than dynamically determined at >> each time of allocation, which could be bypassed by repeatedly spraying >> in brute force). In this way, the vulnerable object and memory allocated >> in other subsystems and modules will (most probably) be on different >> slab caches, which prevents the object from being sprayed. >> >> Signed-off-by: GONG, Ruiqi >> --- > > I'm not yet sure if this feature is appropriate for mainline kernel. > > I have few questions: > > 1) What is cost of this configuration, in terms of memory overhead, or > execution time? I haven't done a throughout test on the runtime overhead yet, but in theory it won't be large because in essence what it does is to create some additionally `struct kmem_cache` instances and separate the management of slab objects from the original one cache to all these caches. But indeed the test is necessary. I will do it based on the v2 patch. > > 2) The actual cache depends on caller which is static at build time, not > runtime. > >     What about using (caller ^ (some subsystem-wide random sequence)), > >     which is static at runtime? Yes it could be better. As I said in my reply to Alexander, I will add a the per-boot random seed in v2, and I think it's basically the `(some subsystem-wide random sequence)` you mentioned here.