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,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 21173C433E2 for ; Mon, 7 Sep 2020 18:16:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A2693207DE for ; Mon, 7 Sep 2020 18:16:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="K4nkmgZM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A2693207DE 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 0B6716B0002; Mon, 7 Sep 2020 14:16:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 03EC56B0037; Mon, 7 Sep 2020 14:16:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E23C36B0055; Mon, 7 Sep 2020 14:16:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0227.hostedemail.com [216.40.44.227]) by kanga.kvack.org (Postfix) with ESMTP id C78CD6B0002 for ; Mon, 7 Sep 2020 14:16:26 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 7FDE6181AEF00 for ; Mon, 7 Sep 2020 18:16:26 +0000 (UTC) X-FDA: 77237070372.16.veil71_2305957270ce Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id 54570100E6903 for ; Mon, 7 Sep 2020 18:16:26 +0000 (UTC) X-HE-Tag: veil71_2305957270ce X-Filterd-Recvd-Size: 6334 Received: from mail-oo1-f68.google.com (mail-oo1-f68.google.com [209.85.161.68]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Mon, 7 Sep 2020 18:16:25 +0000 (UTC) Received: by mail-oo1-f68.google.com with SMTP id h9so3410047ooo.10 for ; Mon, 07 Sep 2020 11:16:25 -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=R5wKHqfwSX4tMBwD67UcVJ4BSt4O+DvIHtBQvGXOV+4=; b=K4nkmgZMU1BL8hol3wBtjK0bL6d36hR7CBWsM+3EgMDiiO0PBpF7JHwRYDUmwUPg4h 1VP8mrfm0Zlp7D5JlqFqXYERaQenl7jM/yjbcMYdxU9HSL6OAJI0DdvYZZ40BLHDbNjf dwy4NZUDXO/663GUjnvP/MfzrQRQYarLEiUC7NP8ih8TL3tQ18xEmCiJ98A+YqBOaM+U jYxUtc8GanrjiDuP0syRYpXV+b32IGS4EPIf30MZ5u4647BXbRocBScurypnJuEEwJwt 9YBgAOWBClGCz7tWtWYjp92GK4+pfzHsuCuY3pqK9m/AFlrXpb/U4wpN/1eNzJoOHmn2 7TEw== 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=R5wKHqfwSX4tMBwD67UcVJ4BSt4O+DvIHtBQvGXOV+4=; b=WnWP4El//ru2rEoa/qotUeW0kxz1zrn7cmCVmoTspgUrUW3hRye1d+DFd5HbrS/wGp 1ADYHeIBUcc6NCZOZXLlJ3XkSFvspsl4vFh6XccpIE35qSWLS8QSUm43luWAPe/DOLe1 0shmCgVGeCKr6Iexd2VYSK/sivBZKp/LwHsmTk5ZYhcfOqSTRvxdxaXrv30kcM9yPtUg 6eOPpBtLnIXqO3eL+ED+QG2n6p0nioU8bxNKbIPuc/5bqfVzEhTEm3Tsre6rxnXYc/0U Fvt/K+p2eaSISdgTSTz228BUzkdCrW1pUV9gtZbli1KO+ZIHLq7k0lgg+OJ8c12AhyOU hR+Q== X-Gm-Message-State: AOAM533bDvqanJv07jfoAJ/qRmVYacjf5mI9VXbfHeK0EopD5fY9NZQH VmZlCO+H7hg8mQ5kjaQKYst9sPp+BkM/47J7sbINhQ== X-Google-Smtp-Source: ABdhPJzAEWw7U1yg3vx4wRYG07d5NYt11k3IChID/WYGphofmGzgUHpslTr9pCxK3O5lHYRzrb3fnqposjMk5wp8nSU= X-Received: by 2002:a4a:4fd0:: with SMTP id c199mr15788309oob.54.1599502584851; Mon, 07 Sep 2020 11:16:24 -0700 (PDT) MIME-Version: 1.0 References: <20200907134055.2878499-1-elver@google.com> <20200907134055.2878499-10-elver@google.com> In-Reply-To: From: Marco Elver Date: Mon, 7 Sep 2020 20:16:13 +0200 Message-ID: Subject: Re: [PATCH RFC 09/10] kfence, Documentation: add KFENCE documentation To: Andrey Konovalov Cc: Alexander Potapenko , Andrew Morton , Catalin Marinas , Christoph Lameter , David Rientjes , Joonsoo Kim , Mark Rutland , Pekka Enberg , "H. Peter Anvin" , "Paul E . McKenney" , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , Dave Hansen , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Ingo Molnar , Jann Horn , Jonathan Corbet , Kees Cook , Peter Zijlstra , Qian Cai , Thomas Gleixner , 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-Rspamd-Queue-Id: 54570100E6903 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, 7 Sep 2020 at 19:55, Andrey Konovalov wrote: > On Mon, Sep 7, 2020 at 6:33 PM Marco Elver wrote: [...] > > > > +Guarded allocations are set up based on the 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). > > > > > > Only for freed allocations, right? > > > > Which "freed allocation"? What this paragraph says is that after the > > sample interval elapsed, we'll return a KFENCE allocation on kmalloc. > > It doesn't yet talk about freeing. > > It says that an allocation is returned to the main allocator, and this > is what is usually described with the word "freed". Do you mean > something else here? Ah, I see what's goin on. So the "returned to the main allocator" is ambiguous here. I meant to say "returned" as in kfence gives sl[au]b a kfence object to return for the next kmalloc. I'll reword this as it seems the phrase is overloaded in this context already. [...] > > > > +Upon deallocation of a KFENCE object, the object's page is again protected and > > > > +the object is marked as freed. Any further access to the object causes a fault > > > > +and KFENCE reports a use-after-free access. Freed objects are inserted at the > > > > +tail of KFENCE's freelist, so that the least recently freed objects are reused > > > > +first, and the chances of detecting use-after-frees of recently freed objects > > > > +is increased. > > > > > > Seems really similar to KASAN's quarantine? Is the implementation much > > > different? > > > > It's a list, and we just insert at the tail. Why does it matter? > > If the implementation is similar, we can then reuse quarantine. But I > guess it's not. The concept is similar, but the implementations are very different. Both use a list (although KASAN quarantine seems to reimplement its own singly-linked list). We just rely on a standard doubly-linked list, without any of the delayed freeing logic of the KASAN quarantine as KFENCE objects just change state to "freed" until they're reused (freed kfence objects are just inserted at the tail, and the next object to be used for an allocation is at the head). Thanks, -- Marco