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=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 A90DDC433E2 for ; Tue, 8 Sep 2020 15:32:40 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5A92821D7E for ; Tue, 8 Sep 2020 15:32:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="oqBbu9C6"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="Ve3aQ+oi" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5A92821D7E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=JFZGLbipaK2Xv3y+dTpJrMv0tuGkV7h3TshDxAN0c68=; b=oqBbu9C6Z1wcSZmI3x8ID2kTb V8kPAQtDRXxGF28pIIYJC2u7PYbordqdV5sNqBhmtkCzwHDHSRiiLerGHVmk71MnDeTm2Cw+EKLgF gaCLTvnTjpApZHeG3dJeAK4W/op/+db5DMr8OusN4rPk7Umndwy0LnbIR8D+UdgVNWt5j2+3WbYb4 1oQD2PnVQwk6AjPM7P/i1kf1Zmn/rnjSsIrRX6e08SSmle9tYidhvnA8l4kVj1i3cMkE+JF0IxGuX 0A491Oqzz89p7dRrJIJZ5IIUfsZeed0tpYJirFIlQd2lG8DPnshHNMdNxk3JNcCdPl/o8UpyKxpUt JQKURGyoA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFfaV-0004o5-Q9; Tue, 08 Sep 2020 15:31:15 +0000 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFfaS-0004mD-BD for linux-arm-kernel@lists.infradead.org; Tue, 08 Sep 2020 15:31:13 +0000 Received: by mail-wr1-x443.google.com with SMTP id k15so19547366wrn.10 for ; Tue, 08 Sep 2020 08:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=YQgUsxZ9GX3vVBI6rWEDHgnkdvr/rXnkrQPmjYVedKg=; b=Ve3aQ+oisG54K1DBOJ6Vv+bfGmYnw8xEga4PIbgpydxas1I6Ucz4AP85ilqGU5v42M ppBWoLaAg0QPXJrjC+pTOvaXY3oT3KTo5FkSxl5Br19DLYKrIf4ZE7i5XBHZfPaLWdLq swqZEgFcwM2oTWjcAm4wstHbLRyWM5dXa7puN16iULpm1dLlLp2PcZojXIWrAaAeMpne gGcrBg5oM48MAvo0LKHh34SO0eWxkl32XY8o0kJFUU6BPKXe7UVuPJTWZaMw/9ppvdlK v4uSzjMcHxXNB7lV2zW69TkrrX70h/88OKykIHufyVSGOfbJ2+daKNTfnHctp1asLp75 moPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=YQgUsxZ9GX3vVBI6rWEDHgnkdvr/rXnkrQPmjYVedKg=; b=ZzKEiHRSY7heOYFjcgPfrFboC2f2gZkvpYUo0B8aKH2l7NSPO3gHquJm/CAm65e1Fa O3zZf9vaouJGg+KrgTMG0kh4wlRIiLzDfA41hzKq4ccgYJzHf8EYKUuKJ+P9EWILZpTp 3bfNrvam1gP0LpxWa+pKXbnomj12snX92pM+osxhkn/3N6V6qPcNrtRzHLlFhC9lW6NX ea0LDCcohvbRMRqHDegjRZyyoEapa2PdMWHGMBUz9F0gUym9qmxxbU3wuoV5A5ioFFox 8MZhJdAx0lnWPAYyOLrbluGEwMSueDDKaV085E3Kg+aVX2ApVeNHhF9mtN29l1O7yZGt nV4A== X-Gm-Message-State: AOAM531QIjAd6lpQSz4tgvS6X7WmOevo1wHAhTwXM0TFDz412ITX2R8Q 9lpYSeDqPNw6YoG1o//tA5vIYA== X-Google-Smtp-Source: ABdhPJzpeL/LG5MivE4qK84Vzr9Pz3Mah/87BWpTWioecpMtrDM52Kk30hPIYNgBxE+EHgxQQKTYoQ== X-Received: by 2002:a5d:52c6:: with SMTP id r6mr172681wrv.141.1599579070236; Tue, 08 Sep 2020 08:31:10 -0700 (PDT) Received: from elver.google.com ([100.105.32.75]) by smtp.gmail.com with ESMTPSA id d6sm34017392wrq.67.2020.09.08.08.31.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Sep 2020 08:31:09 -0700 (PDT) Date: Tue, 8 Sep 2020 17:31:02 +0200 From: Marco Elver To: Dave Hansen Subject: Re: [PATCH RFC 00/10] KFENCE: A low-overhead sampling-based memory safety error detector Message-ID: <20200908153102.GB61807@elver.google.com> References: <20200907134055.2878499-1-elver@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.14.4 (2020-06-18) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200908_113112_409901_5C47F658 X-CRM114-Status: GOOD ( 22.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, linux-doc@vger.kernel.org, peterz@infradead.org, catalin.marinas@arm.com, dave.hansen@linux.intel.com, linux-mm@kvack.org, edumazet@google.com, glider@google.com, hpa@zytor.com, cl@linux.com, will@kernel.org, corbet@lwn.net, x86@kernel.org, kasan-dev@googlegroups.com, mingo@redhat.com, linux-arm-kernel@lists.infradead.org, rientjes@google.com, aryabinin@virtuozzo.com, keescook@chromium.org, paulmck@kernel.org, jannh@google.com, andreyknvl@google.com, bp@alien8.de, luto@kernel.org, tglx@linutronix.de, akpm@linux-foundation.org, dvyukov@google.com, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, penberg@kernel.org, cai@lca.pw, iamjoonsoo.kim@lge.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Sep 08, 2020 at 07:52AM -0700, Dave Hansen wrote: > On 9/7/20 6:40 AM, Marco Elver wrote: > > KFENCE is designed to be enabled in production kernels, and has near > > zero performance overhead. Compared to KASAN, KFENCE trades performance > > for precision. > > Could you talk a little bit about where you expect folks to continue to > use KASAN? How would a developer or a tester choose which one to use? We mention some of this in Documentation/dev-tools/kfence.rst: In the kernel, several tools exist to debug memory access errors, and in particular KASAN can detect all bug classes that KFENCE can detect. While KASAN is more precise, relying on compiler instrumentation, this comes at a performance cost. We want to highlight that KASAN and KFENCE are complementary, with different target environments. For instance, KASAN is the better debugging-aid, where a simple reproducer exists: due to the lower chance to detect the error, it would require more effort using KFENCE to debug. Deployments at scale, however, would benefit from using KFENCE to discover bugs due to code paths not exercised by test cases or fuzzers. If you can afford to use KASAN, continue using KASAN. Usually this only applies to test environments. If you have kernels for production use, and cannot enable KASAN for the obvious cost reasons, you could consider KFENCE. I'll try to make this clearer, maybe summarizing what I said here in Documentation as well. > > 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. > > How much memory overhead does this end up having? I know it depends on > the object size and so forth. But, could you give some real-world > examples of memory consumption? Also, what's the worst case? Say I > have a ton of worst-case-sized (32b) slab objects. Will I notice? KFENCE objects are limited (default 255). If we exhaust KFENCE's memory pool, no more KFENCE allocations will occur. Documentation/dev-tools/kfence.rst gives a formula to calculate the KFENCE pool size: The total memory dedicated to the KFENCE memory pool can be computed as:: ( #objects + 1 ) * 2 * PAGE_SIZE Using the default config, and assuming a page size of 4 KiB, results in dedicating 2 MiB to the KFENCE memory pool. Does that clarify this point? Or anything else that could help clarify this? Thanks, -- Marco _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel