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 2EB6AEB64DD for ; Thu, 29 Jun 2023 19:56:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4AB958D0002; Thu, 29 Jun 2023 15:56:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 45C078D0001; Thu, 29 Jun 2023 15:56:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2FCC68D0002; Thu, 29 Jun 2023 15:56:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 1D0C88D0001 for ; Thu, 29 Jun 2023 15:56:07 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id ABA771A0BE8 for ; Thu, 29 Jun 2023 19:56:06 +0000 (UTC) X-FDA: 80956841532.20.1997B5A Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) by imf29.hostedemail.com (Postfix) with ESMTP id AA8D912000C for ; Thu, 29 Jun 2023 19:56:03 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="COCl/U/c"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf29.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.175 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688068563; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=79zP5YHFLGBu1+jfogz5W0vV+Z/KFoVgf5MKidFMDlI=; b=ktkJ4vEnqifmEoHqtwdnSDnvYkp3gaTpcFdMKWsBhwI3rwxcXSjPgB/Dw/yRsyD+Lqg/iE vx4TttBL18C6B7WpZCSjIAbWldTM82eLnD+tj43y/6EutMVS+OwCTeq24x1dCqd+iFa+2h Idv0FNoEfWRmJ6y77j28N4CAcvmwp1k= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="COCl/U/c"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf29.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.175 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688068563; a=rsa-sha256; cv=none; b=5SuoT4zhYBnSxiwu2USFxnYzBtk/w2I1y6fF7PlwcBlhRT4OByb1EabK6gkD2sO80r0avi 8lCwHTeKPvqJJg1VzZ+iCeebWket1wiK26e/AwWI8NBQmNwTmq66ypxVNjv4O5Dp8REh0g ixc40JB9CKMTNcRqRrGAQeAAlbDuR7M= Received: by mail-pf1-f175.google.com with SMTP id d2e1a72fcca58-666ecb21f86so1009357b3a.3 for ; Thu, 29 Jun 2023 12:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1688068562; x=1690660562; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=79zP5YHFLGBu1+jfogz5W0vV+Z/KFoVgf5MKidFMDlI=; b=COCl/U/c9SsKrj00+ygesw3WObTx3Osmqaz88cXeEi0v16GehgR4AlXwfn6v4ktv5I C10xGRe6FXsRNz9GEZSDN0VUenIdW6qee5G9xjkEUo9iK7AYDUHEUJP+LhlE4uP5GoTc yWmHeuNNBPf3DUPsveyOZm//CrDB/mUonJ6zE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688068562; x=1690660562; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=79zP5YHFLGBu1+jfogz5W0vV+Z/KFoVgf5MKidFMDlI=; b=eS1aKiOcM7q4niyWho3ZW33aDJU/RKfntR+KnCM24s+bspvPAttIgY1vTtHytvPwt/ H1aBN8zl+gk7owiwCm5qh/lRPNmL3Adx2esQe0TuRelTS+e1RMbDZE9qbhqysXlGNQrV F3t6twsfdkoRnPpXRoa1sKvbu/kziRwl0UfEt8rt7HeH+qTZlBWjbLCdIAOJTKQFo30F GTSesVHyzVAkVEAalCrYObhnLyceD4KtDYxUf8eS/GSFUdtbPT1xIZcmMmdTXX5T/sya m/02pQfXBcPzDhPMwM/fqyLxl5JvOEUno8LI03NgBW8YHnTz72B9lUYqbPjxxg3+OMLu JGBw== X-Gm-Message-State: ABy/qLZwGe9PCdY10ddag8kzTJYLiG3UkpP3doHBu8YWL7JDz6mTgLHH 9l5IjbMUpLtCwIsJoX23KF7b3A== X-Google-Smtp-Source: APBJJlEbzji2f8hgYz10MuxdvDgsWischUCXYiFpjLORWOWrkG+Dgz+uKmmLCE30mTNIIFno7FxPWQ== X-Received: by 2002:a05:6a00:2d1d:b0:680:98c:c595 with SMTP id fa29-20020a056a002d1d00b00680098cc595mr1171263pfb.13.1688068562212; Thu, 29 Jun 2023 12:56:02 -0700 (PDT) Received: from www.outflux.net (198-0-35-241-static.hfc.comcastbusiness.net. [198.0.35.241]) by smtp.gmail.com with ESMTPSA id h18-20020a62b412000000b0067c9ff80b64sm4590241pfn.113.2023.06.29.12.56.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Jun 2023 12:56:01 -0700 (PDT) Date: Thu, 29 Jun 2023 12:56:00 -0700 From: Kees Cook To: "GONG, Ruiqi" Cc: Vlastimil Babka , Andrew Morton , Joonsoo Kim , David Rientjes , Pekka Enberg , Christoph Lameter , Tejun Heo , Dennis Zhou , Alexander Potapenko , Marco Elver , Jann Horn , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Dmitry Vyukov , Alexander Lobakin , Pedro Falcato , Paul Moore , James Morris , "Serge E . Hallyn" , Markus Elfring , Wang Weiyang , Xiu Jianfeng , linux-mm@kvack.org, linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org, gongruiqi1@huawei.com Subject: Re: [PATCH v4] Randomized slab caches for kmalloc() Message-ID: <202306291252.F916884987@keescook> References: <20230626031835.2279738-1-gongruiqi@huaweicloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230626031835.2279738-1-gongruiqi@huaweicloud.com> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: AA8D912000C X-Stat-Signature: rh6uhtom55bhn115bjw8xrxqj1o5obsf X-Rspam-User: X-HE-Tag: 1688068563-849127 X-HE-Meta: U2FsdGVkX1+LoeY04pY+xcFtNt851YNfdw1y8n8xNh/dn6rhzIq8NASUTJCFiTqxVOYXtZLVOYRo71IUXElM+2Pa7qdRPnK96VY1GV7B8hlE0sdkEU7xCRMyK6vqm5MPbumi9XlwFwDCrvSh10xyOApgHhjYjmMeV7CqhurBEX87Nvp16Ptq+9aRos8jJph6LE0CXx/vClX2PrluctbbL35qUgGr2aVvTs2HLUqdXlIvltP5qihQMxXleCKXJd4WEqOO/xnzKKQsFeRc8sKCFmSO+dYGHHuzrz+8WdJYvZr2/5UYISbpSK9AJaPlRDZ9igs0v8rKlDFxOBcg/9rcIg7+7tmaSxwN1rN5ECNxzY60GCqv22JCIgZEiVpItbHCf0W3NWk8Pc5ZVwN9XG99UuSorcHrpVS9VYmTng1E9PUZYpdfgLsbAme22SnbBUZFVe+nONbwCSTJL4MNi8juVWdx+qayA9TYyuA+YbolzKQY84KEPJYaXs39XxWCQZuqQ1iHJJLVZ2kZUer5rVRZ/J6OPpDyqImMDcPavrJtj3MTeiEfgfKCIk92TCQN+zuI4F+yvjwNEFFfG6kNQ92sKSfQqlnFuNhU/1pkMEmLIVdwTqurewyA+bTqDr3rACTMAGQ1MdetAuRErlj3Qz22oTlTvRP3MMPTx2d1Sj1biVoiz9rYby2kKopZT/E4VkLxvV/FZrEp65fmKiZRwAx+HhBFT47oS6QJitcPK2moswr4gGxcM6S9W65DfCIfAPPPE7Ag8krgnP9S/TJLdsiXs+s0e43o3BKjSlatJtQpHVXWp1QzmkFhSllJgWUv5AOUluSEp15CsJlTpV48NOXYA7Jj/mEKmw6ScDNnNitYl8U4qIoYM1e/MNE6fuWMBY8mhzNunXkvVhG4F6b98cGRHc1Jy6z/5I8tUdYzZnR/n0B5YMYpmMTOXd9Vw6xII0Gjb9eUTlJowBBIZ94FVjH OrlYMnrY me7a2OFz2Ybe11nFZHPVOQ1ePzzIeoeH+P2AKyRSZ+JO3lLB7aCVAUVD9FwmaVCPUin7pDGTtOapWLzgIELUv5IhMgmSVrT/yBwjfAGEmDA80y9ibpmouBTxxeq+IzLkg7UVMuWFwDgUAf3eu3Rtnxq3dFY5dDaQrEUIveAA4C2VVToyQ6UQhle46fTOWAlG3cNr9d/vcVMhl9TeM3B3NjrlQNI5uk5bpnq4Tu4avPruZhHAyhw2AaOzFMklX7s3gVhdzuPsR5hUeqyJivIx9fWYF6V8aYzfVHLsCdlbczkIQWT4Se5W1pNZVNdhuyt3kaVy+ffJIoG+gZkr+dR0E7/QTYXBbgKC0yaDJ1g7f6KKpXUhb8/AQf94YyqXG1S9ctjnrObKiGzq32smBOw057iUQPqYnUgij8XYsfkJNAUf0tTcMPWKiTJG2tjMvihiD4N1r0Y/qLiN2gxy1kW2QWD+QpFNuo1PpQ6F4oQiU7wwcE25IMbAUcUexAOD70lkdMop08YiJtMpjuLor61/0N4uagoyUxxaxetVost5uo76ODR0ekBIVxBIs3RDjarC7MC4PoCePAg2VIrv1kdeAKwvbq36fBYlJQ4m63npf4bWz8MU= 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 Mon, Jun 26, 2023 at 11:18:35AM +0800, 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 address 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 other words, the randomness of cache selection will > be with respect to the code address rather than time, i.e. allocations > in different code paths would most likely pick different caches, > although kmalloc() at each place would use the same cache copy whenever > it is executed. 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. > > Meanwhile, the static random selection is further enhanced with a > per-boot random seed, which prevents the attacker from finding a usable > kmalloc that happens to pick the same cache with the vulnerable > subsystem/module by analyzing the open source code. In other words, with > the per-boot seed, the random selection is static during each time the > system starts and runs, but not across different system startups. > > The overhead of performance has been tested on a 40-core x86 server by > comparing the results of `perf bench all` between the kernels with and > without this patch based on the latest linux-next kernel, which shows > minor difference. A subset of benchmarks are listed below: > > sched/ sched/ syscall/ mem/ mem/ > messaging pipe basic memcpy memset > (sec) (sec) (sec) (GB/sec) (GB/sec) > > control1 0.019 5.459 0.733 15.258789 51.398026 > control2 0.019 5.439 0.730 16.009221 48.828125 > control3 0.019 5.282 0.735 16.009221 48.828125 > control_avg 0.019 5.393 0.733 15.759077 49.684759 > > experiment1 0.019 5.374 0.741 15.500992 46.502976 > experiment2 0.019 5.440 0.746 16.276042 51.398026 > experiment3 0.019 5.242 0.752 15.258789 51.398026 > experiment_avg 0.019 5.352 0.746 15.678608 49.766343 > > The overhead of memory usage was measured by executing `free` after boot > on a QEMU VM with 1GB total memory, and as expected, it's positively > correlated with # of cache copies: > > control 4 copies 8 copies 16 copies > > total 969.8M 968.2M 968.2M 968.2M > used 20.0M 21.9M 24.1M 26.7M > free 936.9M 933.6M 931.4M 928.6M > available 932.2M 928.8M 926.6M 923.9M > > Co-developed-by: Xiu Jianfeng > Signed-off-by: Xiu Jianfeng > Signed-off-by: GONG, Ruiqi > Reviewed-by: Kees Cook Thanks for the v4; this looks good. :) -- Kees Cook