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=-3.7 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 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 9C8F6C433DF for ; Mon, 19 Oct 2020 22:52:39 +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 2DA592225A for ; Mon, 19 Oct 2020 22:52:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="x8yREGyO"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="OC0a2zIS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2DA592225A 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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=UAX376kjzECUqs2q1GPevFXFaB+csDgjiziUB0eT+O0=; b=x8yREGyOKuEtlKg8qN0N3JnR6 WVll5fsn5/5mke3VA4ayuTPYp5o4Nl8nHsS+SIpJlLP2p+JnD/7adzEEnTiGVaBHK9EUielX5Wafv cKCJc+IRMNb8MRVIQ/BT0oEijVqKSTqWQcS4sEWHLpUbxl4sXjRwNXUqBZacVEQHMi9GxbvptvgRN M0G0mMQYppQYo/05m3CzH4ni9bPuND8i3J1hCSu7ok9I6pP+85umfFJ8VQDEbG3YaczUXhzu0q9kG nCIzM9WntLqTNx9z2lbuWMj+HyvaFtmP+OO5+etzaw/17RBgfokPtWB7zJNdp2J/8I+uUaAa0PknM Wg1OYAolQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kUe06-0008Jr-65; Mon, 19 Oct 2020 22:51:34 +0000 Received: from mail-vs1-xe44.google.com ([2607:f8b0:4864:20::e44]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kUe03-0008I6-KL for linux-arm-kernel@lists.infradead.org; Mon, 19 Oct 2020 22:51:32 +0000 Received: by mail-vs1-xe44.google.com with SMTP id b3so880359vsc.5 for ; Mon, 19 Oct 2020 15:51:29 -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=/5knxhq7CVjdPlgBy3BxP03HOY/V3PzThvC7xXq5gGQ=; b=OC0a2zISWY+9Gjsw14nwxC6O3itMVVWDC6aDVg4v2EmgcL/vXSJjZWkYXdUkTzxe8s cAD755MZ57dpMc2y810w9hN4HKdd1mPIEaK+Rhyf+6Icpc56uNmVjdhMx8V3t0ikNEmQ zD6SoncHRrTsQhuUBeiWz7RbQkYnuCzHoyppqlEH8CyBnjJtw9TvmlzrGNyksOi0PHt1 JJOXZ2rwGPjrKcgd6x8agmqX6Ta3X73gLTKwO5nf0H+oyki4Fdli1II52j8lP83hVfh7 s7+tdQlgbc3hhuzBHJL3dnlCc5OZ9mCCSUM9mgxhzSSB8r/CC/cb6lkT5AVZ16Fc4mBA Pfgg== 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=/5knxhq7CVjdPlgBy3BxP03HOY/V3PzThvC7xXq5gGQ=; b=JSfy7Jb+W5hdoTIj+w3yxA0ygNNjJnGbe3wRZEsjPPXhLqIqMaPLcD0AVrwRaGmy2Z q9f0pGQPU7pRpMl++1AottfHFVL9wkY9MG/6jaZ+9YtxnPiPmd71Xi+mNXF5oDleM389 Plyz4jam2cYH7rhX5woC1opl8lGvi/BAxK0/5wkO/JZrEOPixhbSU4E+BNTbw4K+ZhkQ 8jYZKWy8YKYL13H1cDxggB2O0v4ZKxVh3qmhhYiCYs6a03WrE0Cd7uD/p6uNIVKstXKt Grgq/GM4sPvMKiTQjZVpHhzCxTaq5hrMR6BTadGsc1PaYMpkxfbOh1BelrQNrxm/3QEW 6lEA== X-Gm-Message-State: AOAM530wbQ4wFhDZh1cmOC0OajdQb/sZ8GtcS70aYcdYFuS0VhQcqD3A trIW6mnNujmVDkJHlhGqvVPIyINerxgYmfUsuEZIFQ== X-Google-Smtp-Source: ABdhPJy8KN/9grhnwkimwQACJ6SAuvwZovEjixiYVhsLIag8rk3K/bJAZV1lc/Yt7ptOv+azP1Utu40/QynZ3cYAZgw= X-Received: by 2002:a67:ff01:: with SMTP id v1mr26767vsp.10.1603147887388; Mon, 19 Oct 2020 15:51:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kostya Serebryany Date: Mon, 19 Oct 2020 15:51:15 -0700 Message-ID: Subject: Re: [PATCH RFC 0/8] kasan: hardware tag-based mode for production use on arm64 To: Andrey Konovalov X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201019_185131_707322_D89F9BE4 X-CRM114-Status: GOOD ( 31.29 ) 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: Linux ARM , Branislav Rankov , Elena Petrova , Catalin Marinas , Kevin Brodsky , Will Deacon , LKML , kasan-dev , Linux Memory Management List , Alexander Potapenko , Evgenii Stepanov , Serban Constantinescu , Andrey Ryabinin , Andrew Morton , Vincenzo Frascino , Marco Elver , Dmitry Vyukov 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 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? * Should we aim at a single boot-time flag (with several values) or for several independent flags (OFF/SYNC/ASYNC, Stack traces on/off) 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel