From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f200.google.com (mail-io0-f200.google.com [209.85.223.200]) by kanga.kvack.org (Postfix) with ESMTP id 2CEC06B0006 for ; Wed, 4 Apr 2018 13:00:41 -0400 (EDT) Received: by mail-io0-f200.google.com with SMTP id 185so19861493iox.21 for ; Wed, 04 Apr 2018 10:00:41 -0700 (PDT) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id k25sor2609929iob.102.2018.04.04.10.00.38 for (Google Transport Security); Wed, 04 Apr 2018 10:00:38 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <0c4397da-e231-0044-986f-b8468314be76@virtuozzo.com> References: <805d1e85-2d3c-2327-6e6c-f14a56dc0b67@virtuozzo.com> <0c4397da-e231-0044-986f-b8468314be76@virtuozzo.com> From: Andrey Konovalov Date: Wed, 4 Apr 2018 19:00:35 +0200 Message-ID: Subject: Re: [RFC PATCH v2 13/15] khwasan: add hooks implementation Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Andrey Ryabinin Cc: Alexander Potapenko , Dmitry Vyukov , Jonathan Corbet , Catalin Marinas , Will Deacon , Marc Zyngier , Christopher Li , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Masahiro Yamada , Michal Marek , Mark Rutland , Ard Biesheuvel , Yury Norov , Nick Desaulniers , Suzuki K Poulose , Kristina Martsenko , Punit Agrawal , Dave Martin , Michael Weiser , James Morse , Julien Thierry , Steve Capper , Tyler Baicar , "Eric W . Biederman" , Thomas Gleixner , Ingo Molnar , Paul Lawrence , Greg Kroah-Hartman , David Woodhouse , Sandipan Das , Kees Cook , Herbert Xu , Geert Uytterhoeven , Josh Poimboeuf , Arnd Bergmann , kasan-dev , linux-doc@vger.kernel.org, LKML , Linux ARM , kvmarm@lists.cs.columbia.edu, linux-sparse@vger.kernel.org, Linux Memory Management List , Linux Kbuild mailing list , Kostya Serebryany , Evgeniy Stepanov , Lee Smith , Ramana Radhakrishnan , Jacob Bramley , Ruben Ayrapetyan , Kees Cook , Jann Horn , Mark Brand On Wed, Apr 4, 2018 at 2:39 PM, Andrey Ryabinin wrote: >>> >>> You can save tag somewhere in page struct and make page_address() return tagged address. >>> >>> I'm not sure it might be even possible to squeeze the tag into page->flags on some configurations, >>> see include/linux/page-flags-layout.h >> >> One page can contain multiple objects with different tags, so we would >> need to save the tag for each of them. > > What do you mean? Slab page? The per-page tag is needed only for !PageSlab pages. > For slab pages we have kmalloc/kmem_cache_alloc() which already return properly tagged address. > > But the page allocator returns a pointer to struct page. One has to call page_address(page) > to use that page. Returning 'ignore-me'-tagged address from page_address() makes the whole > class of bugs invisible to KHWASAN. This is a serious downside comparing to classic KASAN which can > detect missuses of page allocator API. Yes, slab page. Here's an example: 1. do_get_write_access() allocates frozen_buffer with jbd2_alloc, which calls kmem_cache_alloc, and then saves the result to jh->b_frozen_data. 2. jbd2_journal_write_metadata_buffer() takes the value of jh_in->b_frozen_data and calls virt_to_page() (and offset_in_page()) on it. 3. jbd2_journal_write_metadata_buffer() then calls kmap_atomic(), which calls page_address(), on the resulting page address. The tag gets erased. The page belongs to slab and can contain multiple objects with different tags. >>> I don't see any possible way of khwasan_enabled being 0 here. >> >> Can't kmem_cache_alloc be called for the temporary caches that are >> used before the slab allocator and kasan are initialized? > > kasan_init() runs before allocators are initialized. > slab allocator obviously has to be initialized before it can be used. Checked the code, it seems you are right. Boot caches are created after kasan_init() is called. I will remove khwasan_enabled. Thanks!