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 BD0AACE79AB for ; Tue, 19 Sep 2023 15:48:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 31A1B6B0071; Tue, 19 Sep 2023 11:48:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2CA386B0072; Tue, 19 Sep 2023 11:48:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B8A06B0074; Tue, 19 Sep 2023 11:48:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 0C2C96B0071 for ; Tue, 19 Sep 2023 11:48:59 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id DA0B3A05F7 for ; Tue, 19 Sep 2023 15:48:58 +0000 (UTC) X-FDA: 81253780356.10.C9AA6AB Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by imf29.hostedemail.com (Postfix) with ESMTP id 35BD4120028 for ; Tue, 19 Sep 2023 15:48:56 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=HPr5p0+s; spf=pass (imf29.hostedemail.com: domain of matteorizzo@google.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=matteorizzo@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695138537; 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=FUFBX34Vi8T0jyulMhlIaJzOiGzxRBHm/K7XuTUIix8=; b=B3qO2zW1RwEkJL9upT1CQA4FVK/R2YurvKr4quDFIJw/49IpDtzwdqwkHH8ToZAisTPfS2 a2BAv92afKFTmCWOjpu+/l/Z568P6DqLPdpGKXD+KCyUmQf+/HXuQKiWNwVJg59QNT239C gWVrEJ7Qeqye/PeHeayLB+oY6AKkPx8= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=HPr5p0+s; spf=pass (imf29.hostedemail.com: domain of matteorizzo@google.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=matteorizzo@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695138537; a=rsa-sha256; cv=none; b=WPfbE3nSuZRD9XPXY/x64rxA3hPli1UKBZ/D+gbPe+GIM4iD9/44X+PxijDNzMvVQwWav3 qG5rnJfXH8ewgpyOoHLFkgFxMiuEyC3lvqWX+K7jHkzfFbZa17hj6tJUvrIWix+fw92+Dt h4DKfRDp1tnMliQqmv8VotcGmZJeRxc= Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-4124e1909edso34064601cf.1 for ; Tue, 19 Sep 2023 08:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695138536; x=1695743336; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FUFBX34Vi8T0jyulMhlIaJzOiGzxRBHm/K7XuTUIix8=; b=HPr5p0+slQi/q/GTM3AUdsAxm8G5GAlgnwFPzDrkub4COW9ymYsbV1vDdrQMuOIQgZ icrvu+ziq/CmmP+jTHrVZq37Z/CN0TqGOn0/QN4homn2MRp1U9O7+TTsJ5aLHFD3DFBL 0rPvBmKdUrlqaDYY/YpaAqrmgOPYzWO1oudXAmPEeDicpbOxQ8+5Iz1eFyO4tsxb5VZC 76++fsSZhiXvghl0POWFNKTwYmreP0cSVqnEtwzs91XvTba+XcUshwJ2YuI1RHPzVrkf S7SLroy826KXRpWUCwFMfuwCmklDF0xRiL2kccp+WhDE1j4oWJgpH8iHNfcUe2SyxX2i fkBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695138536; x=1695743336; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FUFBX34Vi8T0jyulMhlIaJzOiGzxRBHm/K7XuTUIix8=; b=jbYjRHxm0LYoLADRioB2LU1BUA6BYhS49QNo9gSAQCLA21Wx7DYNSTjDCWv6BsK1eg JNxIgDzlP8DFC6IuacSY+9nSoQIo/fBXp3G/VSvopcd78dqQdL5uh2rf+Ll2dsHiuGrT AHz5TD4zMtfSi3pl7M1rWSDH9Dy1qS5GnlNNoOM2tiCVefJ5mb4k/iO7JfXXsGvWivtx s41KpeQQXVYF4zkIdzMpdLO4nsysGHQWJ3H1SeLuMX9AxHuWt3Bk2rZm2xTLE/4+G+cA sBG+Ag11QsfwJr6PmDi8zCjWOQVUrV02txcv9RNz4cPXqHYoKkFYTicce394/cIbpXgJ 4JYA== X-Gm-Message-State: AOJu0YyxxfkvBrLpyucRrp+6r/0NBKZ5uBSfJpAJMkp2ryEkgbgyTOeT bCcG3efkRaAZvJ6yYRzxkZvhNb/jQfxzYgQpb+0PAA== X-Google-Smtp-Source: AGHT+IE3bOOMkBS+atNtSPIXMOTa2Ld22Qs9HTCkKcTaipggWake8IjLOlnyddu6BbylehDROBRn01dZ36CiD5ewpnY= X-Received: by 2002:a05:6214:5d0e:b0:658:2d42:75e4 with SMTP id me14-20020a0562145d0e00b006582d4275e4mr4698272qvb.47.1695138535174; Tue, 19 Sep 2023 08:48:55 -0700 (PDT) MIME-Version: 1.0 References: <20230915105933.495735-1-matteorizzo@google.com> <7a4f5128-28fd-3c5f-34c2-1c34f4448174@intel.com> <1d7573c0-ebbc-6ed2-f152-1045eb0542f9@os.amperecomputing.com> In-Reply-To: From: Matteo Rizzo Date: Tue, 19 Sep 2023 17:48:42 +0200 Message-ID: Subject: Re: [RFC PATCH 00/14] Prevent cross-cache attacks in the SLUB allocator To: Linus Torvalds Cc: Ingo Molnar , "Lameter, Christopher" , Dave Hansen , penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, vbabka@suse.cz, roman.gushchin@linux.dev, 42.hyeyoo@gmail.com, keescook@chromium.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, corbet@lwn.net, luto@kernel.org, peterz@infradead.org, jannh@google.com, evn@google.com, poprdi@google.com, jordyzomer@google.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 35BD4120028 X-Rspam-User: X-Stat-Signature: uqm6saozioka8sjddu5776ofz8mncxfh X-Rspamd-Server: rspam01 X-HE-Tag: 1695138536-46310 X-HE-Meta: U2FsdGVkX18ciKaM1gYxsRRGtmBMfHkTk2xDsBdqmjmPeH89tQfe23Rc2rSRSC2isz69hU8J6bopEp/BTdZoj969Nr4uFVhW6+h+7Sc+nvNDDl0tYy/BW3ANQ0v92cWZdGGdtnjJnTgzSIxXYRN434zvIrL6QFTiFHxfszZtB+oZLilGMDuDSRh6O4b9aO9nKOCFxcHaZsWAl3LFWDfmJmnBO/n/TqFPOtmhaYAoZLjp0gD2Rk67oxY7IEmuOVzSuAtENt+CQjvL4ricmRKR5exQstoLXamOIzX5G+pbhj4aXMpWxA7j2psp6+J9KOf8n7ratbQa4i6hiEzu4iz2UfhBojtslmGbbDOoh/HsoC7BYtiL6tfoGCy7bhtFw6JEwBELuvE2TcGJolTW01DMvWMLPb8v57L1jdWTqeglBOq1JR+haBCAG22wDo1hQy9fRZ6xJf3AGA1ysSObIrITFapWLOxuqvHr/lZxsQ/iDVFXhfRbzKTOcmw3e0BXTCKeM23aGh7RpVi2834GObURPZSTWX33SgXCr3Fq8qzzv8FWtpZ8t36cvThIQwSkr1QJ7YvHTIReIoRyFGWTPp/XUK3s7Ytf1qCbaDAp4RmroCyl6/DHmSSBEoPEwhN6pJMbhrPKNGocVY1cEv+Yd6xXfEGaxmAftB209gI2hS+gnZ+Nx+2Cu2tnX5BdOfmnaxOIvco8CfhG57AOf4ziD2YoU7eOnneMpFfEhFUtpYaQw6H6dkeUCfU5btrAxZqqvHTwRQQh9DvFyFP+hGxm4Cne9/V0OD0RCxWNgDQAPFu+fZi37NCmooAbtKZFkDR3ljKdzQz9nTFbW7ganAnLMAm8sTysZM9AF87WrJ1oR8/gvJjm7F/GLFpDa/KCeJTWpaacxQpMlsi9mpP9dLDfUAN/+FNiNMDgJYD6G+SmIYet5AKDh7tZ/tv8hfRu+Z8haU26fhXywdfg1MMdY4FfX8X QMwntUWI cN5OkL0g4DYKu74/XpKfiZdzmftbRxYKiVNu57TLUZ6jWEhieOuh/XJ8ZejKhdredWOdtya75UcNzJ5WaCfyNW6Hx1dBBRZinj9akAnRZ29rZ3LurMHiFtvdSpMBnH6LpxHGqoeFtXZPbd0qI1HY1l8ACy36yGsjQVGv7cjAiHnZHecbWDa1TA4PDR++3MmhHDh+irHw1A5aI/xnQviDdIXhSJ6rU/znfHsjkDY0BerzPF2lW6Zzg8Ga/IDZVNTyj1xqelTeONs2Lkud3WmhdNLuQyieYtVl2KEdfI6yO1moHrHu1u81GmUcFn5bZMtAgtGm7V0S/NBXVgw3sIJDTRVB9+2ITfyo3qO2GyjI0VBmZilFUp8QEuiNfeK3ID+jnHiQ4lXl2JhnJBf9T2PPltofxP6LzrsdbVb4oukuDnIQcuozIVkDBLiJpdg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, 18 Sept 2023 at 20:05, Linus Torvalds wrote: > > ... and equally importantly, what about DMA? I'm not exactly sure what you mean by this, I don't think this should affect the performance of DMA. > Or what about the fixed-size slabs (aka kmalloc?) What's the point of > "never re-use the same address for a different slab", when the *same* > slab will contain different kinds of allocations anyway? There are a number of patches out there (for example the random_kmalloc series which recently got merged into v6.6) which attempt to segregate kmalloc'd objects into different caches to make exploitation harder. Another thing that we would like to have in the future is to segregate objects by type (like XNU's kalloc_type https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/) which makes exploiting use-after-free by type confusion much harder or impossible. All of these mitigations can be bypassed very easily if the attacker can mount a cross-cache attack, which is what this series attempts to prevent. This is not only theoretical, we've seen attackers use this all the time in kCTF/kernelCTF submissions (for example https://ruia-ruia.github.io/2022/08/05/CVE-2022-29582-io-uring/). > I think the whole "make it one single compile-time option" model is > completely and fundamentally broken. Wouldn't making this toggleable at boot time or runtime make performance even worse? -- Matteo