Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp944809rwn; Thu, 15 Sep 2022 08:22:36 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6Duo9yKJh9Lh3nWLV6TQZ07MuBQxZmAuXO381JG4yR7Gif1SxveWp5MuAmMsZ+ndYlXJU9 X-Received: by 2002:aa7:c458:0:b0:44e:9078:5712 with SMTP id n24-20020aa7c458000000b0044e90785712mr336260edr.25.1663255356731; Thu, 15 Sep 2022 08:22:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663255356; cv=none; d=google.com; s=arc-20160816; b=HmMS/WFNzQe3gqMDlsn+GyD3Y8Xzet5OkvamQr7/S3KY836ksJqU4VOZywDJ1FrP9O pqH+1eLgYCJU5LUv9Ud8r+edv4BDT98vsVK6vuYjFyiMpuEfVNDo38DucntY72am3Htm XpdOskZ3A5nbYGrTf7dIKBFCkN4DK1AgqbGRnioGTa0j1AsEF8S20cgV51hPaviva+7C mKkBJWO+wJEATFQFVsoO/NdclPul4lqQTrUWFHzsIRggyvWvvZ3OfhDh+/JudcEMlvxD xjdg2ktURj7hQ4Vrc6//h1wpoxDyU+7GaxKdIGMOUR0ohfn4LEuCswbKq//R74fycTHt X8Eg== 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:message-id:references :mime-version:in-reply-to:date:dkim-signature; bh=Rbxz0iuc7RXxWgIfjeSrHOuiWEHvXH2VAJuclXEfLdg=; b=aBzuXgy7JpvTm5LPvPwjk3VJ28ubs6uheURIjaQEasnUZqig9MMqn6eX9+MTNdTEJs CTU+vfiGiyoaS9ZUJSYbU9UGriJL5f5vd8XWTOaqt+AwEpCjUdPvBnzQ5L5kDPrYIk8N nMncmCSUFgkfRoKJfir+U8H1gnYtJaW+Q3rLAq/7AbwCAW9OekiH9fqFa7SKYbEtPNR1 sDoMkUC3HAlOQzBkIDbiykKCczAhasLcqvpmukhIXwM78+9tA7viKC3to97KmZrwTy29 pYirsjP0ifn0Iod8B02KJb5yG2wqawtR5YW65O3OhWfZ/nFruM8iR6dsZoIamasVOTGs stPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=F6VwgljK; 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 m21-20020a1709062b9500b007707edd5487si12187499ejg.947.2022.09.15.08.22.10; Thu, 15 Sep 2022 08:22:36 -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=F6VwgljK; 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 S231224AbiIOPMR (ORCPT + 99 others); Thu, 15 Sep 2022 11:12:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231138AbiIOPKZ (ORCPT ); Thu, 15 Sep 2022 11:10:25 -0400 Received: from mail-ej1-x64a.google.com (mail-ej1-x64a.google.com [IPv6:2a00:1450:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8267D9E112 for ; Thu, 15 Sep 2022 08:06:26 -0700 (PDT) Received: by mail-ej1-x64a.google.com with SMTP id qf40-20020a1709077f2800b0077b43f8b94cso6164828ejc.23 for ; Thu, 15 Sep 2022 08:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date; bh=Rbxz0iuc7RXxWgIfjeSrHOuiWEHvXH2VAJuclXEfLdg=; b=F6VwgljKSoHlmWj1nWyCtFBHI2b5B8DMZ6H1olBVWsiyfT2kbw7W/bawpY6tA8zayB THwH3bKPewMxmxrhbJdq+mZdumidYxMIcUtzSGYEkAasnxQOXeSE7IjjawVZVIn2zcXQ r1YsO97BGqmMH/3Gm3SPgEFLbDSNRdcBrXoh3uNQ2BkTLA6uRpOGDFXhN9pCl9ZI7NBZ xhhcFg1UVJA4C2HyIq9LT8Fw+KPyPlGxH/UCui6KY5gucTlsnsRb7V38I53MLrTmhqTr tJkPsqtR6gQh2kMAprFeLbJIRRB1FXqX6TCmSGetbahnUDYy2pQaPR875kzYJHfpMY4q Y0EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date; bh=Rbxz0iuc7RXxWgIfjeSrHOuiWEHvXH2VAJuclXEfLdg=; b=WXVWvxm8HezAHWymvQok/AV57hov7EdscXRdMpZJZ4Shbx9yssmIWfo4Y0OcNQLZRZ 6Zkj3d6wdLEBFMDwGrOh5vH5obCvFzUGhfcqx6CIfX2VJJYEVGekFrpmN1C3vLgrMq9f NuFFtKQXJ+dqwG7lK9v1yjEIUZWe18Wl3mwIKs1Fvpps8JNwQ9ZB+Jp0Dqpaox+olKxI D2AIAIhi3Ws2SwesZ122wQKyoLenaT/Q5ecoREMV+xN9kD5N3C+1UBSYfjn6Zl4v3PHE S9i9VEaEW2Md5uslmc/mA/xWxHYiV67WcnLo/Gy+rOfpcioKtlLf0gHiskcinSuU+4PA kSnQ== X-Gm-Message-State: ACrzQf0CuPPF6QTQ3p5I/06oD8xZk7syCFs7rbqugB9SepWbFUehszKR +xkpDA/Ss03xbb5YhT5vIdqj69N9NxQ= X-Received: from glider.muc.corp.google.com ([2a00:79e0:9c:201:686d:27b5:495:85b7]) (user=glider job=sendgmr) by 2002:a05:6402:270f:b0:451:b5bd:95dd with SMTP id y15-20020a056402270f00b00451b5bd95ddmr251653edd.215.1663254384829; Thu, 15 Sep 2022 08:06:24 -0700 (PDT) Date: Thu, 15 Sep 2022 17:04:13 +0200 In-Reply-To: <20220915150417.722975-1-glider@google.com> Mime-Version: 1.0 References: <20220915150417.722975-1-glider@google.com> X-Mailer: git-send-email 2.37.2.789.g6183377224-goog Message-ID: <20220915150417.722975-40-glider@google.com> Subject: [PATCH v7 39/43] 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 Biggers , 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 , Stephen Rothwell , 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,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/I6550563768fbb08aa60b2a96803675dcba93d802 --- 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.2.789.g6183377224-goog