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 3F5ACC7EE23 for ; Wed, 31 May 2023 03:47:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8355A6B0072; Tue, 30 May 2023 23:47:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7BE396B0074; Tue, 30 May 2023 23:47:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 65EB7900002; Tue, 30 May 2023 23:47:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 51F546B0072 for ; Tue, 30 May 2023 23:47:56 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B244CC013F for ; Wed, 31 May 2023 03:47:55 +0000 (UTC) X-FDA: 80849166510.10.DD1F497 Received: from dggsgout12.his.huawei.com (unknown [45.249.212.56]) by imf02.hostedemail.com (Postfix) with ESMTP id 24F6980003 for ; Wed, 31 May 2023 03:47:50 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf02.hostedemail.com: domain of gongruiqi@huaweicloud.com designates 45.249.212.56 as permitted sender) smtp.mailfrom=gongruiqi@huaweicloud.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1685504873; 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=teIb1ws+7h85XoaOmgYta710dkH+TvsA+RviMTjWXwA=; b=SAcaHJizdZecwR5JWSVYTEvrSJD1yuxJVFOUow59pGENk+7h32lolB/nBrB7sZ/jy53pzx sFNvWOBS6esLsUqb8x/GlS5A71W3xsPn6IA7wYpPlX4aVfpObXkUNVPLwtd6DynALPRiFn EukZDHvbDwhDumyVscBjbBB3bcN1l8g= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf02.hostedemail.com: domain of gongruiqi@huaweicloud.com designates 45.249.212.56 as permitted sender) smtp.mailfrom=gongruiqi@huaweicloud.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1685504873; a=rsa-sha256; cv=none; b=DtDDq8pIP2VL4CLfpuv5Ukxnp5fcP/AhNwayxEdpYrY9+uQzgimLh/vCbOErBuNjgTj9Zx oqmran32qP5uTGAiQ/zV9xcemusWqNvdCLA+QmaG7Lz13gta2zm5iRSihVvDwaWVoZC1Dt 00ggSod5bpUGQrpqaWj6e6Iks5GdYT8= Received: from mail02.huawei.com (unknown [172.30.67.169]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4QWFb34Qd7z4f3lKC for ; Wed, 31 May 2023 11:47:43 +0800 (CST) Received: from [10.67.110.48] (unknown [10.67.110.48]) by APP3 (Coremail) with SMTP id _Ch0CgDXzhxKw3Zkmo0aJw--.10451S2; Wed, 31 May 2023 11:47:45 +0800 (CST) Message-ID: Date: Wed, 31 May 2023 11:47:22 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH RFC v2] Randomized slab caches for kmalloc() Content-Language: en-US To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, Alexander Lobakin , kasan-dev@googlegroups.com, Wang Weiyang , Xiu Jianfeng , Vlastimil Babka , Christoph Lameter , David Rientjes , Roman Gushchin , Joonsoo Kim , Andrew Morton , Pekka Enberg , Kees Cook , Paul Moore , James Morris , "Serge E. Hallyn" , "Gustavo A. R. Silva" , Gong Ruiqi , Jann Horn References: <20230508075507.1720950-1-gongruiqi1@huawei.com> <5f5a858a-7017-5424-0fa0-db3b79e5d95e@huawei.com> <19707cc6-fa5e-9835-f709-bc8568e4c9cd@huawei.com> <1cec95d5-5cd4-fbf9-754b-e6a1229d45c3@huaweicloud.com> From: "GONG, Ruiqi" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CM-TRANSID:_Ch0CgDXzhxKw3Zkmo0aJw--.10451S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWFykGF15GFyfKF1xGr43GFg_yoW5Aw48pF WIyFyUAr48Wry7Cry0vw10ga9av3yxtF1Uu3s0gw17Zr1ktw1xXFn5Kry09F97uF45GFy3 ZFsYk3ZxWF9Iy3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvIb4IE77IF4wAFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6r1S6rWUM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x 0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7Mxk0xIA0c2IE e2xFo4CEbIxvr21l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxV Aqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r4a 6rW5MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6x kF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE 14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf 9x07UZ18PUUUUU= X-CM-SenderInfo: pjrqw2pxltxq5kxd4v5lfo033gof0z/ X-CFilter-Loop: Reflected X-Rspam-User: X-Stat-Signature: yxxaadn9hod7unzajbfukc4nzpggegdn X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 24F6980003 X-HE-Tag: 1685504870-840893 X-HE-Meta: U2FsdGVkX196tC5n8dhbrQo3GTUahgX1J7vVG8XvXNLe3510C0sERDqNiFDqbnFQbpoGgjAP1b5Mx9KE/Ye9OLvsYUTjGKd/+8lMBSc7Wdi94BnEmj1U8ia+1uQBQ3V4moFvQrQEwMJXEIpRyizlMzxT520gQBz5rX4i9GcVCXeYfJvbbdEtBuUOzyYbekdu8PizOENzq7eXtm5qDW5udqq2QqnGtAncqT3ehkc81lek0573FwGl2w3cuVhhxIKdU5hmG4lW7nVIuJZhoKZyk2h1qGQeCGTnG/02kIOZ0tFl6Jcw0ATGpzOg1QgryGmV8yBhhwlwsY9uLC9kBs3Lh4EyAhRXcXCzvB3Yuu6wMRPt00/UtMBTzias+TTBoTXTAm+S33vYMuKsZkUP+K1/2uw8BlpPTpGjfHZ3iy6bBPFDqmDHgqd2YTaOyLLpQJd9m3x2jBQJUkT+CI5gas5PJZbRpxhg5Y+o+DoS8N8AjffCpGe3gWnoHDDjkwfiqFIjau2JQUEeCjKFri5wjsu3FVGQnlsZWorp84vuQFJDtAH5w91ffPFGPD86G6X54z44PprQip1eZDxmJrn4WGvdghnL5lL0rOXmIkrnz6yLFGbolBOSph1wTYZUlt8fAzN8pWRezAG9u1JNnz8XK0VjJWl/FrzS8PJkVLItH5XZMtVVeajDljC5IbCsRFE01FFWq3Rb704PE/9SsdrW5y3qJCo/f40uw4zvd93I4vFrPE3d3+8K2ekOodsZgwFYYIVnsMPAFX3k7t5fLyNh0U8NS/0aK1Y+wLnn1BjGHI4c1RTlcmG6O+4bKx9KFsnexBHbI1FkMZvHFlsDV1W9K1jwNyibhiQ+el/5eXPWGimmNF36v1IigheGEDh9OdK1xOIslhKxS+1xCTpAzD8HOqVYCwN1CE0VV6idzujij0KswdPn8jeAaUlTZV0dtRk0ZWChVetauD9zORzD0QFLDQS kLw9XliU GfVRtzSfw3OjtwZiyObmpJ4l3RSFTzop1lb1/MpibHYe0HCj9A6amegW0W6vpMuVvJMM2eQB4dwLngdKSD+rPwmzMpGNrGrG0B9X1YVBl4icUmqRcYgPVRSd+XC6Hi6zNKKbeGYmA7/T31U5C95IrZy0pUhMXHx9pkWb5KNBq3KTNRAnkV9b1MXZKAFIh0z4xmEikuotJZ42PPQSKMNRJJgUiTcM4B4igLGhcAkTOWn6rqS5xyUXjy2+sUMp96dy1jT46v/iMxtS+UsI= 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 was trapped by other in-house kernel issues these days. On 2023/05/24 13:54, Hyeonggon Yoo wrote: > On Mon, May 22, 2023 at 04:58:25PM +0800, GONG, Ruiqi wrote: >> >> >> On 2023/05/22 16:03, Hyeonggon Yoo wrote: >>> On Mon, May 22, 2023 at 4:35 PM Gong Ruiqi wrote: >>>> On 2023/05/17 6:35, Hyeonggon Yoo wrote: >>> [...] >>>>>>>> +#ifdef CONFIG_RANDOM_KMALLOC_CACHES >>>>>>>> +# define SLAB_RANDOMSLAB ((slab_flags_t __force)0x01000000U) >>>>>>>> +#else >>>>>>>> +# define SLAB_RANDOMSLAB 0 >>>>>>>> +#endif >>>>> >>>>> There is already the SLAB_KMALLOC flag that indicates if a cache is a >>>>> kmalloc cache. I think that would be enough for preventing merging >>>>> kmalloc caches? >>>> >>>> After digging into the code of slab merging (e.g. slab_unmergeable(), >>>> find_mergeable(), SLAB_NEVER_MERGE, SLAB_MERGE_SAME etc), I haven't >>>> found an existing mechanism that prevents normal kmalloc caches with >>>> SLAB_KMALLOC from being merged with other slab caches. Maybe I missed >>>> something? >>>> >>>> While SLAB_RANDOMSLAB, unlike SLAB_KMALLOC, is added into >>>> SLAB_NEVER_MERGE, which explicitly indicates the no-merge policy. >>> >>> I mean, why not make slab_unmergable()/find_mergeable() not to merge kmalloc >>> caches when CONFIG_RANDOM_KMALLOC_CACHES is enabled, instead of a new flag? >>> >>> Something like this: >>> >>> diff --git a/mm/slab_common.c b/mm/slab_common.c >>> index 607249785c07..13ac08e3e6a0 100644 >>> --- a/mm/slab_common.c >>> +++ b/mm/slab_common.c >>> @@ -140,6 +140,9 @@ int slab_unmergeable(struct kmem_cache *s) >>> if (slab_nomerge || (s->flags & SLAB_NEVER_MERGE)) >>> return 1; >>> >>> + if (IS_ENALBED(CONFIG_RANDOM_KMALLOC_CACHES) && (flags & SLAB_KMALLOC)) >>> + return 1; >>> + >>> if (s->ctor) >>> return 1; >>> >>> @@ -176,6 +179,9 @@ struct kmem_cache *find_mergeable(unsigned int >>> size, unsigned int align, >>> if (flags & SLAB_NEVER_MERGE) >>> return NULL; >>> >>> + if (IS_ENALBED(CONFIG_RANDOM_KMALLOC_CACHES) && (flags & SLAB_KMALLOC)) >>> + return NULL; >>> + >>> list_for_each_entry_reverse(s, &slab_caches, list) { >>> if (slab_unmergeable(s)) >>> continue; >> >> Ah I see. My concern is that it would affect not only normal kmalloc >> caches, but kmalloc_{dma,cgroup,rcl} as well: since they were all marked >> with SLAB_KMALLOC when being created, this code could potentially change >> their mergeablity. I think it's better not to influence those irrelevant >> caches. > > I see. no problem at all as we're not running out of cache flags. > > By the way, is there any reason to only randomize normal caches > and not dma/cgroup/rcl caches? The reason is mainly because based on my knowledge they are not commonly used for exploiting the kernel, i.e. they are not on the "attack surface", so it's unnecessary to do so. I'm not sure if other hardening experts have different opinions on that. > > Thanks, >