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 C325FC433DF for ; Tue, 20 Oct 2020 12:13:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 26950217A0 for ; Tue, 20 Oct 2020 12:13:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="O+WQf8Zs" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 26950217A0 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 706406B006C; Tue, 20 Oct 2020 08:13:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6B65D6B006E; Tue, 20 Oct 2020 08:13:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A52E6B0070; Tue, 20 Oct 2020 08:13:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0146.hostedemail.com [216.40.44.146]) by kanga.kvack.org (Postfix) with ESMTP id 27E206B006C for ; Tue, 20 Oct 2020 08:13:18 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id AE0E4180AD807 for ; Tue, 20 Oct 2020 12:13:17 +0000 (UTC) X-FDA: 77392193634.27.fang16_25034d72723f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 8E0D63D663 for ; Tue, 20 Oct 2020 12:13:17 +0000 (UTC) X-HE-Tag: fang16_25034d72723f X-Filterd-Recvd-Size: 6505 Received: from mail-pl1-f196.google.com (mail-pl1-f196.google.com [209.85.214.196]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Tue, 20 Oct 2020 12:13:16 +0000 (UTC) Received: by mail-pl1-f196.google.com with SMTP id bf6so930848plb.4 for ; Tue, 20 Oct 2020 05:13:16 -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=ozLNOPkf0S7L5SxL6HFc1I8U+KuG7maLq27YKTCUYHs=; b=O+WQf8ZsYiZjkr3gEOBjWyzKrfvHEq3aKJ8d9HcKcEKgwvtDihveeQvKbbMu3hjman cTw7hCBlJcu7C8gt2qRH5N8XHLT2MUbL5topuaCSg5nblYfgu4CbnZJi0PLHSWSPgJfT UlxT6i5qsQRfQZKJ4H/Ez4EU1/Uf+RpAcZB3XGKc2oD5vkwR8eM0fQrTVNHVLawTNxme 7CuS8TwisSRK08UErg7+VJYhS4zCt8pLRmlNKvqVyDkqFKmAHRd5ioiKgFVuSYd0XRmu 6TlZz4PKzcnb41ZnSHSmVGq4AWc+xFapaM5UPiYRxWSWSp2ueBdJ8hCV1tFNCmUDrVXK 3FDw== 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=ozLNOPkf0S7L5SxL6HFc1I8U+KuG7maLq27YKTCUYHs=; b=PtxgyxK9FBBJijk2DgEDO1buTNow9OMBJipd3XPpk6kuwjj/6m8v5ZpL15hNW4UoL5 cBKoq6hA7qulBLs+EtSTSRZiCIDGh+iX35XkJZOb1qrV0zLDU+ERPiEIVgiunTI5QmZX Tg/27ZdP9aSx0M4YNEfn1qegwaPqNlPnjS+5PLRWPLFT99Yd14/rxb4nlGfzltbLpWHW DiLfjULuY0Cv5vkq6hcxGj11IWSYmIW+R1M3mSJW5VyGviy50oUXzdrN2vXPINWxI5cs AdkIglc1Byqr2KHy15SKA2xEYOLm9GAOc/mHYseAsWtAkcQyM0e4gHijDyymRk7hP/GF SoYQ== X-Gm-Message-State: AOAM532CUIBO1yG79CUUgmT9XjmvWtT8stZU4kR5uWQK13SUwOykE2ST bQ0GeAI8rV9XE+OyakNfKGPayaDZj0xAw8KGZcTnoQ== X-Google-Smtp-Source: ABdhPJzI7/G68CXv/SFIlGYC2SxZYGtX2T5HcmEbZeWUgH77nTI1fOUrf8QB9k6apPyGNTps1PCNymMBytOuOD4dFCw= X-Received: by 2002:a17:90b:228f:: with SMTP id kx15mr2530393pjb.41.1603195995550; Tue, 20 Oct 2020 05:13:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrey Konovalov Date: Tue, 20 Oct 2020 14:13:04 +0200 Message-ID: Subject: Re: [PATCH RFC 0/8] kasan: hardware tag-based mode for production use on arm64 To: Dmitry Vyukov , Kostya Serebryany Cc: Serban Constantinescu , Catalin Marinas , Will Deacon , Vincenzo Frascino , Alexander Potapenko , Evgenii Stepanov , Andrey Ryabinin , Elena Petrova , Branislav Rankov , Kevin Brodsky , Andrew Morton , kasan-dev , Linux ARM , Linux Memory Management List , LKML , Marco Elver 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 Tue, Oct 20, 2020 at 7:34 AM Dmitry Vyukov wrote: > > On Tue, Oct 20, 2020 at 12:51 AM Kostya Serebryany wrote: > > > > Hi, > > I would like to hear opinions from others in CC on these choices: > > * Production use of In-kernel MTE should be based on stripped-down > > KASAN, or implemented independently? > > Andrey, what are the fundamental consequences of basing MTE on KASAN? > I would assume that there are none as we can change KASAN code and > special case some code paths as necessary. The main consequence is psychological and manifests in inheriting the name :) But generally you're right. As we can change KASAN code, we can do whatever we want, like adding fast paths for MTE, etc. If we Ctrl+C Ctrl+V KASAN common code, we could potentially do some micro optimizations (like avoiding a couple of checks), but I doubt that will make any difference. > > * Should we aim at a single boot-time flag (with several values) or > > for several independent flags (OFF/SYNC/ASYNC, Stack traces on/off) > > We won't be able to answer this question for several years until we > have actual hardware/users... > It's definitely safer to aim at multiple options. I would reuse the fs > opt parsing code as we seem to have lots of potential things to > configure so that we can do: > kasan_options=quarantine=off,fault=panic,trap=async > > I am also always confused by the term "debug" when configuring the > kernel. In some cases it's for debugging of the subsystem (for > developers of KASAN), in some cases it adds additional checks to catch > misuses of the subsystem. in some - it just adds more debugging output > on console. And in this case it's actually neither of these. But I am > not sure what's a better name ("full"?). Even if we split options into > multiple, we still can have some kind of presents that just flip all > other options into reasonable values. OK, let me try to incorporate the feedback I've heard so far into the next version. > > > Andrey, please give us some idea of the CPU and RAM overheads other > > than those coming from MTE > > * stack trace collection and storage > > * adding redzones to every allocation - not strictly needed for MTE, > > but convenient to store the stack trace IDs. > > > > Andrey: with production MTE we should not be using quarantine, which > > means storing the stack trace IDs > > in the deallocated memory doesn't provide good report quality. > > We may need to consider another approach, e.g. the one used in HWASAN > > (separate ring buffer, per thread or per core) My current priority is cleaning up the mode where stack traces are disabled and estimating the slowdown from KASAN callbacks. Once done with that, I'll switch to these ones.