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 8DFF2C54E64 for ; Mon, 25 Mar 2024 20:26:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 03FA26B0087; Mon, 25 Mar 2024 16:26:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F320A6B0088; Mon, 25 Mar 2024 16:26:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DD5066B008A; Mon, 25 Mar 2024 16:26:39 -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 CF6416B0087 for ; Mon, 25 Mar 2024 16:26:39 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4B12EC02F3 for ; Mon, 25 Mar 2024 20:26:39 +0000 (UTC) X-FDA: 81936694518.03.B2B2460 Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) by imf20.hostedemail.com (Postfix) with ESMTP id 78CB01C0016 for ; Mon, 25 Mar 2024 20:26:37 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=dfhQ7EO5; spf=pass (imf20.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.44 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711398397; 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=XQgVc5rA568fhlJ0cVI5voz5lHmOfZopdFI9MupJvHk=; b=QwfmnGbHc9KeioqMJQmpdP8fONNkiz1224uBof7s/PGI+Fg9NRQr5qjz5MF1ug295ubssN R7Vk3ABU60cZz5wJiL3htjvlp7YWlYpYtRcki/YeRiHI2KPL2clq4tapRHYnGhhh1431Wm KJqBvmweaMDy8ajCVYomjiC6Hks2bTo= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=dfhQ7EO5; spf=pass (imf20.hostedemail.com: domain of keescook@chromium.org designates 209.85.210.44 as permitted sender) smtp.mailfrom=keescook@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711398397; a=rsa-sha256; cv=none; b=DAf3inXtUKt65padNzsBkSJB9YpmD1R4QkCf5OmG/CSfqZwLuE7phIVITYmBWAAqpD6PMd YQZBcI1GzzXu+dVbZEH6rwMAzvHz22yQws820RACeHqca/cH5IsqTdqUPIOb8hey0Srcgk zWMDKclijYJvFrI3qb820NB2ODp9qq0= Received: by mail-ot1-f44.google.com with SMTP id 46e09a7af769-6ddf26eba3cso3282880a34.0 for ; Mon, 25 Mar 2024 13:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1711398396; x=1712003196; darn=kvack.org; 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=XQgVc5rA568fhlJ0cVI5voz5lHmOfZopdFI9MupJvHk=; b=dfhQ7EO5mR6ldJp/HT26kqEw4yPzaV02Qk5L7T74CJWL2VH0U2CFWRuVCp6rzxV+MN FdVxDAp3bWzszoBZnds2zUaZ2QNd65AKsZzgS5M4MxNLucuwvGCXvhWjBafwxk3CsvXV KX9PNoiuCyzILM5KGL9CuDWlcdN7pfsNkQ/yU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711398396; x=1712003196; 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=XQgVc5rA568fhlJ0cVI5voz5lHmOfZopdFI9MupJvHk=; b=BYyJY20LhLuR8KeWG3JzgalbqbF49DLn9OfaSk3vD/RRQyYC0oopNyUHaHpueUC0QJ GrLaA/bX8/wWkew0Gu6gnfPdFrMCkP9xfCqUn9C2mxIaweEceyJtooViYxGxFddN2sD3 uBEmB4n3zDBchKhGo/ICkPi9MCYBVCQfwGMe/cfwNkR3urxQsJTGG1CvYnErKaTrp7HE 9/S0jnPj6jJ0taVd/+3WVQYwdJb/LxgOPeJ+hMlOS5fNLeEevSibSwdIaL/gyCOsEKT/ uKGv7vcH2fpERPwmqov+7mQPIpeXNG/ArFOAyK2TuE3vx0eFvWkhc9UcRgWouRwjuicJ R3hg== X-Forwarded-Encrypted: i=1; AJvYcCWRK33Pwi8XIPjhw4xc2Y/kXhrKXNS0S42siXya2su67IRw7PBNDDFNvgAINkMYMVHv6RuRrK60xRsXLzfJPgqsJDk= X-Gm-Message-State: AOJu0Yxb73UT4h3Oe4IdCiE4Z9yXpIYN/B3tA3h/EmhQpJ5unBr/4s+G aZR+V5IEhCb3I8FPIs64l2wrm4DT9CwzlFUOi5Ea56HuR+GxdxDFvu7B9Snopw== X-Google-Smtp-Source: AGHT+IGDLy633FPE8AGgVDT1L28BA0GlpvQ5JB0Sst0Ad42s4bKNBdcs/aHPwJ6kk2CRqJ3AwFCzew== X-Received: by 2002:a05:6870:1652:b0:22a:4f78:5be6 with SMTP id c18-20020a056870165200b0022a4f785be6mr2334889oae.17.1711398395563; Mon, 25 Mar 2024 13:26:35 -0700 (PDT) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id s66-20020a632c45000000b005d6b5934deesm6218001pgs.48.2024.03.25.13.26.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Mar 2024 13:26:35 -0700 (PDT) Date: Mon, 25 Mar 2024 13:26:34 -0700 From: Kees Cook To: Kent Overstreet Cc: Vlastimil Babka , Andrew Morton , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, "GONG, Ruiqi" , Xiu Jianfeng , Suren Baghdasaryan , Jann Horn , Matteo Rizzo , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org, jvoisin Subject: Re: [PATCH v2 0/9] slab: Introduce dedicated bucket allocator Message-ID: <202403251324.F8EADD2E@keescook> References: <20240305100933.it.923-kees@kernel.org> <5e1571de-2c5a-4be4-93f4-01582094ee96@suse.cz> <24vn56fs7oohqgw3rhssiwglmviruqnt44y6oeajzvskostcrr@7jzhmxjbhcha> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24vn56fs7oohqgw3rhssiwglmviruqnt44y6oeajzvskostcrr@7jzhmxjbhcha> X-Rspamd-Queue-Id: 78CB01C0016 X-Rspam-User: X-Stat-Signature: 7tey66ujtt17m6fwjfxdsxofnzs6nxc6 X-Rspamd-Server: rspam01 X-HE-Tag: 1711398397-689130 X-HE-Meta: U2FsdGVkX1/KbQurgM8ZINrBsP1qp6k84MpYYX9txRRwUdTo1PePRScbLS3wSKfbfx4KzUfXHadaivZmVudOBFN6xw3u3skb+P+a53dnAcT5wzqIcPKyL0SIZ1MLdOEnfXe06CujXm1xZzhbTXMJF4wCwc9ErMJs5P1+in4kHL+ImYErDI0RPyz/6RTQKVPJNGGDbmxbsel297OUKblw+D5HV2Z/TbM1SbTSNDiRT4tWsBUGV4egLLKjraB7K4Km49o4d/b7FyA7YXKeRXoMcTE2dc54QwrRRofrq9JIPEIjI8JgAuqgpJjqDXgRZEn9xDSpgofZgwo/RViOccozRJvB0p1NFg5+p8uflGD4KHApfKHZ77AUdht/L5PR2Y0j6IzLU59U2zXf0d6UM6oB8u6l7XG0wxRcG0FXGQ4q7rNQII8E7vmsgdIlYfGFnYpKqTmiYySagOucHvJy1ltqbF9imUD6wfUmMxZ2OS+Gd8Yxg9o4KM47gJGyg6KANL2aOLOCAXeA4ZWjsATVCKXdOLVHZ1qWuU8nCm45WGsNCpNdRe/SyP/t8Eut6jiWs3DNTnS+F1y7kuoy9bzyVf2oDKYolLV2Io+YRvyTTultZdlqXetljzMHNVJYWeUPFJV1UsvX04OOA0JELv2C3Y2b1qz1bAt2NY7uB3cs7KhKtViY4ZebY2PcVg7HLLIJYhnWtwmWXIW+kcuVoZ4G2qlnRzaK9qf6wZIcWGBPmS7YnDVpHeQt942vJv06Yy2wVyak6ia8P7RskvICgGYh15nPLtHngVl3dqjKLzQAvYFXo5y9uWs9sK7v730e+JERQste5wEf8wI4L2YqjL3dq1yrX6Jlc9j1UdfFCWEgo7lXQpI77PaBlRQYH9ockbZ+zjRd5PHc6PZBlHjdP1Dmk6irpUiRDsb5PB9xGw4m38FVZIxzvkOll4Md/mNEgfDVS+ul6rxHTWqApIclJT04gSR +GUexoRq kQizjGDMs3EV1N0sBjds0xvfSkbX53+BynkN5t8tjux36f4JCA1MZJZakNLoHz6ozk9Fsk0Hu0xRFLDyMSPnX/+9MNq4zjhMkPhKI9d43r8fitDDpL7eLZtZEv11ent5X9wA4Yhu8nth3Yprn0f4/P8/MLqs7JYkdy8RxHtAHxO0wh85p9WO/UIUGvMbmkekoc0ZrjrbrJbAwAdnsthM2rGk0xHaaoZXLd0x3f7daNEgLGHErsaexWwQqJoL3P7XTUZweKikI9TM6aOIAcp7zrXrPKYULDQ3z9xZkjKBow4jwepw3/7gsL+/gbH0M+6GvqjOu7V6XbERQh9RocKDD3Q994khxJKW9rviLQMFiJiXQ91uZQlqWNxfAJ+vjozhVkWCc2AdnXNGCXjc4LgxqDjYiaxoGizses/9v9ez1a4DJawjzP7TVWtmEco/sJEgRH/LUNe5P9iCg+UXDmcgMagRJHdd/med8QevFC/UPzCFRwEaFiIih8YdRjc1EBkugxyade5HrSpH1elHybHSaMvd6KF+tsKUHAyi70HRXWmhqGXZuGXH5uih+PCChqTgDVMkvsT9sPIY/Qv0fHJ95Gah7vUOZaUUhJy664P4z6YkG+WL40NgGchNle7H/4XiccMItqjB9rMiExq6+HAqRqcD79o2oQFiOgcXCVLoxaO2csZBSimN00qFAyCXD7D3h1JovmbAuY9Pf0XrxgVt4KQnEmE4JHvFN4Fl3ntxO+fhBQpvE6edT3LuAHW5qjk1f6x/vD+8bRso6SpDeZIyTVdVSIhOAP5xg5RSKibbhhl386pNb4KNwJq0T2QQ0sBav/UdokrD3RqlBjAqUhZ1+59IeZSfrR1aA9qXBqmSWqjViBFHHm+hKVV0oovbcktOn/zlBufvDjMohJJjLjRk50cgajHmDfJsLGnXgo3C37B7yZfZTkB+Ykwpe99mYqj97VEPl3ZMePzbpSM2qPI0Z8QN9YU2L vl5c6dIt ZZicavS3ShF2Dyk31xMzcyTKVsWbtkwg 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: List-Subscribe: List-Unsubscribe: On Mon, Mar 25, 2024 at 03:32:12PM -0400, Kent Overstreet wrote: > On Mon, Mar 25, 2024 at 10:03:23AM +0100, Vlastimil Babka wrote: > > On 3/5/24 11:10 AM, Kees Cook wrote: > > > Hi, > > > > > > Repeating the commit logs for patch 4 here: > > > > > > Dedicated caches are available For fixed size allocations via > > > kmem_cache_alloc(), but for dynamically sized allocations there is only > > > the global kmalloc API's set of buckets available. This means it isn't > > > possible to separate specific sets of dynamically sized allocations into > > > a separate collection of caches. > > > > > > This leads to a use-after-free exploitation weakness in the Linux > > > kernel since many heap memory spraying/grooming attacks depend on using > > > userspace-controllable dynamically sized allocations to collide with > > > fixed size allocations that end up in same cache. > > > > > > While CONFIG_RANDOM_KMALLOC_CACHES provides a probabilistic defense > > > against these kinds of "type confusion" attacks, including for fixed > > > same-size heap objects, we can create a complementary deterministic > > > defense for dynamically sized allocations. > > > > > > In order to isolate user-controllable sized allocations from system > > > allocations, introduce kmem_buckets_create(), which behaves like > > > kmem_cache_create(). (The next patch will introduce kmem_buckets_alloc(), > > > which behaves like kmem_cache_alloc().) > > > > > > Allows for confining allocations to a dedicated set of sized caches > > > (which have the same layout as the kmalloc caches). > > > > > > This can also be used in the future once codetag allocation annotations > > > exist to implement per-caller allocation cache isolation[0] even for > > > dynamic allocations. > > > > > > Link: https://lore.kernel.org/lkml/202402211449.401382D2AF@keescook [0] > > > > > > After the implemetation are 2 example patches of how this could be used > > > for some repeat "offenders" that get used in exploits. There are more to > > > be isolated beyond just these. Repeating the commit log for patch 8 here: > > > > > > The msg subsystem is a common target for exploiting[1][2][3][4][5][6] > > > use-after-free type confusion flaws in the kernel for both read and > > > write primitives. Avoid having a user-controlled size cache share the > > > global kmalloc allocator by using a separate set of kmalloc buckets. > > > > > > Link: https://blog.hacktivesecurity.com/index.php/2022/06/13/linux-kernel-exploit-development-1day-case-study/ [1] > > > Link: https://hardenedvault.net/blog/2022-11-13-msg_msg-recon-mitigation-ved/ [2] > > > Link: https://www.willsroot.io/2021/08/corctf-2021-fire-of-salvation-writeup.html [3] > > > Link: https://a13xp0p0v.github.io/2021/02/09/CVE-2021-26708.html [4] > > > Link: https://google.github.io/security-research/pocs/linux/cve-2021-22555/writeup.html [5] > > > Link: https://zplin.me/papers/ELOISE.pdf [6] > > > > Hi Kees, > > > > after reading [1] I think the points should be addressed, mainly about the > > feasibility of converting users manually. On a related technical note I > > worry what will become of /proc/slabinfo when we convert non-trivial amounts > > of users. > > There shouldn't be any need to convert users to this interface - just > leverage the alloc_hooks() macro. I expect to do both -- using the alloc_hooks() macro to do per-call-site-allocation caches will certainly have a non-trivial amount of memory usage overhead, and not all systems will want it. We can have a boot param to choose between per-site and normal, though normal can include a handful of these manually identified places. -- Kees Cook