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 C5B37C46466 for ; Mon, 5 Oct 2020 16:49:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 33DDC20874 for ; Mon, 5 Oct 2020 16:49:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="YVj4GC3J" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 33DDC20874 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 4B8C58E0001; Mon, 5 Oct 2020 12:49:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 441D36B00A0; Mon, 5 Oct 2020 12:49:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 30B568E0001; Mon, 5 Oct 2020 12:49:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0250.hostedemail.com [216.40.44.250]) by kanga.kvack.org (Postfix) with ESMTP id 00E0D6B009F for ; Mon, 5 Oct 2020 12:49:52 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 197323631 for ; Mon, 5 Oct 2020 16:49:52 +0000 (UTC) X-FDA: 77338458624.14.bath19_2e0bdae271bf Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin14.hostedemail.com (Postfix) with ESMTP id E03AC1822987A for ; Mon, 5 Oct 2020 16:49:51 +0000 (UTC) X-HE-Tag: bath19_2e0bdae271bf X-Filterd-Recvd-Size: 6453 Received: from mail-ed1-f68.google.com (mail-ed1-f68.google.com [209.85.208.68]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Mon, 5 Oct 2020 16:49:51 +0000 (UTC) Received: by mail-ed1-f68.google.com with SMTP id p13so4198127edi.7 for ; Mon, 05 Oct 2020 09:49:51 -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=e75sgfE0gBHuZ+sQh5xSznZKqRTfepXZ5BM13ORNfbc=; b=YVj4GC3JL8go1+BQzjpqRqC+/HErXCrcVSbeTGXkmGNDW0inx8fYasntI3xi6q8VOM hJVNYfqKZPCzxROaMECiKmwLcdalUc1GdONuilK01tVtKa891PSDahBolGt9vJKkkSOL B0hyh8ssSuuwmiS2dIotXfe6KCbVlfk7jvA1blxGgHgJbdflFwobWNcvSrGx058Q/beR KU4kN/C5m3lc95eHwZLfKb3lf2wCsj5934cQIzfTnG9+JSUg0kYxuitggcx40qWKFVgI 77FMQRT8Q4W2BepuQvyuFCNaAX2Na1W5CNqAiuR2rDWjdrpuNHqtkwhLe9xKwKVBWEBG M3gA== 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=e75sgfE0gBHuZ+sQh5xSznZKqRTfepXZ5BM13ORNfbc=; b=NjiYQWz3s06qlnlDC/ZHDlQ8cprcnumfipa8uID63hRpY31uU/REnofssgxlLekuTt zWl5N7ZWn+bKO4oGdDRBf7Zm7k/AlwvyTzR8kOrXaoKTFp/Nxc3Oy5rT06EP3CTW96bN bquMEOST204Nje5/vheQNO3st2yyN4plpBZYdKS1Gr8ocpoxD3pitLipV0pEVruxxyZh YT5Wc8pnKN+Olpotna4o4dBLiRpyQt8CzJF+sLweDOtDGiC39xONAiFM7KaAI2x/i042 jlw1NfkKwsqSODxvO0sxPxBaI15Sd1FRL2ddc+ZghKhTSuLB1qOTg+CtGppnsfw2MRNj W5Vw== X-Gm-Message-State: AOAM532PLqXqJUUkd01kDedrfdKLxNaE5hjCHyJrrl+kR1MuRq9AOwwf Y61+mDoVbZVoq4vEEOzSbfvl9HOZdBfEqJZ5TYcNSw== X-Google-Smtp-Source: ABdhPJzebiK7XGTTGSesU9XZZts7MY9QebXYMDbKFDRw9FyOaSzmZF06erodX8ExTD8H4foe9ncp1NqIIGZDvVpWzfo= X-Received: by 2002:a50:ccd2:: with SMTP id b18mr555817edj.51.1601916589473; Mon, 05 Oct 2020 09:49:49 -0700 (PDT) MIME-Version: 1.0 References: <20200921132611.1700350-1-elver@google.com> <20200921132611.1700350-2-elver@google.com> <20200929142411.GC53442@C02TD0UTHF1T.local> <20200929150549.GE53442@C02TD0UTHF1T.local> In-Reply-To: From: Jann Horn Date: Mon, 5 Oct 2020 18:49:23 +0200 Message-ID: Subject: Re: [PATCH v3 01/10] mm: add Kernel Electric-Fence infrastructure To: Alexander Potapenko Cc: Mark Rutland , 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 , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Hillf Danton , Ingo Molnar , Jonathan Cameron , Jonathan Corbet , Joonsoo Kim , Kees Cook , Pekka Enberg , Peter Zijlstra , SeongJae Park , 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" 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, Oct 5, 2020 at 6:01 PM Alexander Potapenko wrote: > > On Tue, Sep 29, 2020 at 5:06 PM Mark Rutland wrote: > > > > On Tue, Sep 29, 2020 at 04:51:29PM +0200, Marco Elver wrote: > > > On Tue, 29 Sep 2020 at 16:24, Mark Rutland wrote: > > > [...] > > > > > > > > From other sub-threads it sounds like these addresses are not part of > > > > the linear/direct map. 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. > > > > > > > > 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). > > > > > > That's an excellent point, thank you! Indeed, on arm64, a version with > > > naive static-pool screams with CONFIG_DEBUG_VIRTUAL. > > > > > > We'll try to put together an arm64 version using a carveout as you suggest. > > > > Great, thanks! > > > > Just to be clear, the concerns for DMA and virt<->phys conversions also > > apply to x86 (the x86 virt<->phys conversion behaviour is more forgiving > > in the common case, but still has cases that can go wrong). > > To clarify, shouldn't kmalloc/kmem_cache allocations used with DMA be > allocated with explicit GFP_DMA? > If so, how practical would it be to just skip such allocations in > KFENCE allocator? AFAIK GFP_DMA doesn't really mean "I will use this allocation for DMA"; it means "I will use this allocation for DMA using some ancient hardware (e.g. stuff on the ISA bus?) that only supports 16-bit physical addresses (or maybe different limits on other architectures)". There's also GFP_DMA32, which means the same thing, except with 32-bit physical addresses. You can see in e.g. __dma_direct_alloc_pages() that the GFP_DMA32 and GFP_DMA flags are only used if the hardware can't address the full physical address space supported by the CPU.