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 X-Spam-Level: X-Spam-Status: No, score=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D2A8BC433E1 for ; Tue, 18 Aug 2020 15:46:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 91EED22B4E for ; Tue, 18 Aug 2020 15:46:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ee8Rbkby" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 91EED22B4E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 198728D001B; Tue, 18 Aug 2020 11:46:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 148598D000B; Tue, 18 Aug 2020 11:46:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 010078D001B; Tue, 18 Aug 2020 11:46:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0051.hostedemail.com [216.40.44.51]) by kanga.kvack.org (Postfix) with ESMTP id DA2598D000B for ; Tue, 18 Aug 2020 11:46:05 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8AF87362F for ; Tue, 18 Aug 2020 15:46:05 +0000 (UTC) X-FDA: 77164115490.21.form11_3a0f9ad27020 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id 20F17180442C4 for ; Tue, 18 Aug 2020 15:46:05 +0000 (UTC) X-HE-Tag: form11_3a0f9ad27020 X-Filterd-Recvd-Size: 7152 Received: from mail-pf1-f195.google.com (mail-pf1-f195.google.com [209.85.210.195]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Tue, 18 Aug 2020 15:46:04 +0000 (UTC) Received: by mail-pf1-f195.google.com with SMTP id d188so10160535pfd.2 for ; Tue, 18 Aug 2020 08:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LaWl8Zpiv/jFVXO3m0WashM5ldm/W64kfnal4k5ac3s=; b=ee8Rbkby61dQq7lCcZOsAyUQIuSGcYEtLC0PiPpU+eKTVLvPY5Q9nFZK+at9upsFjw xC7psyYAxV3H4XatlFiqQ3lZPTtMKxblP/lm6YmIOuL9f6naLRF1Bz7BOH/y0ffbWaUy Zw8ByQbMF7ZoSYo3HlbbkWRGjV7/tizUURsy25OHGpqGS6LE/jm05t9RL1+Fok4afK60 U2t0dMWD4fD1XkZjx5Y8P16uezJ4REIRf49KSsJtAtUVAmYvkCB5stGCRSOQhkClunrq 3p1pNqEU+Vn+ghlFl/INrW8UOJbd5A/Ulie48CIvmDUtvEkxXiiTeNyImlRzPRbrjBzT jLtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LaWl8Zpiv/jFVXO3m0WashM5ldm/W64kfnal4k5ac3s=; b=l9UMcpKFQr5MWDtY8ur3atDXnfoQvbX8SU+l4Cb431F6RDoxc4G183CowQNQ+JoTRB JC74/WuEO5YFtZ/Fjj6WY64/5e+4rFWVYRvpIDzUVdKOtDxiUh4dl/qHiSl9O2ov6pkH 8NMgc+ChzlobQrhllVlOsRB3HKEfuYo5VRXA32l1ww3hjR2NGNRlG/ul8dseE84lROks 5CSrGxTeAFDtIoUNn0kKmA6+nYetJhF3Z8uoj1TeuXvwtyEDs1n/PM4mSNVRVn5F8sJu SfUvzbj3JnxqIGpbxzvQJ3B+3FM5HO/RnuDppIPkjbMfZWT3qcGnbTMnUin/Eaiqvcbm ux/g== X-Gm-Message-State: AOAM533CgPeIOpX3DtGFSjYm+v/2kxioVxK95HcxbAct3LK8lLNLyChN wnHOzd55xaFbxlQeJyfx0/dH9JozTRa7AObenqea3A== X-Google-Smtp-Source: ABdhPJwvek9/UE22iuTmUPANkh4gr6Kban+1Xge7EcyTlYgnVUC/xb5/ww37hGdor0eyhlS6u0Gg0Evh978FGWvgKVE= X-Received: by 2002:a65:680b:: with SMTP id l11mr7436248pgt.440.1597765563163; Tue, 18 Aug 2020 08:46:03 -0700 (PDT) MIME-Version: 1.0 References: <20200813151922.1093791-1-alex.popov@linux.com> <20200813151922.1093791-2-alex.popov@linux.com> <202008150939.A994680@keescook> <82edcbac-a856-cf9e-b86d-69a4315ea8e4@linux.com> In-Reply-To: <82edcbac-a856-cf9e-b86d-69a4315ea8e4@linux.com> From: Andrey Konovalov Date: Tue, 18 Aug 2020 17:45:50 +0200 Message-ID: Subject: Re: [PATCH RFC 1/2] mm: Extract SLAB_QUARANTINE from KASAN To: Alexander Popov , Dmitry Vyukov , Alexander Potapenko , Andrey Ryabinin , kasan-dev Cc: Kees Cook , Jann Horn , Will Deacon , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Masahiro Yamada , Masami Hiramatsu , Steven Rostedt , Peter Zijlstra , Krzysztof Kozlowski , Patrick Bellasi , David Howells , Eric Biederman , Johannes Weiner , Laura Abbott , Arnd Bergmann , Greg Kroah-Hartman , Linux Memory Management List , kernel-hardening@lists.openwall.com, LKML , notify@kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 20F17180442C4 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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, Aug 17, 2020 at 7:32 PM Alexander Popov wrote: > > On 15.08.2020 19:52, Kees Cook wrote: > > On Thu, Aug 13, 2020 at 06:19:21PM +0300, Alexander Popov wrote: > >> Heap spraying is an exploitation technique that aims to put controlled > >> bytes at a predetermined memory location on the heap. Heap spraying for > >> exploiting use-after-free in the Linux kernel relies on the fact that on > >> kmalloc(), the slab allocator returns the address of the memory that was > >> recently freed. Allocating a kernel object with the same size and > >> controlled contents allows overwriting the vulnerable freed object. > >> > >> Let's extract slab freelist quarantine from KASAN functionality and > >> call it CONFIG_SLAB_QUARANTINE. This feature breaks widespread heap > >> spraying technique used for exploiting use-after-free vulnerabilities > >> in the kernel code. > >> > >> If this feature is enabled, freed allocations are stored in the quarantine > >> and can't be instantly reallocated and overwritten by the exploit > >> performing heap spraying. > > > > It may be worth clarifying that this is specifically only direct UAF and > > doesn't help with spray-and-overflow-into-a-neighboring-object attacks > > (i.e. both tend to use sprays, but the former doesn't depend on a write > > overflow). > > Andrey Konovalov wrote: > > If quarantine is to be used without the rest of KASAN, I'd prefer for > > it to be separated from KASAN completely: move to e.g. mm/quarantine.c > > and don't mention KASAN in function/config names. > > Hmm, making quarantine completely separate from KASAN would bring troubles. > > Currently, in many special places the allocator calls KASAN handlers: > kasan_cache_create() > kasan_slab_free() > kasan_kmalloc_large() > kasan_krealloc() > kasan_slab_alloc() > kasan_kmalloc() > kasan_cache_shrink() > kasan_cache_shutdown() > and some others. > These functions do a lot of interesting things and also work with the quarantine > using these helpers: > quarantine_put() > quarantine_reduce() > quarantine_remove_cache() > > Making quarantine completely separate from KASAN would require to move some > internal logic of these KASAN handlers to allocator code. It doesn't look like there's quite a lot of KASAN-specific logic there. All those quarantine_*() calls are either at the beginning or at the end of some kasan annotations, so it should be quite easy to move those out. E.g. quarantine_reduce() can be moved together with the gfpflags_allow_blocking(flags) check and put before kasan_kmalloc() calls (or maybe also into some other places?), quarantine_put() can be put after kasan_slab_free(), etc. > In this patch I used another approach, that doesn't require changing the API > between allocators and KASAN. I added linux/mm/kasan/slab_quarantine.c with slim > KASAN handlers that implement the minimal functionality needed for quarantine. > > Do you think that it's a bad solution? This solution doesn't look clean. Here you provide a second KASAN runtime implementation, parallel to the original one, which only does quarantine. It seems much cleaner to put quarantine logic into a separate module, which can be either used independently, or together with KASAN built on top of it. Maybe other KASAN contributors have an opinion on this?