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 AD58CC32793 for ; Wed, 18 Jan 2023 07:36:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDC6C6B0074; Wed, 18 Jan 2023 02:36:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E8C136B0075; Wed, 18 Jan 2023 02:36:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D53846B0078; Wed, 18 Jan 2023 02:36:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id C284C6B0074 for ; Wed, 18 Jan 2023 02:36:25 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8BD6CAB035 for ; Wed, 18 Jan 2023 07:36:25 +0000 (UTC) X-FDA: 80367111930.08.96B8B54 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf03.hostedemail.com (Postfix) with ESMTP id DA4F620010 for ; Wed, 18 Jan 2023 07:36:23 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Y1PYitAE; spf=pass (imf03.hostedemail.com: domain of dvyukov@google.com designates 209.85.167.43 as permitted sender) smtp.mailfrom=dvyukov@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=1674027384; 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=tXJS6O96pqUrAn6JTjfwzdlxbTr5MxmXpgvppk1+ZUI=; b=e4LMDKiRFY8TE1oI/PSHp9rPwKVBRFFEXktrqP2ybOwD3rirCm+wDdtd5P7asJ8FuLSs6q yta7rG6niVmsQWJnRxAqaOSC0faPbCx2shP+KZeeoFmE66vBnMBRmuznzVHqQHuMbZmLRO rb/PT0x8bh3k312wK7UoQhKY0c/5UAQ= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Y1PYitAE; spf=pass (imf03.hostedemail.com: domain of dvyukov@google.com designates 209.85.167.43 as permitted sender) smtp.mailfrom=dvyukov@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674027384; a=rsa-sha256; cv=none; b=AUdYJe+38Tag3RYydCiylCwCzRHaf1sbAuKidK6sUxwAPAt6sxFB+Tnu9MRSMv6PUAZpas C/awVHlLRbp0R7k2LCpAMLvib8II/Xd7cbckaxMA+5K8UchH7YGaJcR0hUFmjvWTCuWgyQ GkMqaCTukQKH2VPOOYx9GBQOsVETyHw= Received: by mail-lf1-f43.google.com with SMTP id br9so15215963lfb.4 for ; Tue, 17 Jan 2023 23:36:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tXJS6O96pqUrAn6JTjfwzdlxbTr5MxmXpgvppk1+ZUI=; b=Y1PYitAEZNLh0tMF269DyDhvK7SU90x/pZSKSUY1YcSH3Q6dxMtNI8y9Q6AN6MVyxY cn5Ye3GOhKXE+nTWj69viVf+zWfsKnvGe6xqqrgFpGLlGCyy8uyKFasmeGN8dSb1KTLJ uTn3z7L2Fi3f18OTfxJPfiPGQRrL04ekm6xNXWKL9NZsnsFrxC/Z1S5LqSI9bPH2p+W3 lmRkmrIyJwD9dBWQgUU1cqe+YQcXSdCW4QFho72DRZ2iucpHpsiXUmFmB+FKdnM/7bZM t9mm3hEVPaskSJ+LwS35XMx0JGimed0EqmiCjGOCFNq6fy6Ea1iT55TyTPNLYakuXk7B B/mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=tXJS6O96pqUrAn6JTjfwzdlxbTr5MxmXpgvppk1+ZUI=; b=S0zOkxBELIhsETWwsBj4cyJCoCU5xwyGHju7erYmW7vVhSZ98tvPBNnDfhXOFBACV8 EJdyhS/BO5o6WbSyOmqgM7mfpm2ul0w5HNiObXJcidbyBv84nIg+3oAGy0h/pT76g0c/ mYBGCJaXS/cAnJNpu/uXA4xIz8FGE56+sh8FpWoxVEKqXgUuLbZxM+EV7NwbSbiVlxn3 TUakxkUlxSh+1kVIrgKcO31dMAJcwmuJ67oV8Rsd/iLvC8DqAuz+oO8PzYLdVrS6DrnI LIbsfYnS1SPLDl+iuEqmG+p08uhK4nL3G1tro1zQvHZOYCrmNnYp8v3jT8eIiDpieztM JarQ== X-Gm-Message-State: AFqh2koK+LQGSUidRO6+lPlVDIzyV6IHTdY2mmLb/lHAFTruMBV7V4th w1Y3oLumkcLeWYKN946OgjtneP7lcbHs1rm/VB13AQ== X-Google-Smtp-Source: AMrXdXuj5bzcgQGLaz1JgVZv2c7juMWmB7EfCOepc1a7fDbsUWhqpEZ3Uj+TmWN0FE8M1AQbWRFpg+6i/hAV1CzefpU= X-Received: by 2002:ac2:4bd0:0:b0:4c5:32a4:6f88 with SMTP id o16-20020ac24bd0000000b004c532a46f88mr410419lfq.6.1674027381894; Tue, 17 Jan 2023 23:36:21 -0800 (PST) MIME-Version: 1.0 References: <20230117163543.1049025-1-jannh@google.com> In-Reply-To: <20230117163543.1049025-1-jannh@google.com> From: Dmitry Vyukov Date: Wed, 18 Jan 2023 08:36:09 +0100 Message-ID: Subject: Re: [PATCH] fork, vmalloc: KASAN-poison backing pages of vmapped stacks To: Jann Horn Cc: Andrew Morton , linux-mm@kvack.org, Uladzislau Rezki , Christoph Hellwig , Andy Lutomirski , linux-kernel@vger.kernel.org, Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Vincenzo Frascino , kasan-dev@googlegroups.com Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: DA4F620010 X-Stat-Signature: i8n6pbmupwjiaa8rs1a5imokpxu4e45q X-HE-Tag: 1674027383-63144 X-HE-Meta: U2FsdGVkX19b1mf5id9zPB06PaauSN4GcA8gTNZg9hqSZB6wbwKqkjU7OQtlvEoK9SLiLTPpNJyqRixYBbFx70TsdGUUhJ4PMkD5x7OBHCEkvr7n8vlXk7NLL0xW/VVhutIGGWUfZz7Cy5f45nfHzxbBdFzoI/9HzZTKhvZ5TGFSjN+KEQGWvRIcs/dsijXJMHa+umGP55pF92ivqxg2ExVlHtadiaB1NI+hZQMeyZogffaK36Rbu6Rk6wCqe2FyjMvIuAMAF9U+rITpC4+RhI1Dy1efiCAiY5jEUbh8WnIIb7KFBCop4O2FqOk5DHx2NetIby5zSs+Lsecee0BCc4GhaAklnIf69sk0wg8zHKzJyRfyL7ayhpHa+94rjEZZY7+3GU9/fq/mLuEOlHU+OLKKnJrPSwiEbRW/zBY67rjcjZulXOqrRut2ZsqnvSE5YXb8qGmiq9Iz9hp8KYc2CcRJTjCjXD4vCEP4DY6ZyP1BzeCMRsaPGqnOvjrGP3qEDbn6SQiixSjGEPSDdpB/7EIZY0fXR/d7Gfl0L+N85lTH7b/1nbi+UdenSTpwuAs5h4n5x2kE5EBWB0e4QyEqbiopJIJQJt0UHnRqzcQPAi0492tRCPLVyjcEMto77G5DdBSDrt6Iw50mn9UEvkGeJ08a/VlyqO4r98YT5LdKM2IdIrYBblRFxqYmmx/HiqGgbtaG3Y9dhPk7UCsaCkSl/NabXf5EpB8WjeZRzcbAraVS+tLP+XPRupP+bRmBct74clbgASVs9+/JaJ+7sxiOdTpwk8a83zBsSpQ+Pl8gQzBzGEpRs8u85354p5d8Ckm62UCVU1ZlzWzeHRgVAhGwa8KNpVzm5PJWvWGhQVA8bHGKLCztJDZANEg0Fb/M3KzMTWNaZU2Hr3FsLooWc3WtGDVRTMmfqvfngbSY3t+G47+Qwcx79OQSgPHi1qQQDKnRWAKh+p/7i1HY7bnMMn0 9KTKrcsc kgE60BamV1aayiQBpHp/Tlup1nOg5NYjWZWax71X5ppf7e8TpRXlPR5dJ4KqFrgb+PCLh9O2YrEUYrkpZZvpbtBytFQ== 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 Tue, 17 Jan 2023 at 17:35, Jann Horn wrote: > > KASAN (except in HW_TAGS mode) tracks memory state based on virtual > addresses. The mappings of kernel stack pages in the linear mapping are > currently marked as fully accessible. Hi Jann, To confirm my understanding, this is not just KASAN (except in HW_TAGS mode), but also CONFIG_VMAP_STACK is required, right? > Since stack corruption issues can cause some very gnarly errors, let's be > extra careful and tell KASAN to forbid accesses to stack memory through the > linear mapping. > > Signed-off-by: Jann Horn > --- > I wrote this after seeing > https://lore.kernel.org/all/Y8W5rjKdZ9erIF14@casper.infradead.org/ > and wondering about possible ways that this kind of stack corruption > could be sneaking past KASAN. > That's proooobably not the explanation, but still... I think catching any silent corruptions is still very useful. Besides confusing reports, sometimes they lead to an explosion of random reports all over the kernel. > include/linux/vmalloc.h | 6 ++++++ > kernel/fork.c | 10 ++++++++++ > mm/vmalloc.c | 24 ++++++++++++++++++++++++ > 3 files changed, 40 insertions(+) > > diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h > index 096d48aa3437..bfb50178e5e3 100644 > --- a/include/linux/vmalloc.h > +++ b/include/linux/vmalloc.h > @@ -297,4 +297,10 @@ bool vmalloc_dump_obj(void *object); > static inline bool vmalloc_dump_obj(void *object) { return false; } > #endif > > +#if defined(CONFIG_MMU) && (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) > +void vmalloc_poison_backing_pages(const void *addr); > +#else > +static inline void vmalloc_poison_backing_pages(const void *addr) {} > +#endif I think this should be in kasan headers and prefixed with kasan_. There are also kmsan/kcsan that may poison memory and hw poisoning (MADV_HWPOISON), so it's a somewhat overloaded term on its own. Can/should this be extended to all vmalloc-ed memory? Or some of it can be accessed via both addresses? Also, should we mprotect it instead while it's allocated as the stack? If it works, it looks like a reasonable improvement for CONFIG_VMAP_STACK in general. Would also catch non-instrumented accesses. > #endif /* _LINUX_VMALLOC_H */ > diff --git a/kernel/fork.c b/kernel/fork.c > index 9f7fe3541897..5c8c103a3597 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -321,6 +321,16 @@ static int alloc_thread_stack_node(struct task_struct *tsk, int node) > vfree(stack); > return -ENOMEM; > } > + > + /* > + * A virtually-allocated stack's memory should only be accessed through > + * the vmalloc area, not through the linear mapping. > + * Inform KASAN that all accesses through the linear mapping should be > + * reported (instead of permitting all accesses through the linear > + * mapping). > + */ > + vmalloc_poison_backing_pages(stack); > + > /* > * We can't call find_vm_area() in interrupt context, and > * free_thread_stack() can be called in interrupt context, > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index ca71de7c9d77..10c79c53cf5c 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -4042,6 +4042,30 @@ void pcpu_free_vm_areas(struct vm_struct **vms, int nr_vms) > } > #endif /* CONFIG_SMP */ > > +#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS) > +/* > + * Poison the KASAN shadow for the linear mapping of the pages used as stack > + * memory. > + * NOTE: This makes no sense in HW_TAGS mode because HW_TAGS marks physical > + * memory, not virtual memory. > + */ > +void vmalloc_poison_backing_pages(const void *addr) > +{ > + struct vm_struct *area; > + int i; > + > + if (WARN(!PAGE_ALIGNED(addr), "bad address (%p)\n", addr)) > + return; > + > + area = find_vm_area(addr); > + if (WARN(!area, "nonexistent vm area (%p)\n", addr)) > + return; > + > + for (i = 0; i < area->nr_pages; i++) > + kasan_poison_pages(area->pages[i], 0, false); > +} > +#endif > + > #ifdef CONFIG_PRINTK > bool vmalloc_dump_obj(void *object) > { > > base-commit: 5dc4c995db9eb45f6373a956eb1f69460e69e6d4 > -- > 2.39.0.314.g84b9a713c41-goog >