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.3 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 6B5FCC43457 for ; Tue, 20 Oct 2020 05:34:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 894312225F for ; Tue, 20 Oct 2020 05:34:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="lSWQdfR8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 894312225F 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 80FF26B005C; Tue, 20 Oct 2020 01:34:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C0A16B0062; Tue, 20 Oct 2020 01:34:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6AE756B0068; Tue, 20 Oct 2020 01:34:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3F5446B005C for ; Tue, 20 Oct 2020 01:34:56 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id CC84D181AEF07 for ; Tue, 20 Oct 2020 05:34:55 +0000 (UTC) X-FDA: 77391189750.19.scale63_1102d2d2723d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id A9A8A1AD1B7 for ; Tue, 20 Oct 2020 05:34:55 +0000 (UTC) X-HE-Tag: scale63_1102d2d2723d X-Filterd-Recvd-Size: 7882 Received: from mail-qk1-f195.google.com (mail-qk1-f195.google.com [209.85.222.195]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Tue, 20 Oct 2020 05:34:55 +0000 (UTC) Received: by mail-qk1-f195.google.com with SMTP id i22so574834qkn.9 for ; Mon, 19 Oct 2020 22:34:55 -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=s42cP9f/U3GYa0s71Z6i/ug0NaSJrPca2FKEkcjzEig=; b=lSWQdfR8gb//jvhTXD7ptWiD8DJJy+QjL933HmhsYV5USe+0wW1O06ws9f29EgM4qL dXTXghMazo5HR5hrNNZN0QWad7fuv72ijxZHgGM4dhb94NpKt5BG+UDw9dxDPm5isHbK VzWtr8QDDpaeXy1lNNL4aUltU0UEbqzZliXwaJmphUu/0jLamQtspESFhrUD3zPkGlFk 7cKt2+0fes/lHWCcEVHjigO/OxF/2686l62/e9GcR3cjXVrMgDBwfIIVJ6uZAUeEadRg 1icRhPP7aCKcIkcd6JlHEEsxQjcpF6+wjzjTcuremLItAP6IkJOKWRwmFP8Raik0rnnU gOnA== 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=s42cP9f/U3GYa0s71Z6i/ug0NaSJrPca2FKEkcjzEig=; b=MZyEK9kZrKw+RkY387ywtOW9HE/U8xGiKqRmAj+jNtXHzZeIWHGQOqgKZ2EOzGOBLi yyYMxl52NUmMinogr4YnjxuWPtUSmvqfy7QzUIFmYKyOUzp8mTxkk6NuCmdmXRyjINc8 VEiekRJm8plhiksrg/miBNt3uVEhKkKIi2o3lI6w1oRJuOiZtnOP4tC8tDMhbQxz1eJf QOOikW7f092OJfuyosgXsu6Yd7iAfd3X+eFHSk0+8SgxN93R33z4o+Gmkhmx+lIQKTQn 4SEv1ymjx0F+P1SF+C7QTKg9w3z2kwNP02fg+NpCX6J6xyxgbhLsbcstHqrm+8nQ2m9b Z6Cg== X-Gm-Message-State: AOAM531fdoRDEI6T0SpqVkebZtnKGJs9/Re6x6vkDZcewpdSbv2+S2Gg l9jltc20TzEwDtf2Wv5CgidnN0EbojqiD3PPNokjkQ== X-Google-Smtp-Source: ABdhPJxM6S0zXSmPa4/to/wlbV3NpOmdBumwfTp0AnsNgLnkahAjzxKwoC9YKJyhHRzuqbhFDQbCn/SvoNJd4p45X6c= X-Received: by 2002:a05:620a:1657:: with SMTP id c23mr1269155qko.231.1603172094152; Mon, 19 Oct 2020 22:34:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dmitry Vyukov Date: Tue, 20 Oct 2020 07:34:42 +0200 Message-ID: Subject: Re: [PATCH RFC 0/8] kasan: hardware tag-based mode for production use on arm64 To: Kostya Serebryany Cc: Andrey Konovalov , 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 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. > * 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. > 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) > > --kcc > > > On Fri, Oct 16, 2020 at 8:52 AM Andrey Konovalov wrote: > > > > On Fri, Oct 16, 2020 at 3:31 PM Marco Elver wrote: > > > > > > On Fri, 16 Oct 2020 at 15:17, 'Andrey Konovalov' via kasan-dev > > > wrote: > > > [...] > > > > > > The intention with this kind of a high level switch is to hide the > > > > > > implementation details. Arguably, we could add multiple switches that allow > > > > > > to separately control each KASAN or MTE feature, but I'm not sure there's > > > > > > much value in that. > > > > > > > > > > > > Does this make sense? Any preference regarding the name of the parameter > > > > > > and its values? > > > > > > > > > > KASAN itself used to be a debugging tool only. So introducing an "on" > > > > > mode which no longer follows this convention may be confusing. > > > > > > > > Yeah, perhaps "on" is not the best name here. > > > > > > > > > Instead, maybe the following might be less confusing: > > > > > > > > > > "full" - current "debug", normal KASAN, all debugging help available. > > > > > "opt" - current "on", optimized mode for production. > > > > > > > > How about "prod" here? > > > > > > SGTM. > > > > > > [...] > > > > > > > > > > Should we somehow control whether to panic the kernel on a tag fault? > > > > > > Another boot time parameter perhaps? > > > > > > > > > > It already respects panic_on_warn, correct? > > > > > > > > Yes, but Android is unlikely to enable panic_on_warn as they have > > > > warnings happening all over. AFAIR Pixel 3/4 kernels actually have a > > > > custom patch that enables kernel panic for KASAN crashes specifically > > > > (even though they don't obviously use KASAN in production), and I > > > > think it's better to provide a similar facility upstream. Maybe call > > > > it panic_on_kasan or something? > > > > > > Best would be if kasan= can take another option, e.g. > > > "kasan=prod,panic". I think you can change the strcmp() to a > > > str_has_prefix() for the checks for full/prod/on/off, and then check > > > if what comes after it is ",panic". > > > > > > Thanks, > > > -- Marco > > > > CC Kostya and Serban.