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 AA0EAEE6455 for ; Fri, 15 Sep 2023 11:00:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 961558D0012; Fri, 15 Sep 2023 07:00:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8C11A8D0025; Fri, 15 Sep 2023 07:00:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6AF168D0012; Fri, 15 Sep 2023 07:00:17 -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 5068F8D0012 for ; Fri, 15 Sep 2023 07:00:17 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1FAFB160F82 for ; Fri, 15 Sep 2023 11:00:17 +0000 (UTC) X-FDA: 81238537674.15.AC7F46A Received: from mail-yw1-f201.google.com (mail-yw1-f201.google.com [209.85.128.201]) by imf27.hostedemail.com (Postfix) with ESMTP id 0747F40021 for ; Fri, 15 Sep 2023 11:00:14 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=G7n9emll; spf=pass (imf27.hostedemail.com: domain of 3PjkEZQsKCO8dRkkVfiZqqfXffXcV.TfdcZelo-ddbmRTb.fiX@flex--matteorizzo.bounces.google.com designates 209.85.128.201 as permitted sender) smtp.mailfrom=3PjkEZQsKCO8dRkkVfiZqqfXffXcV.TfdcZelo-ddbmRTb.fiX@flex--matteorizzo.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694775615; a=rsa-sha256; cv=none; b=WvwMHkikF4l31pDaU/f6qtXclSsthJgZN2+MDW5ebv/MFjMI0UuFg6kQ56DG8E5CDnDaEN yd4xwY/MSSWvneKJgii0oPQM8tNdwmG+ajMRnLCFkEqJ/ZfdjnE9espjbFFWr9cF/8ORoU cABATcaZvreWmYGmb9AhKDZZXdTzefk= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=G7n9emll; spf=pass (imf27.hostedemail.com: domain of 3PjkEZQsKCO8dRkkVfiZqqfXffXcV.TfdcZelo-ddbmRTb.fiX@flex--matteorizzo.bounces.google.com designates 209.85.128.201 as permitted sender) smtp.mailfrom=3PjkEZQsKCO8dRkkVfiZqqfXffXcV.TfdcZelo-ddbmRTb.fiX@flex--matteorizzo.bounces.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=1694775615; 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=/kdjtZjOl0pG1Y8OuH7SH0XgMhsH4ZDWKrdEtcTG86U=; b=XAxRnNfGzQhir3tcPnYCfyDZuxWl/Yb7UVdLWROarlm9y920mlr+m3sNospWbGfW9vmKcM wPYotLxXJZdHf6uisbjyBZXL1b1C5G0TbFI/w0E3FDpGdqn4caxkKcfNfV11GuxOiazRM7 s5xmGNAOUMntCmaSBA7rJbBT1GiNmBk= Received: by mail-yw1-f201.google.com with SMTP id 00721157ae682-58c8b2d6784so25562677b3.3 for ; Fri, 15 Sep 2023 04:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1694775614; x=1695380414; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=/kdjtZjOl0pG1Y8OuH7SH0XgMhsH4ZDWKrdEtcTG86U=; b=G7n9emllwlup+WuArtI63JVWYZUYMh/4Arz0FU7wpaVVpLh8X4h1yGfXPApQMxo2qR arJfPEfp5wK+yBX6ybWHgV98Fd8+WdKU6JGb468ESTcWRGfBLPS1UqlCCqNFqZDCdZN1 Muz8tAnEQLaQprhIHAeoyJBDbrf8evxWmo//lnCgrP+4Tdb6x1mKeiIKIok7h+vXfJkR xkS8YQKdOINwZSFu7wDXt0dsBcXPaKm89ry2Zf9ZhluH2kQNnxB7k49/wMUgp4RC/eLS TB6CumM19fujhwN83KXpyki+po/U9Pmgg9UdEwXbym7qiAtBezvUknOLQqHmfw6h5sUa fWbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694775614; x=1695380414; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/kdjtZjOl0pG1Y8OuH7SH0XgMhsH4ZDWKrdEtcTG86U=; b=ru5cyUeJPbPiwWoNgdB0OQ/ox4Byy/umX3ETvb0C8o7U06L5eTpTpJCHN3l38kdhyT avLHmb3psLvHLKvEK3Xsl2Jwm29eDNzye4x4d+7Yyy/130qvOshABn32qxKF66eFaVjr zjdOBczr/anT5uSheHO9rDhYMXRwLM+oTXwEzuNOrJFvvxxCiUSYR14aAuSosZcd8Y2L tYMXnuHYlH4yvBNmdj1C+BJJhZEZpSqEpDzZG3BsXQ3uSjgAkceDhfLagj7gURf49Jtv FPO+1ra9h5U7hUE1uQVh5owRmoOw/dUoso1BIuy4p6owgQyxU0KCIt8OFYBuIOFowiYK fnmg== X-Gm-Message-State: AOJu0YwHlEB+40Vzs3vtmZJ6BgEUAJ5Dy94ijcc+uHQ0C7Rs/PRVhc8R 0MyoLDbLqFSO9XzKIGWsb7nJivefoS3l7qYi4g== X-Google-Smtp-Source: AGHT+IH3LIX5OX5bZq/S9d+gFcO+JqbLY4Sep9fDWrOQHGQEzWkq5gu7AdHBA2+dfu8HpxR++S9aMZH+wQ9NGJ4UEA== X-Received: from mr-cloudtop2.c.googlers.com ([fda3:e722:ac3:cc00:31:98fb:c0a8:2a6]) (user=matteorizzo job=sendgmr) by 2002:a81:b643:0:b0:59b:f863:6f60 with SMTP id h3-20020a81b643000000b0059bf8636f60mr37260ywk.4.1694775614195; Fri, 15 Sep 2023 04:00:14 -0700 (PDT) Date: Fri, 15 Sep 2023 10:59:33 +0000 In-Reply-To: <20230915105933.495735-1-matteorizzo@google.com> Mime-Version: 1.0 References: <20230915105933.495735-1-matteorizzo@google.com> X-Mailer: git-send-email 2.42.0.459.ge4e396fd5e-goog Message-ID: <20230915105933.495735-15-matteorizzo@google.com> Subject: [RFC PATCH 14/14] security: add documentation for SLAB_VIRTUAL From: Matteo Rizzo To: cl@linux.com, 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 Cc: jannh@google.com, matteorizzo@google.com, evn@google.com, poprdi@google.com, jordyzomer@google.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 0747F40021 X-Stat-Signature: nk9sbunbaypkjf4mx5sw3j9racuh6t77 X-Rspam-User: X-HE-Tag: 1694775614-470589 X-HE-Meta: U2FsdGVkX1+eRL1sgqMpqniifTnxFTn3SiOr9V3LvjfnKUpIHe6e4E2NV5UfpWlKKzUEgj9rcuQ21s02Cmk3hWvkUX/nghVXFH/9SbtgW1aDcAl1hXrDJhEhg9xeDTCX5iG4naKLUh2/CVt6ds2u36h1qTEOKtPMtVv0ffQQ2uzC+Rl40mp/ljcxoPHxaKs+Qosq6ljPOG2IBw/kHH2PcrRQfvuJxuT5OufEfWCmQ44gmWaTVwIwjXjtWveXoP+0aRvq7eqUpNo65PN26oFq4iPqzNkd1e7fl77sTks9QqGhmUjYlxMBmRNnkUqZItmM5HVT/AMpinBzxLg8Kx3opp8BmT1DcISWMn42+G6DjRFSrpxdkJeKDTjukPLq9QayfAj0QnK+uc7omONl7kUZQyuCxHqSAOlIWcyoFCj9OWzxhugkPgfOWVOSWT7ElTngkG4Z3glNV1d8cLR8NqUlwYLXdtF5RK1xS7zOszYMG4WLi1nsxA4CDes1q4UEd4lLMHGRRro2txUjklgSx6HLbyjYo3itdqUdo6rjf9PikeWug14EoZtkHhTDcWvrxl7I23WQhk9Xwv2XZX2wTiqteOzYMTlBbpBW99yAzReYqSBA6x824hIFTWFN0o9wPVOf326XUeoH+uJbPRhlHVGykxhZAKgC5H8/Y1iy3RbnLwNrbvlZn6bg1tc54OW5yfuE0SqMzTMNi8CIzhRXZQ5cLMdS/LmvbINggVRaKtpckHhatKDN2G9B3Y6eXy5I8amuhRUdd1IBAsTyg88IRpHCvYsV3kC0cUZa4qEEOk5hFL2SZ4uJVn4f42vi1fJQArVKCWSNCpq509ETYTS1qxnzp9EIkatk/6hgNjMAutKY8TFFpKYtJY29Zlln0jwdYKKjoWT89/j+nGsxMd+M9KXHsrJXzka68YRqz8r8EVl9Vw6fT4dmYoeQpHcxAY9KRPSEl0b3jLd4lG6493XywVz foq13h20 FDRn9152YnVQAWwFp6bQ3MSooHVXvgEZ2T3SmSimXmfUdbcX0IXFrxY46JqJ1tDW1icopBaqwkXrvQkbRir0u7lQsJSKYs7zv8f+hP5KSYqdSOiUsSNht3L49ngIKIAxUcfGPjUTsStqL5InEE3MJuhiPRn8rVRmJE4KSGeE5w/N78I+lYxSCYiu0FYfqDJ1cw7WtPSj8EhvmjbbqKmshbOSL5XrE8ZxjDsCNpec4RF0KqWhAbqoUSgOnBZ+6igjtvPV4LXHzPg36DECzMfKxURJ5/He9bWJqmCvC65Goevjd8TILDkoPepgnUjrbJFFPveJ/v+/EMJb6vnKF1zgfB24A2RbrevfV0X9jJwqcUx9X2n6U6Rjq2CzpaZJ5pTA3sirlh1/DJJ/nuknk6eBWG86yJcahhBje+sXGxne1TMXD8feLNHZ1Jkq3nVmuUlDA5tYUEtpg4FkQH/dXbufuu94IIJU6jOaBjMrAbTI0FXfJJ9QV3r1G3Mscds5pXtrOcZQEB7PzBpdm3nVj/o1lGaOuYfRej78EXiL/gQG5w+cTMrbzKeTWqKZ5KgZVid/x079QhDR5cMD6EUTAQ9WZlorY02QVFqMQMUq9ypkOXEWZDaCKyppoUaoKksF+AMWRec6aX2kIWj2C1HGO69J95AO6Ia0RcxKHbh7/Nk5mRwGBfQRgGkRw7Luvf8cbSmKMuXMQgFrktN6g7gRI3D/uvtoBL5sU5togtJpHd6OmjFQ4hI0dW8IlznDxfcXQweCepfm5zM6hvbKY2g8JkjRqFMLzYPitaxqMm4+FK4nc6jiXmYeYVgWbxM4Qvx0lWVbg+tMT 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: From: Jann Horn Document what SLAB_VIRTUAL is trying to do, how it's implemented, and why. Signed-off-by: Jann Horn Co-developed-by: Matteo Rizzo Signed-off-by: Matteo Rizzo --- Documentation/security/self-protection.rst | 102 +++++++++++++++++++++ 1 file changed, 102 insertions(+) diff --git a/Documentation/security/self-protection.rst b/Documentation/security/self-protection.rst index 910668e665cb..5a5e99e3f244 100644 --- a/Documentation/security/self-protection.rst +++ b/Documentation/security/self-protection.rst @@ -314,3 +314,105 @@ To help kill classes of bugs that result in kernel addresses being written to userspace, the destination of writes needs to be tracked. If the buffer is destined for userspace (e.g. seq_file backed ``/proc`` files), it should automatically censor sensitive values. + + +Memory Allocator Mitigations +============================ + +Protection against cross-cache attacks (SLAB_VIRTUAL) +----------------------------------------------------- + +SLAB_VIRTUAL is a mitigation that deterministically prevents cross-cache +attacks. + +Linux Kernel use-after-free vulnerabilities are commonly exploited by turning +them into an object type confusion (having two active pointers of different +types to the same memory location) using one of the following techniques: + +1. Direct object reuse: make the kernel give the victim object back to the slab + allocator, then allocate the object again from the same slab cache as a + different type. This is only possible if the victim object resides in a slab + cache which can contain objects of different types - for example one of the + kmalloc caches. +2. "Cross-cache attack": make the kernel give the victim object back to the slab + allocator, then make the slab allocator give the page containing the object + back to the page allocator, then either allocate the page directly as some + other type of page or make the slab allocator allocate it again for a + different slab cache and allocate an object from there. + +In either case, the important part is that the same virtual address is reused +for two objects of different types. + +The first case can be addressed by separating objects of different types +into different slab caches. If a slab cache only contains objects of the +same type then directly turning an use-after-free into a type confusion is +impossible as long as the slab page that contains the victim object remains +assigned to that slab cache. This type of mitigation is easily bypassable +by cross-cache attacks: if the attacker can make the slab allocator return +the page containing the victim object to the page allocator and then make +it use the same page for a different slab cache, type confusion becomes +possible again. Addressing the first case is therefore only worthwhile if +cross-cache attacks are also addressed. AUTOSLAB uses a combination of +probabilistic mitigations for this. SLAB_VIRTUAL addresses the second case +deterministically by changing the way the slab allocator allocates memory. + +Preventing slab virtual address reuse +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In theory there is an easy fix against cross-cache attacks: modify the slab +allocator so that it never gives memory back to the page allocator. In practice +this would be problematic because physical memory remains permanently assigned +to a slab cache even if it doesn't contain any active objects. A viable +cross-cache mitigation must allow the system to reclaim unused physical memory. +In the current design of the slab allocator there is no way +to keep a region of virtual memory permanently assigned to a slab cache without +also permanently reserving physical memory. That is because the virtual +addresses that the slab allocator uses come from the linear map region, where +there is a 1:1 correspondence between virtual and physical addresses. + +SLAB_VIRTUAL's solution is to create a dedicated virtual memory region that is +only used for slab memory, and to enforce that once a range of virtual addresses +is used for a slab cache, it is never reused for any other caches. Using a +dedicated region of virtual memory lets us reserve ranges of virtual addresses +to prevent cross-cache attacks and at the same time release physical memory back +to the system when it's no longer needed. This is what Chromium's PartitionAlloc +does in userspace +(https://chromium.googlesource.com/chromium/src/+/354da2514b31df2aa14291199a567e10a7671621/base/allocator/partition_allocator/PartitionAlloc.md). + +Implementation +~~~~~~~~~~~~~~ + +SLAB_VIRTUAL reserves a region of virtual memory for the slab allocator. All +pointers returned by the slab allocator point to this region. The region is +statically partitioned in two sub-regions: the metadata region and the data +region. The data region is where the actual objects are allocated from. The +metadata region is an array of struct slab objects, one for each PAGE_SIZE bytes +in the data region. +Without SLAB_VIRTUAL, struct slab is overlaid on top of the struct page/struct +folio that corresponds to the physical memory page backing the slab instead of +using a dedicated memory region. This doesn't work for SLAB_VIRTUAL, which needs +to store metadata for slabs even when no physical memory is allocated to them. +Having an array of struct slab lets us implement virt_to_slab efficiently purely +with arithmetic. In order to support high-order slabs, the struct slabs +corresponding to tail pages contain a pointer to the head slab, which +corresponds to the slab's head page. + +TLB flushing +~~~~~~~~~~~~ + +Before it can release a page of physical memory back to the page allocator, the +slab allocator must flush the TLB entries for that page on all CPUs. This is not +only necessary for the mitigation to work reliably but it's also required for +correctness. Without a TLB flush some CPUs might continue using the old mapping +if the virtual address range is reused for a new slab and cause memory +corruption even in the absence of other bugs. The slab allocator can release +pages in contexts where TLB flushes can't be performed (e.g. in hardware +interrupt handlers). Pages to free are not freed directly, and instead they are +put on a queue and freed from a workqueue context which also flushes the TLB. + +Performance +~~~~~~~~~~~ + +SLAB_VIRTUAL's performance impact depends on the workload. On kernel compilation +(kernbench) the slowdown is about 1-2% depending on the machine type and is +slightly worse on machines with more cores. -- 2.42.0.459.ge4e396fd5e-goog