Received: by 2002:ac0:c50a:0:0:0:0:0 with SMTP id y10csp1330528imi; Fri, 1 Jul 2022 07:37:58 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sqlFh7DO1NVbU85vosgcxfLtP4dK1oHV8R5nVNUeHWPUa41cUb9O1LmEQvAo4bC7WG5X7+ X-Received: by 2002:a17:90b:4c0d:b0:1ed:2466:c0d3 with SMTP id na13-20020a17090b4c0d00b001ed2466c0d3mr19207742pjb.6.1656686278659; Fri, 01 Jul 2022 07:37:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656686278; cv=none; d=google.com; s=arc-20160816; b=W/paqk4PTkF0t/zUFTWSZXx1sZlv0UapnWbtYR6y51G60DjpykRkFTNxVYI8PyGJ6X 4AgqAHQPugVrQESAaWPcQHZ3IEHwX5fH2oRgC+lXQ64bmjLlwkVY2qLl9sKpNO7Odo4l yuGTgc4NmliJs9hhdX/0rdQDaE4OOLNRgnPkXfM6gMb32Qlatmxhe+ZJtOTGj7ETxEB+ 9hHRjdJGWQ+Mx317cSruWsD24f7H5ebDCy4RBoBArqdTvohvlUVsNcQPzDi1A2eEF3Y6 F/XEVdBl0dn75dpaSK2rbl+TWOX/JTDgOhHh0GKGK4YIKyTdQwUhIFe0ozcneAFQ4Qja jcPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:references:mime-version :message-id:in-reply-to:date:dkim-signature; bh=l9HW4hvq2CQJApDpi6peUok9IhcNK11lvxcg04+BYhI=; b=jeE+eUHd4Uefqd/0L8kfgqS31zfkIQgi5qtKhYlsS3igh3a7kqxtQo08bu9Gy4M/MH PbaVOwl91xSrRYh9Hmo4Lnybl8qwZ+db3PeyfGPNQw9a0jS0K7OEWVzQlWusDYfQd3lB EkpvG4/MR8jysd+4DT777KmKfsLFos+w4T6HJq+mrr5m8iM4etrcy0yj1kLBobZh2UZp j8YshBuoUvC8O/uI2b733US11ei8OcbGewvkIynKpRtm4cv7umyOj5MWQdmJzEWN9gUb hllH6IAjnH2+Syix/ECDpdjWmi4EcXO6AM8RUK1plUA3GjAdmL2krzBcVNAzHjuvqy64 LlnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=m0zQVBcw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ja21-20020a170902efd500b00161a72f1966si27089917plb.421.2022.07.01.07.37.46; Fri, 01 Jul 2022 07:37:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=m0zQVBcw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231168AbiGAO3y (ORCPT + 99 others); Fri, 1 Jul 2022 10:29:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232944AbiGAO3G (ORCPT ); Fri, 1 Jul 2022 10:29:06 -0400 Received: from mail-wr1-x44a.google.com (mail-wr1-x44a.google.com [IPv6:2a00:1450:4864:20::44a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B847868A12 for ; Fri, 1 Jul 2022 07:25:15 -0700 (PDT) Received: by mail-wr1-x44a.google.com with SMTP id w17-20020a5d6811000000b0021ba89c2e27so421835wru.10 for ; Fri, 01 Jul 2022 07:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:in-reply-to:message-id:mime-version:references:subject:from:to :cc; bh=l9HW4hvq2CQJApDpi6peUok9IhcNK11lvxcg04+BYhI=; b=m0zQVBcwGsjkgBeyzji8njbsYom2zyjvffvZ6f53ygK/a73Sef45vu34Ym/f3GwiY6 24n4n5Tlgq2qKw2wFpgxSipNYxkrLnqPxJkpsZM0TLgQ2V+ISia+unOFzoAz0KadaQq4 AvfYtgG93hXBLXmtu/JrK/Ct51BvQc3+jnECwKhDga5fUg0X6Ao4l5Ye7I/3vzo4ftFo GeOl93a20QvxkwE/6EI17QYzXpZVp27n/+oALgi5SCFfQ+HUJc4i0Oa+cDwovsuOxHTR +8xmXrHToewGWfcV26T9eZU1Ic9Ws7op5A1NuDcoULUqufGrU4oSyUyGYH/L6tZRdLvq YiQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:in-reply-to:message-id:mime-version :references:subject:from:to:cc; bh=l9HW4hvq2CQJApDpi6peUok9IhcNK11lvxcg04+BYhI=; b=GBUWa4GKcONrxg56mn2Qjcd6wePhBkpR4fKrCOY3ybdGeivARd3qFLoJ+M5geLbj2Z 8ReNAetamQSrL0nROgSOxXrDj68/Xrv0uPFChFd9o7pkHyZgXEdt4qIhdLS1MGfp+239 OfkaOauw86NyT0uM3slSz/uBe2X4IgMXMltlTKtPxV43AjbhOvk2Vi1KnrzI/WkS1Rc9 fRuYnwNPU2BHRQOEZ62xpeQs1VWIpzy4/mmGa+QBXuInyTwBw/0o9t2xgPUXJWSEtdKL eDFqepA+hEDM4t4GzKyW19I4jtlMn1enEBs2FpI5lVOzxGiPfcdj+lle0xvVO314fG3k n3/g== X-Gm-Message-State: AJIora/Ki607KcHLfEED4FZD3fUV2OBbn+GnaHAiYzkp56iHvsbdIovf GnZ1B6Dl/2NoA1iLx8yauEneTDd12ws= X-Received: from glider.muc.corp.google.com ([2a00:79e0:9c:201:a6f5:f713:759c:abb6]) (user=glider job=sendgmr) by 2002:a05:6000:10c4:b0:21b:8ea4:a27a with SMTP id b4-20020a05600010c400b0021b8ea4a27amr14086444wrx.575.1656685507805; Fri, 01 Jul 2022 07:25:07 -0700 (PDT) Date: Fri, 1 Jul 2022 16:23:05 +0200 In-Reply-To: <20220701142310.2188015-1-glider@google.com> Message-Id: <20220701142310.2188015-41-glider@google.com> Mime-Version: 1.0 References: <20220701142310.2188015-1-glider@google.com> X-Mailer: git-send-email 2.37.0.rc0.161.g10f37bed90-goog Subject: [PATCH v4 40/45] x86: kmsan: don't instrument stack walking functions From: Alexander Potapenko To: glider@google.com Cc: Alexander Viro , Alexei Starovoitov , Andrew Morton , Andrey Konovalov , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Christoph Hellwig , Christoph Lameter , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Herbert Xu , Ilya Leoshkevich , Ingo Molnar , Jens Axboe , Joonsoo Kim , Kees Cook , Marco Elver , Mark Rutland , Matthew Wilcox , "Michael S. Tsirkin" , Pekka Enberg , Peter Zijlstra , Petr Mladek , Steven Rostedt , Thomas Gleixner , Vasily Gorbik , Vegard Nossum , Vlastimil Babka , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL autolearn=unavailable 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 Upon function exit, KMSAN marks local variables as uninitialized. Further function calls may result in the compiler creating the stack frame where these local variables resided. This results in frame pointers being marked as uninitialized data, which is normally correct, because they are not stack-allocated. However stack unwinding functions are supposed to read and dereference the frame pointers, in which case KMSAN might be reporting uses of uninitialized values. To work around that, we mark update_stack_state(), unwind_next_frame() and show_trace_log_lvl() with __no_kmsan_checks, preventing all KMSAN reports inside those functions and making them return initialized values. Signed-off-by: Alexander Potapenko --- Link: https://linux-review.googlesource.com/id/I7001eaed630277e8d2ddaff1d6f223d54e997a6f --- arch/x86/kernel/dumpstack.c | 6 ++++++ arch/x86/kernel/unwind_frame.c | 11 +++++++++++ 2 files changed, 17 insertions(+) diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c index afae4dd774951..476eb504084e4 100644 --- a/arch/x86/kernel/dumpstack.c +++ b/arch/x86/kernel/dumpstack.c @@ -177,6 +177,12 @@ static void show_regs_if_on_stack(struct stack_info *info, struct pt_regs *regs, } } +/* + * This function reads pointers from the stack and dereferences them. The + * pointers may not have their KMSAN shadow set up properly, which may result + * in false positive reports. Disable instrumentation to avoid those. + */ +__no_kmsan_checks static void show_trace_log_lvl(struct task_struct *task, struct pt_regs *regs, unsigned long *stack, const char *log_lvl) { diff --git a/arch/x86/kernel/unwind_frame.c b/arch/x86/kernel/unwind_frame.c index 8e1c50c86e5db..d8ba93778ae32 100644 --- a/arch/x86/kernel/unwind_frame.c +++ b/arch/x86/kernel/unwind_frame.c @@ -183,6 +183,16 @@ static struct pt_regs *decode_frame_pointer(unsigned long *bp) } #endif +/* + * While walking the stack, KMSAN may stomp on stale locals from other + * functions that were marked as uninitialized upon function exit, and + * now hold the call frame information for the current function (e.g. the frame + * pointer). Because KMSAN does not specifically mark call frames as + * initialized, false positive reports are possible. To prevent such reports, + * we mark the functions scanning the stack (here and below) with + * __no_kmsan_checks. + */ +__no_kmsan_checks static bool update_stack_state(struct unwind_state *state, unsigned long *next_bp) { @@ -250,6 +260,7 @@ static bool update_stack_state(struct unwind_state *state, return true; } +__no_kmsan_checks bool unwind_next_frame(struct unwind_state *state) { struct pt_regs *regs; -- 2.37.0.rc0.161.g10f37bed90-goog