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 A0FCFCA0EC0 for ; Mon, 11 Sep 2023 21:21:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CED0E6B0305; Mon, 11 Sep 2023 17:21:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C9C446B0306; Mon, 11 Sep 2023 17:21:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B63AD6B0307; Mon, 11 Sep 2023 17:21:20 -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 A036A6B0305 for ; Mon, 11 Sep 2023 17:21:20 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 421A8160B26 for ; Mon, 11 Sep 2023 21:21:16 +0000 (UTC) X-FDA: 81225587352.19.1F509F5 Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by imf19.hostedemail.com (Postfix) with ESMTP id 4069F1A001E for ; Mon, 11 Sep 2023 21:21:13 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=dustri.org header.s=gm1 header.b="mPNTD/3C"; dmarc=pass (policy=reject) header.from=dustri.org; spf=pass (imf19.hostedemail.com: domain of julien.voisin@dustri.org designates 217.70.183.195 as permitted sender) smtp.mailfrom=julien.voisin@dustri.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694467273; 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:dkim-signature; bh=b0XvMYLh9/MC3gxuFXLDQKkOMU9w8ZJazb0YgA6oPTk=; b=q6iRE+aCKqgukJvAFqy6NpVxqzL2mFXhDCFcEg2tpV0JCOAisVN6E0QqwISsapNiJ0ilGd CzT+3MRlY5q4LrzQI2t1Dw/A9WMKFNaD5kSrsh3hUkPFn1Cheq4zJWH+IUzD1Qji3CYYM4 F1bSH6DDRnz3TGtWvkniet24M/gCW3I= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=dustri.org header.s=gm1 header.b="mPNTD/3C"; dmarc=pass (policy=reject) header.from=dustri.org; spf=pass (imf19.hostedemail.com: domain of julien.voisin@dustri.org designates 217.70.183.195 as permitted sender) smtp.mailfrom=julien.voisin@dustri.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694467273; a=rsa-sha256; cv=none; b=76Om/3bwFK/sn1AECJ50/d8Ojj5rWMb3qfCFC9tSit3jR6BW9SCsqoc64dWrF3oLHPx6o+ n/8AZ8l4/sV+QmaBu4EmmPvi/v25TG8NYS7CaCKp7m56Av8oxmYcVaRVO5UdBUTSxeaHC7 KNkhWFKf6lbuzEPSv/6Di3Hj7VPzAiw= Received: by mail.gandi.net (Postfix) with ESMTPSA id 543F660007; Mon, 11 Sep 2023 21:18:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dustri.org; s=gm1; t=1694467271; h=from:from: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:autocrypt:autocrypt; bh=b0XvMYLh9/MC3gxuFXLDQKkOMU9w8ZJazb0YgA6oPTk=; b=mPNTD/3CCFlTXK8D2tNaHmgm4PIe6xtxAwQ8tWGMhi9PN67MtdJceeexPzaWzCAMRhfY6j VHP6P8F7h6MwB+kd/ARwiqBvFZ36hRdm28LMhLBiPBNrZxjV+PHHphwHne6fhpt2tyi8KU NGfGgFCiKJnMUSEXwfdcE115+yUKuTYaRK+m6zVjehHHHnGedSyRUEjbmgyKhpHA05SNvA XhJ0XRi30fADIBZt/cQtqBXCpAjS+hlDGD2V/djdSSCP46hkP2yz/1BYKqpBfBYngcoBZj ORMLdx4mHn+rdWRU4lAaaMLaOzRa2CVqwcbCyVpXSZFufli89yIXcU8qKGh1Yw== Message-ID: Date: Mon, 11 Sep 2023 23:18:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: gongruiqi@huaweicloud.com Cc: 42.hyeyoo@gmail.com, akpm@linux-foundation.org, aleksander.lobakin@intel.com, cl@linux.com, dennis@kernel.org, dvyukov@google.com, elver@google.com, glider@google.com, gongruiqi1@huawei.com, iamjoonsoo.kim@lge.com, jannh@google.com, jmorris@namei.org, keescook@chromium.org, linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, paul@paul-moore.com, pedro.falcato@gmail.com, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, serge@hallyn.com, tj@kernel.org, vbabka@suse.cz, wangweiyang2@huawei.com, xiujianfeng@huawei.com References: <20230714064422.3305234-1-gongruiqi@huaweicloud.com> Subject: Re: [PATCH v5] Randomized slab caches for kmalloc() Content-Language: en-US From: jvoisin Autocrypt: addr=julien.voisin@dustri.org; keydata= xsFNBFWzxaABEACu3G1fwzHtrhHuotgvZ69zA4YqF9vYfx7hoYrjnKzP5pTiOZ2US6AJj1qE W1WlN6cHnqzzqoXotVu/MPuPrbadL21jRnJWurrkktpcqK4BaCZ5S0lOQ3ck40LysidexhI6 ZZi6jhBZzuzxs2Mi9aIPIxDekXAWQBybs4m27E4MNmJkIshVnDTMQ4ToGQxzwPj+VurpQVPh WGMCPwlUbVkN/w6N/lLC088ePpESh5E0vFE+BQc66ZpRn+cXTlaqjQnwRtWuEBoqJSn2MXAn wODEj4H5HvQjgFyRfmOHHMTEHOg4yyc84SmIv8YJlTbVX7VnMGUJF43SA4PFtXFypBkQ481u w10XdBPYwD/i0q3QnzzRiIsrlQJUCkGFxyIpcDNRnf3ApjT4+QuEaw98tKvgRzCozFx2D94w sSFz858vZrdYj4pt/VYw8JeoPDiWwuzPVvgpJmQlL8aCRnAhLIv9O+fySvXcGh1WEvtUgkNn 1WjU2M00BYnPNFBEeGMRWkxuVwV1o+WKNJfwg2UcDghSkJGBCPCAiC2fDlfyk3njjLjxZHP/ mYNwUkxTlQolzknJZ5wg7vbE6r4rfQX4gTi3mNzYtqUAb17GIczOARZK7qdSapObrXPFGgX3 Bd4FZJEaIq3p5xWcWS8fcMveoYO7m9cyaSkSQxAPrPZE3hDF1QARAQABzTJKdWxpZW4gKGp2 b2lzaW4pIFZvaXNpbiA8anVsaWVuLnZvaXNpbkBkdXN0cmkub3JnPsLBlwQTAQoAQQIbAwUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgAIZARYhBJ/N7p4aOB8xHqYqdATQQegXGQHMBQJfDWXp BQkSV5eAAAoJEATQQegXGQHMKrwQAI8gOcx3qRk7T5qBgg9rlk3WDaJWcmw1Dq2VnjKrEVLh vxvwK/CjiaH4g6oUiGNeDVBoozjzKM/umHL7SoBjhHiayEu33ziAjLWxiVGbHVmHmfXkZdQz CEBSI1ZR8HF88tFCCOCtK7Nc+1yohmTnfnrIIEXMpSvAgdFilwnjYbaNe+aQ9MJMo+k7J144 h+BzN5EW19zVwOidUdD0HxKpCYz6D34etnYIpv8Qa0KBzOPTtO1QYr6A7MfQPiRVlIOA543g h9bi9SQhCBsOZU1NOVQUZ3/ktj8qlUTVlOhGKYaPvJJ0X9va02rzL7zxYcVZgQic2dTLGYW/ GGHVseegnxWB/7V49Yf4ZljQvjK2B1COmahZ2UYN+fzqXO0NhpSLX4SDKDnvM/3X2TYWx1MS fY8x4IURA633TTW9QZzflqIYk4aO44/8MDiuaxLwt+e6d8EN8ECaAoVFPCq1dWTjCJ4XhSlb 6eV8trCpLZfkVviuRD7xPtZU1sViVSj/O9naQ2HuUq0+LuYBmI25BEpq2rkgVKS++sYgUtxO IP5WoQJeNNnS+8e15VRdb77WxRe6+05JNu48wZI2OcW/MiyFs+cGtoDC5mSpVuJTmpPumP7A hjlxy4e5YlQn6coqQcuNL1DC/vUFwO1/cnh5dqk0x5JfHL1/XFWYjsVNjuJj/vIQzsFNBFWz xaABEAC/p5ESSIlC6qVJnxfhtIpappjkHmFjMHWmFrB05KnmtGB/InGH0e5y2OVaKz0RErLd f2CAzU5zb9cyLPnqHpE7SaqtPBmahTBX7nVzIFrbjLpU/XPHaWrHa6M1ifyu1y2msXe5U1ln oOVjJXTVsyoNAt8wzf73I4St2+pY7kQBlv5AUTssa4T22hZs3BImcd4OsLpct2aIGd3NGofN ksiLB3ZiE/vKJkXWIbx9/hm8nuKlQuHGo+sHho8T+QQcc+YCo66BYBznzD+yEv/UALjgHWU/ PXw3RVM8kqQ3WlmWsYKqQYgkaA2cVPrkbLlxiHg28Y4deu6oZR4oSovXjJk4jj3m/UckaN0f c47BG1VwKVHxjg/c8hy1elunhJv0Vf2eLA6pc0UfAcpSkJZNkOLjFZ9YROHdiKiUE4pEej4/ o3WE76TIX58aURuouVAVwe14sIED3QLoO+4wczTZsOX/jcOg2D2qPquby5taOAM6yPP/v7fy TAG9UYdxq1L9/wKwhH1pmagkTmLu7k5XzgQ/6rrR4NJPRRMETrtqDFJNb2UxhRlnl/Cavkt6 5BK7D0QJ9n9phFWC2oTIaMd5suFZK3I71UdeTaBOlrqmqLzuBVhzQeAK2vaJI1c6IzqjGRlx PEm6BuHfRWaf+LLj4Z7wrupWwAxLjHgPUCL2Chk2ZwARAQABwsF8BBgBCgAmAhsMFiEEn83u nho4HzEepip0BNBB6BcZAcwFAl8NaJcFCRK/pHcACgkQBNBB6BcZAcxUhg//fmeZNMlB7NPJ bT4dLsnSTCRAl1zqCxqowPyG4ux79qiG73KW/vLT1EUQTm4ANyl5Mwyf+3ssfzxl/Flp7i93 57rENZRMWj80JluU8w68sUrxKlTNZfrukHttoNPmTh9TTuvP0yQXysJyy0p6VvdBT5euf2Iw LMERoaln4h2VuhLSL80VcJfou0TVl9Aq47HerwTPXQdC4Rm/bYrdDdZhEJMrEQuDP6eLIjmC 4vI51LwnPcXABan3WudfEaxdpI9acwcCy9XQ32vIjhxV9D3fx0dsfo6PDXFdKEY9q+bfOjUt GyqZWRtqe/EWM8T1w4H4svpGpTh2mB8Du/1jNy5CiSgLiDySd6Gz8vP0rqFGYuLN1fCBNpd4 PzF29dPO8xJ++K5pVi+pXpKzIfW9f2ZL0fabrsKP1Rht+q+3ldgGSvgw3v2aFffvEuRmodiY Vkby7UMuABQGlgE89z+cffBRhelgNzoVs/PtIuWb/y5BgOBGD9zUn4Z2FjB5eby230qkP1uQ +vyunBj6QnANa7qBxycL+xXbW8HBksArQ/HX+OZs7hagrP0qGMnjmCzsblv0wixghgvQTkpg 61RTH34ieLUkzE0oFkrqJyNZcoH0wStdP/9zwK1Av0cZcFcvlLdIL956v4IpZozW1ScG7OJw 766VTOg4l2PTPCnIdNFy1Os= In-Reply-To: <20230714064422.3305234-1-gongruiqi@huaweicloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-GND-Sasl: julien.voisin@dustri.org X-Rspam-User: X-Stat-Signature: i17h4od1igpytprcf9px94cfkipqf1dr X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 4069F1A001E X-HE-Tag: 1694467273-553869 X-HE-Meta: U2FsdGVkX1/m9AgTSwfL/mVZPRhmdIbLgObL9bG4Her+VDcTg04WYbZDS9PLi88Xlkw3ED+7m1VKqBeyt6nJie4AwVVYo/+MZW80tEOAIqORerIgqG1ZF1L1teVofvpsyCGUV7UoFYEmZqh/LXQwoP1I6vHRYpYl7NTb/AhN4wu4cidL0zZh73aFoM8SpKE6IGJx8iXVxqTHTaYjDuJ7nEYX3XtymhlxNApG0YtW01Ng+mUScP0hueLwEQeTofewyzAoJ546on6h7+9Yi39l979h3fJY/skDkBgd0X3NWS5ZqRTkoOvJ8L0lor01IjD2vCaFYUgNN3nLD5EFqUYJDBgmovzKDMFR3YoaEshSy8yXgG1zlmZpxjcE38BmtdQM+nx4BrmBnhVK1/M+tKj1zOp9U5HoG7kuNqFeak0bRXuiHllLcmiun+kFBvVlWMhZaHaL/VdDCkNiEJyfAOF2QNW7ssbY4dQn/NsdsbnPrh+dTYJKnwwT20vDmN53ceHRI+nBvkxvFPx7qwSv+bWueEs4oUVUWCjkXbgaap6OPI/m7LnrFtNHIDF3x3I9cf7oA8vyAmnUuwW2m7c0u4iaDumdztVu+3AGmbDA6FsJFcwYHTtzp3MqvFx9VthkhcSiHAWfsNyu/Ca2Z0a1YQ+Axd7W+bwuJGwchO3E7KXkYga3vf1UVfyTi/PXCA7fbOaL+gebRqMP+hdkwyRnv0/usVnqvqUnLDsmM64yy/3zGOBSo6NvNh/NpU0wvkRGcBKtf7YN0VeufoKrTFYtlDWP3QyN1a1nE4D0FtNItJmk7UgJzvrVvkSQsZgvrHckVO2UNn06volp4BagKL9H+HEGbnzNc1wxoqRrfH+j2RDNutObCY7KZ4JWFtYJioEzA4IXlDG81bso3Vv5FpyyD/GjgQxSOAy94Eg8YSSX+L+V4K2kr6sqAYCHHVPvHAzCCFGvDJETA9tE+nJk1JUOC8+ 1F19c1Qi 0cA8kc2poSGbHkcq/x1jN4CwnkgtuDcv/0twquCElV2kUbPWChQxLsHasiXTtmmBca2vL7G+YeN1W2ulg5pNUB/iduSNp9Fdksuw0Y2C+6R+ZF6RzBOdHB3/N49kqDxLDFhvX/3kG4gvZ/CQuG7JPR1kM4hwrAhmmb1M9z1jhSkJoxeI/4haAwKj7avNmrJ4Pdar11BDvjaNjY3NMKHVZdzoHhqHhbFU639ABaymnVVB0qdCIM2CLkrF4JN0II1Imcrv9hy379NPGo1Wyiejxy9iY3J0cFX1Gh9PtUIcB/fMmHxlXutLzH1c8dQ01mnRoF5qMYIXLiRVhsMql+2FNK1F12gz3q4lU2tgifG6Lbk9DNYMYwmFQ87FFW9g9QsJ0eLcn6SCz6GbIH+xubs7M+1rJc1sL/4dKbr+ITWC1o3m4JwG37CXBQG1UjRIWbHoSi1K82g+BRiYmx4iYvBjyrdtq5T/66hJIrhZUm15AjIiO3Ia4KFSs3Mp/EvSVm2MpBJjO096LjH1Z0x45mGkzzOfDJBPNIXBijIR690TuaAwC3riYBkagAHPElLi1qeB21M4D4rYR6mRqo8+zWxszxu0cjX9thv+4h3wt6gVgGsanEGCzyBvlESGL5bCMgrocYMbsWNV9ky/0ba+25H+qsEVG0uHSH23evL8vWjJIdtJ7BC8Nk395VpWkxN22VH7ypOhydxr00ZAXblyCxYwM4HxQrk0vpDdkWsQHE1VtoEFnnv8kNq/px7071JJ57H7RCzulRT3Molm03nBhvybffluagIh8M7DC3mNCW5hdcWr32P6VJQFrnJ+d6+A0oVC1D6C48CsuWAn+YoGcleRFaiNn4/Bo0e6/kKLge477vLsPHe2fTIXqlm5GLJPA6PyAoNvjrCj3ST8Oz3uFXq0CAac8KRYie0dCtXeah/uLabGV3H1qV2ljT8I17g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.038740, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: I wrote a small blogpost[1] about this series, and was told[2] that it would be interesting to share it on this thread, so here it is, copied verbatim: Ruiqi Gong and Xiu Jianfeng got their [Randomized slab caches for kmalloc()](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c6152940584290668b35fa0800026f6a1ae05fe) patch series merged upstream, and I've and enough discussions about it to warrant summarising them into a small blogpost. The main idea is to have multiple slab caches, and pick one at random based on the address of code calling `kmalloc()` and a per-boot seed, to make heap-spraying harder. It's a great idea, but comes with some shortcomings for now: - Objects being allocated via wrappers around `kmalloc()`, like `sock_kmalloc`, `f2fs_kmalloc`, `aligned_kmalloc`, … will end up in the same slab cache. - The slabs needs to be pinned, otherwise an attacker could [feng-shui](https://en.wikipedia.org/wiki/Heap_feng_shui) their way into having the whole slab free'ed, garbage-collected, and have a slab for another type allocated at the same VA. [Jann Horn](https://thejh.net/) and [Matteo Rizzo](https://infosec.exchange/@nspace) have a [nice set of patches](https://github.com/torvalds/linux/compare/master...thejh:linux:slub-virtual-upstream), discussed a bit in [this Project Zero blogpost](https://googleprojectzero.blogspot.com/2021/10/how-simple-linux-kernel-memory.html), for a feature called [`SLAB_VIRTUAL`]( https://github.com/torvalds/linux/commit/f3afd3a2152353be355b90f5fd4367adbf6a955e), implementing precisely this. - There are 16 slabs by default, so one chance out of 16 to end up in the same slab cache as the target. - There are no guard pages between caches, so inter-caches overflows are possible. - As pointed by [andreyknvl](https://twitter.com/andreyknvl/status/1700267669336080678) and [minipli](https://infosec.exchange/@minipli/111045336853055793), the fewer allocations hitting a given cache means less noise, so it might even help with some heap feng-shui. - minipli also pointed that "randomized caches still freely mix kernel allocations with user controlled ones (`xattr`, `keyctl`, `msg_msg`, …). So even though merging is disabled for these caches, i.e. no direct overlap with `cred_jar` etc., other object types can still be targeted (`struct pipe_buffer`, BPF maps, its verifier state objects,…). It’s just a matter of probing which allocation index the targeted object falls into.", but I considered this out of scope, since it's much more involved; albeit something like [`CONFIG_KMALLOC_SPLIT_VARSIZE`](https://github.com/thejh/linux/blob/slub-virtual/MITIGATION_README) wouldn't significantly increase complexity. Also, while code addresses as a source of entropy has historically be a great way to provide [KASLR](https://lwn.net/Articles/569635/) bypasses, `hash_64(caller ^ random_kmalloc_seed, ilog2(RANDOM_KMALLOC_CACHES_NR + 1))` shouldn't trivially leak offsets. The segregation technique is a bit like a weaker version of grsecurity's [AUTOSLAB](https://grsecurity.net/how_autoslab_changes_the_memory_unsafety_game), or a weaker kernel-land version of [PartitionAlloc](https://chromium.googlesource.com/chromium/src/+/master/base/allocator/partition_allocator/PartitionAlloc.md), but to be fair, making use-after-free exploitation harder, and significantly harder once pinning lands, with only ~150 lines of code and negligible performance impact is amazing and should be praised. Moreover, I wouldn't be surprised if this was backported in [Google's KernelCTF](https://google.github.io/security-research/kernelctf/rules.html) soon, so we should see if my analysis is correct. 1. https://dustri.org/b/some-notes-on-randomized-slab-caches-for-kmalloc.html 2. https://infosec.exchange/@vbabka@social.kernel.org/111046740392510260 -- Julien (jvoisin) Voisin GPG: 04D041E8171901CC dustri.org