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.9 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 5A46DC4741F for ; Tue, 29 Sep 2020 15:52:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 938DB20C09 for ; Tue, 29 Sep 2020 15:52:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="C1AnuCCs" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 938DB20C09 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 6A3716B005C; Tue, 29 Sep 2020 11:52:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 62DBC6B005D; Tue, 29 Sep 2020 11:52:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4F79A8E0001; Tue, 29 Sep 2020 11:52:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0075.hostedemail.com [216.40.44.75]) by kanga.kvack.org (Postfix) with ESMTP id 301B96B005C for ; Tue, 29 Sep 2020 11:52:12 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id DF3C51730846 for ; Tue, 29 Sep 2020 15:52:11 +0000 (UTC) X-FDA: 77316540462.01.whip61_1c0354f2718b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id BAA181004D424 for ; Tue, 29 Sep 2020 15:52:11 +0000 (UTC) X-HE-Tag: whip61_1c0354f2718b X-Filterd-Recvd-Size: 8282 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Tue, 29 Sep 2020 15:52:11 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id t10so6005624wrv.1 for ; Tue, 29 Sep 2020 08:52:11 -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:content-transfer-encoding; bh=waqIMiy+b2Y1XhEMp7lwlO73kRIAH1OEaVKybD+u/ZQ=; b=C1AnuCCs/G/bgA/1YUmJNF1XFBujise6V07eyEJJbbGfWWHPX2GIlFrVyhXkrH37sQ 4D4/krQiYT/p7pJRrz3xRrYYUbhyOjtPvSFnorNVoaXsLOa01N5SXKpDjsI5FndLnhRd 8nK6h5qWp161tMRwNkkygqbTqyOdPiFESFKY1juuvWxIlXC/k38w8aUaMO24jxlGlnjt 8E4fz28XrSpaprVTj00BiuGBXBkyXouN3n7UAFQy42yNhHXd8HqUbkpyNmUq8wON2nT6 bR28M/YWkmC1hvdZjdZHvkiQbcWBAX5c7Y1P31soTuUXGQ6B3jh8O1vONpSzsyquRPi5 O9Ng== 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:content-transfer-encoding; bh=waqIMiy+b2Y1XhEMp7lwlO73kRIAH1OEaVKybD+u/ZQ=; b=U9xnfMweMbp1oTkUxag/lfSNgXPC9yXjzCzOEjkDwtnSkUCzza94BRysJxHdRj17c4 UjvSQ04odZ2MG4iIcvVvV37e1U6JpX4yvmQ0fGi9elmNBAO/ZOPDKWfVBz6wrBT/uUXK D7r8WVlxEfGOcTOYF4t7HyKo6LJstQ73dEeWKNVbHc+x/e2JICe7bhJdwvCQL49KR3X/ n4rmZNc9hvyu2Oc8p5NbIy4p5KF5Pp3loj7bhsK/r9DhfbFpAMF+eQrZSaQQEWAJVSk3 xz76w6OAWKjPYpd5sz/2FSjtQWIlLLMht9gxMU61VtKv9AUFi401y+naoQUq3eNFjwee hpxA== X-Gm-Message-State: AOAM532uL6OiJBJsbyysyUHlS0V+Re5UAZnKOcAyPqT+hbXXx42QiVur LGqja5w6CfSMKjG7psOw5KG5InFENnD8k2OwTEEmAA== X-Google-Smtp-Source: ABdhPJyt0n3BFeP7541F+hN//hQOYJ9pNhiIXhLw+JPQvp3FfyuIQnsFqmqLKix89U+C2Ps2OK6T6XilQ90ujF0il+k= X-Received: by 2002:adf:e312:: with SMTP id b18mr5418270wrj.372.1601394729790; Tue, 29 Sep 2020 08:52:09 -0700 (PDT) MIME-Version: 1.0 References: <20200921132611.1700350-1-elver@google.com> <20200921132611.1700350-2-elver@google.com> <20200929142411.GC53442@C02TD0UTHF1T.local> In-Reply-To: <20200929142411.GC53442@C02TD0UTHF1T.local> From: Alexander Potapenko Date: Tue, 29 Sep 2020 17:51:58 +0200 Message-ID: Subject: Re: [PATCH v3 01/10] mm: add Kernel Electric-Fence infrastructure To: Mark Rutland Cc: Marco Elver , Andrew Morton , "H. Peter Anvin" , "Paul E. McKenney" , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Christoph Lameter , Dave Hansen , David Rientjes , Dmitriy Vyukov , Eric Dumazet , Greg Kroah-Hartman , Hillf Danton , Ingo Molnar , Jann Horn , Jonathan.Cameron@huawei.com, Jonathan Corbet , Joonsoo Kim , Kees Cook , Pekka Enberg , Peter Zijlstra , sjpark@amazon.com, Thomas Gleixner , Vlastimil Babka , Will Deacon , "the arch/x86 maintainers" , "open list:DOCUMENTATION" , LKML , kasan-dev , Linux ARM , Linux Memory Management List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, Sep 29, 2020 at 4:24 PM Mark Rutland wrote: > > On Mon, Sep 21, 2020 at 03:26:02PM +0200, Marco Elver wrote: > > From: Alexander Potapenko > > > > This adds the Kernel Electric-Fence (KFENCE) infrastructure. KFENCE is = a > > low-overhead sampling-based memory safety error detector of heap > > use-after-free, invalid-free, and out-of-bounds access errors. > > > > KFENCE is designed to be enabled in production kernels, and has near > > zero performance overhead. Compared to KASAN, KFENCE trades performance > > for precision. The main motivation behind KFENCE's design, is that with > > enough total uptime KFENCE will detect bugs in code paths not typically > > exercised by non-production test workloads. One way to quickly achieve = a > > large enough total uptime is when the tool is deployed across a large > > fleet of machines. > > > > KFENCE objects each reside on a dedicated page, at either the left or > > right page boundaries. The pages to the left and right of the object > > page are "guard pages", whose attributes are changed to a protected > > state, and cause page faults on any attempted access to them. Such page > > faults are then intercepted by KFENCE, which handles the fault > > gracefully by reporting a memory access error. To detect out-of-bounds > > writes to memory within the object's page itself, KFENCE also uses > > pattern-based redzones. The following figure illustrates the page > > layout: > > > > ---+-----------+-----------+-----------+-----------+-----------+--- > > | xxxxxxxxx | O : | xxxxxxxxx | : O | xxxxxxxxx | > > | xxxxxxxxx | B : | xxxxxxxxx | : B | xxxxxxxxx | > > | x GUARD x | J : RED- | x GUARD x | RED- : J | x GUARD x | > > | xxxxxxxxx | E : ZONE | xxxxxxxxx | ZONE : E | xxxxxxxxx | > > | xxxxxxxxx | C : | xxxxxxxxx | : C | xxxxxxxxx | > > | xxxxxxxxx | T : | xxxxxxxxx | : T | xxxxxxxxx | > > ---+-----------+-----------+-----------+-----------+-----------+--- > > > > Guarded allocations are set up based on a sample interval (can be set > > via kfence.sample_interval). After expiration of the sample interval, a > > guarded allocation from the KFENCE object pool is returned to the main > > allocator (SLAB or SLUB). At this point, the timer is reset, and the > > next allocation is set up after the expiration of the interval. > > From other sub-threads it sounds like these addresses are not part of > the linear/direct map. For x86 these addresses belong to .bss, i.e. "kernel text mapping" section, isn't that the linear map? I also don't see lm_alias being used much outside arm64 code. > Having kmalloc return addresses outside of the > linear map is going to break anything that relies on virt<->phys > conversions, and is liable to make DMA corrupt memory. There were > problems of that sort with VMAP_STACK, and this is why kvmalloc() is > separate from kmalloc(). > > Have you tested with CONFIG_DEBUG_VIRTUAL? I'd expect that to scream. Just checked - it doesn't scream on x86. > I strongly suspect this isn't going to be safe unless you always use an > in-place carevout from the linear map (which could be the linear alias > of a static carevout). > > [...] > > > +static __always_inline void *kfence_alloc(struct kmem_cache *s, size_t= size, gfp_t flags) > > +{ > > + return static_branch_unlikely(&kfence_allocation_key) ? __kfence_= alloc(s, size, flags) : > > + NUL= L; > > +} > > Minor (unrelated) nit, but this would be easier to read as: > > static __always_inline void *kfence_alloc(struct kmem_cache *s, size_t si= ze, gfp_t flags) > { > if (static_branch_unlikely(&kfence_allocation_key)) > return __kfence_alloc(s, size, flags); > return NULL; > } > > Thanks, > Mark. --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg