Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp5614906pxb; Mon, 28 Mar 2022 15:00:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyn8og83vjg+q9I1PrUpjI0kFPzFL1UAjpY0H6+BeiYD2x38Le9BonYFkOeUkQIg9jFguRT X-Received: by 2002:a05:6a00:179f:b0:4fa:ecc3:a6ea with SMTP id s31-20020a056a00179f00b004faecc3a6eamr23877173pfg.82.1648504840786; Mon, 28 Mar 2022 15:00:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648504840; cv=none; d=google.com; s=arc-20160816; b=tfs53F8nQKtoAAV6uouetnxsDK5O6W0Rai2M9k+1GwRoqDYeJj5ICXUogOsM5vcOJp SNutBUS4cp+Mm9i5615BoksXAQX98WYZUQ7so4e49LV+vJShepu5CG0unzF8DJIshBBH +wRopjGk5uiJhPgm+XJHQhxf9nU7sv4bWiZzvbkYypg73Q1KCAM5+7YDaY80UiY89x7k +MsILh2+8HucF+f6vQOmrwVEdQfMzss7IyMwmmX2PhtYKhMish0FWgcfo3zjehsGk012 UAv8oqaXtHEezdCzhBHsJMOS0iBVbEW6No/PoZaZNwO7CKMXIGf/1nVzw8vExp4GsLbi aYTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=uMEZK2jSyKIkvvjIbH4GT3Fdajafv9KYrdFViGd4yCs=; b=ZE4H/ssv1VKFuLVUrGXP0apWboMq3/qnuo+qOsCDig5SUJHyZ+GudiPSTr+FItozxw f+95e6AasyRju9C1i7znSK6Jz5r2UBMhvrgejWp6bXz2v3dbfF/qBs+Q/BaC1GP8AQeu HUhpY2/Hr75MWGALlnAKm5tinW7r4QfjLHh3jdD4+SD1Rrh9rUy+dqzILekSiDJ4GI7V 77VaytqKZNciSE+eh1UfPlVLPHrBPcie7Qk7O6ymP/Pv50paoC6fmr6IJUrGh4617Drk Dh2erewL6Z1+BYQynaSU5V4RmJvvJLZeWA7aZ/90aLVZVmIuAPVF9qv3zetrhuHyeFRC at8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=E9+QQkZM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id 13-20020aa7920d000000b004fa3a8e0005si13416163pfo.188.2022.03.28.15.00.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Mar 2022 15:00:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=E9+QQkZM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A045D13AA03; Mon, 28 Mar 2022 14:26:16 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242566AbiC1Mim (ORCPT + 99 others); Mon, 28 Mar 2022 08:38:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53642 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239356AbiC1Mik (ORCPT ); Mon, 28 Mar 2022 08:38:40 -0400 Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C69254ECC9 for ; Mon, 28 Mar 2022 05:36:59 -0700 (PDT) Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-2e612af95e3so146670877b3.9 for ; Mon, 28 Mar 2022 05:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uMEZK2jSyKIkvvjIbH4GT3Fdajafv9KYrdFViGd4yCs=; b=E9+QQkZMHaB3kC1jUcU1jKceyPqYXHgBAwrVH0Qoo7sy3RqybcW+gUMd6ILGzB7f+l ws3VHba8umN32ny6nvOGE7S0/BDPYbL3CibIFNlYrI+ImbMRn5uBNTtYcvWjpMn70BeQ YSZHLatfVPFPqrYmESblO10IJea6qXAQwCHfSeIe/Um9EbObWu/lemX2KJ23uLSz97eH g6on/oQ6sD9DD5h9J/mHKHD3CEJ6mjGQwCKzXS6Oo18j1nmsU3d9qcw+HawWBiquerkd 1uGdCrnf3Y0q0XTNc1w9PPJSTSY6BhV6JhFKAinQ4KUVPbxqYrV3ctxarnAfrHwnZlJo D6Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uMEZK2jSyKIkvvjIbH4GT3Fdajafv9KYrdFViGd4yCs=; b=HCmt2dCST3p3r3bPbV0ZLth+J6TKrqy3c0O08LJeHd0CI1Ke5wbQzk8DBPWVmRhOnH RF/4TbluuQ9kAknZbfiIqIn/+LifmhZhhcCpoYUy+nbaXwWfp0S4+RSyXIGHC9TaZ5Xl hj68bb6W50E2rHxVMTznYxbLhgki5qPpVnRV9DMTSAKux9lJwSyIxu8gnhpefqvOSJAM 2AjhyN6oageWG09u3KvBqQJz0V8bww9+g9i0NsCK9Luxtrap1ZnKTOt7eVsyTIxd/Yls HKPGsjksu6Pl03n+BvF/mdotX8hehgM5CklHCKD5JzZ37bIDl9NWnmYtizCWsdeoLMZW FJGA== X-Gm-Message-State: AOAM531lWyvj1dzs0eI18gSmhxlPstyKdHCEX6ZYdF/UhZMMfZxndH2g FKg/f6OUEZf248Bful6AukJNenxQUKO4s08Xvoljx67OXg4= X-Received: by 2002:a81:59c4:0:b0:2e5:c7c3:5d29 with SMTP id n187-20020a8159c4000000b002e5c7c35d29mr25403537ywb.512.1648471018879; Mon, 28 Mar 2022 05:36:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Marco Elver Date: Mon, 28 Mar 2022 14:36:22 +0200 Message-ID: Subject: Re: [PATCH v2 0/4] kasan, arm64, scs, stacktrace: collect stack traces from Shadow Call Stack To: andrey.konovalov@linux.dev Cc: Alexander Potapenko , Catalin Marinas , Will Deacon , Andrew Morton , Andrey Konovalov , Dmitry Vyukov , Andrey Ryabinin , kasan-dev@googlegroups.com, Mark Rutland , Vincenzo Frascino , Sami Tolvanen , Peter Collingbourne , Evgenii Stepanov , Florian Mayer , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 23 Mar 2022 at 16:33, wrote: > > From: Andrey Konovalov > > kasan, arm64, scs, stacktrace: collect stack traces from Shadow Call Stack > > Currently, KASAN always uses the normal stack trace collection routines, > which rely on the unwinder, when saving alloc and free stack traces. > > Instead of invoking the unwinder, collect the stack trace by copying > frames from the Shadow Call Stack whenever it is enabled. This reduces > boot time by 30% for all KASAN modes when Shadow Call Stack is enabled. > > Stack staces are collected from the Shadow Call Stack via a new > stack_trace_save_shadow() interface. > > Note that the frame of the interrupted function is not included into > the stack trace, as it is not yet saved on the SCS when an interrupt > happens. > > --- > > To deal with this last thing, we could save the interrupted frame address > in another per-CPU variable. I'll look into implementing this for v3. > > I decided to postpone the changes to stack depot that avoid copying > frames twice until a planned upcoming update for stack depot. That's fair. > Changes v1->v2: > - Provide a kernel-wide stack_trace_save_shadow() interface for collecting > stack traces from shadow stack. > - Use ptrauth_strip_insn_pac() and READ_ONCE_NOCHECK, see the comments. > - Get SCS pointer from x18, as per-task value is meant to save the SCS > value on CPU switches. > - Collect stack frames from SDEI and IRQ contexts. Do any of these new changes introduce new (noticeable) overhead (in particular patch 2)?