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 1D583C77B73 for ; Tue, 25 Apr 2023 03:55:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 22FEC6B0071; Mon, 24 Apr 2023 23:55:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1DFDB6B0074; Mon, 24 Apr 2023 23:55:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F6E06B0075; Mon, 24 Apr 2023 23:55:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id F40146B0071 for ; Mon, 24 Apr 2023 23:55:27 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B7187140485 for ; Tue, 25 Apr 2023 03:55:27 +0000 (UTC) X-FDA: 80718548694.19.51BFEEA Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by imf28.hostedemail.com (Postfix) with ESMTP id 3DCDDC0004 for ; Tue, 25 Apr 2023 03:55:23 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of gongruiqi1@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=gongruiqi1@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682394925; a=rsa-sha256; cv=none; b=QLBKkIC4NkWIfA22h5iVododg3a5TZJp8f1ffPy+MY3sy6JMjDj7ML2VUlP34aUv5qeGPh Nk0irin5GpZ1oZBoDixrder0WGO81DhIOeUKQlcc32R5GdzFqV/GxT/xtuZ07Vx1rg25nG qPqeXy+xOyqx/Y2HcnlCUkii94zajiA= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of gongruiqi1@huawei.com designates 45.249.212.189 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=1682394925; 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=CoEKKzOJt3kg3DSMXzb/BFd6QDKZKPpl6ThiVhhnRcc=; b=RH4Yh7vFqxCuEc93knu9hXMW6aZ0U2cyrqX4WyosfDSYKXY877wv/fhV834eMcoO6H3MM8 xdzzmxEM4tneSOhYWjEeInrKvzpu7s85UnARN2mOwwUOK2090AjcqI2xU0zOL7Y6Vlt0fW ZSr6grSv9R5zlasd4cPc1GB17g8Jg1Y= Received: from dggpemm500016.china.huawei.com (unknown [172.30.72.53]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4Q57RK54VWzKvMB; Tue, 25 Apr 2023 11:54:21 +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; Tue, 25 Apr 2023 11:55:18 +0800 Message-ID: <0f3abe0f-216b-dda6-38c4-26ffa79d966f@huawei.com> Date: Tue, 25 Apr 2023 11:55:18 +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: Alexander Lobakin CC: Hyeonggon Yoo <42.hyeyoo@gmail.com>, Dennis Zhou , Tejun Heo , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka , 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> <36019eb3-4b71-26c4-21ad-b0e0eabd0ca5@intel.com> From: Gong Ruiqi In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.110.48] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpemm500016.china.huawei.com (7.185.36.25) X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Queue-Id: 3DCDDC0004 X-Rspamd-Server: rspam01 X-Stat-Signature: foapj33yjzfapsqdn1qabxiix7ehs783 X-HE-Tag: 1682394923-686843 X-HE-Meta: U2FsdGVkX1+Kf5pB69OxAd4dO4zlnMNMUq1QZw2vvGk6/GniCk6XQ9CrrcphfOn0m7JutXg8Quc9A36OmmeT0NpIRB5NoV6oxHvk+W14IykFdpyu0+Kkx6oXMdPFb/hGx63rUh79gxq+O82pkWOVALP/X30QEHpr+CI7HgR7KLNFDXAzq6EYAvrSyGe7KxcqOGhiEEAq0/SgmslcaDaoYwOLAHJ2HgXTly593jw2Z3dDB4wAPGnMv3w21vWXGEAmhgqH657MGZBB63Ci1D/sMDhIMpZ/Ii19LdBnL4PZX4gZWZhQlmnvUPKFTThYjtAjE+npY+5jqcQ5aCBT/zV1lXpE++bH2uocYI0/+St6cwjAPRAiW05T7RxF7JrVyM5OvNWH03vACHVl3aesiyQuhqd9txDvJlLxrLuDU9qbpUHm7CPnbGKnU/TegomebfI6HFwsmkFIfMKy6++ebueN1KB1HaV2tSJhc/b3AOjPP3mgSjPU0jNYrSozFmhvIL+kWEcyCXC+TDkTSDwgXVrYjDhFi+IkB3JJCPpKgDBo4zuboqsqOCh9tJNPNbEF1FLRC98QvrlSPhR24aVD42DHnR+eW+E3w92LP68aoOBTLb5PaSmaMae/HS/Qt10h93IjYQhZrbD6ullrRYtdh/r2WCMtORXGhnptJc6hJVhLRd+7v5yUsP1nmXWSsMwpA8aou3K9xSLZvmueVO98G3SSQOSQXWmLzeNqlLsX+EXA2Rpxb5N+h1aZGPsjm1mjBAYNC1l2tyNNYNNbTYxXYXhbS7Ug1KQlRSvu/jJ/xRYBLDtKb+Q1eSeI9PaG7KiA9BARwDd1B/f+h8uuvHH1wb43+vStkTKaHO07jOAQHyYwCSkmIyhMbAB+L1MxHtGf+9eFr91DjlGU6niAhUrukQQ7rdyvmX5Ps7yFbyCd2PrVsHz3UGhnvHCrTVFIWLkK5Haxf1oza8qn+DsX0U8uK2i 5zEqDxS2 4iPeLBs30HuJhA4aKyau+a3wfKdkfEFAjvfLlxeyYBFo+5bis4Dr/Vx1jAezVb6HQkm+mUURaMHqlJOJyD4kR5++SHTP1KIKk+c3vwX/6I45KcxMqdl/YThY9bWhk0oM0h3m/o74EASEY2kE6NY2mBuqZ1vhlgC5i1EOwgBFxJl+kRwzp+JtO/ch5zxNtd0BGfVYCRJceEpOEXMv4F2pV3CHOujwkfpuKx2SFvYw2JUAq0fnviFUyohCeFcOHtu0ijQQAFKC50C354He5cBwPa2hJig== 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: On 2023/04/24 21:46, Alexander Lobakin wrote: > From: Gong, Ruiqi > Date: Mon, 24 Apr 2023 10:54:33 +0800 > > ... > >> >>> It's fast enough according to Jason... `_RET_IP_ % nr` doesn't sound >>> "secure" to me. It really is a compile-time constant, which can be >>> calculated (or not?) manually. Even if it wasn't, `% nr` doesn't sound >>> good, there should be at least hash_32(). >> >> Yes, `_RET_IP_ % nr` is a bit naive. Currently the patch is more like a >> PoC so I wrote this. Indeed a proper hash function should be used here. >> >> And yes _RET_IP_ could somehow be manually determined especially for >> kernels without KASLR, and I think adding a per-boot random seed into >> the selection could solve this. > > I recall how it is done for kCFI/FineIBT in the x86 code -- it also uses > per-boot random seed (although it gets patched into the code itself each > time, when applying alternatives). So probably should be optimal enough. > The only thing I'm wondering is where to store this per-boot seed :D > It's generic code, so you can't patch it directly. OTOH storing it in > .data/.bss can make it vulnerable to attacks... Can't it? I think marking the seed with __ro_after_init is enough, since we don't mind it could be read by the attacker. Given that the code paths the attacker can utilize to spray the heap is limited, our address-related randomness in most cases prevents kmalloc()s on these paths from picking the same cache the vulnerable subsystem/module would pick. Although _RET_IP_ of kmalloc()s could be known, without tampering the source code and rebuilding the image, the attacker can't do anything to make those caches collide if the cache selection algorithm says they don't. So in my perspective the per-boot random seed is more like an enhancement: if one day, by analyzing the open source code, the attacker does find a usable kmalloc that happens to pick the same cache with the vulnerable subsystem/module, the seed could make his/her effort wasted ;) > >> >> I will implement these in v2. Thanks! >> >>> >>> Thanks, >>> Olek >>> > > Thanks, > Olek