Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17E0DC433EF for ; Mon, 20 Dec 2021 14:35:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233698AbhLTOfv (ORCPT ); Mon, 20 Dec 2021 09:35:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58942 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233633AbhLTOfu (ORCPT ); Mon, 20 Dec 2021 09:35:50 -0500 Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 74793C061574 for ; Mon, 20 Dec 2021 06:35:50 -0800 (PST) Received: by mail-qv1-xf34.google.com with SMTP id q3so2099104qvc.7 for ; Mon, 20 Dec 2021 06:35:50 -0800 (PST) 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:content-transfer-encoding; bh=KIUzswcAUaRAOTc8qof1lu1zKeUeUmXtr9MrXGORaeI=; b=DiEjH6My8Ez1IQhVc6pvDrx8DdYBf5P9Q+clTviqtdAcGoyrz8O3Mm0QM1wUFrNkY0 erUGHvnkQdBzOobPRhQhMUs2tWFe8BqPjTGLGO7iDNYJjnvifWvJK0CZAwohnr/jSIgz QpKt+Ew79In897TuLR2zRLivKaLe3tEQEONG8JVkG6PU0InE460sA5jq4dymMlHT8XSX zg2DC/LWEyYpH62+sfMqlCvUH8ljGrMJB9GT5NpPjnlC3IZ7ST16PWtT0L8tFOZmLFjb TIGp0qdZPmp5QBN5QRqIC1GTcIzUBcUI8b5RNxMVY+8vGRJeuba9qlq6VNmEPxlzglI1 v4Rw== 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:content-transfer-encoding; bh=KIUzswcAUaRAOTc8qof1lu1zKeUeUmXtr9MrXGORaeI=; b=HhsuHToFCXEZa+Mh46clZvZZA6Sz6QLelzwHL10N8hYrcf4iVkEPcuwBox7g9z1Vu9 SRf+toCjMoJleg6+rCPLUm+raexwv2UjQrp5pgW8xVrLFmotO4sTpbbunvEe1eNQryPK MFj/58yr6OxlD0YSU7vfkTTX8rc5V/yl+qZbmWhJ+rl8udxDcnC1eiAIN83NY94uICs5 jKT01FsziW1PlBaLfU65FuL2N795Dihokj5mqUwulMwl961hVM//FL591rrYcWtB9p13 l2mz1XXzH3/pZudrziJ9yBA9IsNHim+L/f2iQRNHU4EtIlcAedxSDbh4jWH55oI/6CX3 G+VQ== X-Gm-Message-State: AOAM533qOZMVibYtibSLULIUV1QjHfHJ+8EyxXR4A/zTq2fzxmuccbyE JuPD/cP65DSVj22x35UM2HvKn/Cj/vYKuhE2Rd6pEg== X-Google-Smtp-Source: ABdhPJzaFRZE2AdeTnoG9pfGf1WQwZj1GmAFj8sa8rSd0l4vITphwUpgRq+6SCv0VHaU8fAW9eiqASykEX99MrCy/vM= X-Received: by 2002:a0c:8031:: with SMTP id 46mr13207207qva.126.1640010949396; Mon, 20 Dec 2021 06:35:49 -0800 (PST) MIME-Version: 1.0 References: <20211214162050.660953-1-glider@google.com> <20211214162050.660953-40-glider@google.com> <87bl1ec32a.ffs@tglx> In-Reply-To: <87bl1ec32a.ffs@tglx> From: Alexander Potapenko Date: Mon, 20 Dec 2021 15:35:13 +0100 Message-ID: Subject: Re: [PATCH 39/43] x86: kmsan: handle register passing from uninstrumented code To: Thomas Gleixner Cc: Alexander Viro , Andrew Morton , Andrey Konovalov , Andy Lutomirski , Ard Biesheuvel , 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 , Matthew Wilcox , "Michael S. Tsirkin" , Pekka Enberg , Peter Zijlstra , Petr Mladek , Steven Rostedt , Vasily Gorbik , Vegard Nossum , Vlastimil Babka , Linux Memory Management List , Linux-Arch , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 17, 2021 at 10:51 PM Thomas Gleixner wrote= : > > Alexander, > > On Tue, Dec 14 2021 at 17:20, Alexander Potapenko wrote: > > When calling KMSAN-instrumented functions from non-instrumented > > functions, function parameters may not be initialized properly, leading > > to false positive reports. In particular, this happens all the time whe= n > > calling interrupt handlers from `noinstr` IDT entries. > > > > Fortunately, x86 code has instrumentation_begin() and > > It's not only x86 code: > > kernel/entry/common.c | 3 +++ Shall this bit go into a separate patch? > > @@ -76,6 +77,7 @@ __visible noinstr void do_syscall_64(struct pt_regs *= regs, int nr) > > nr =3D syscall_enter_from_user_mode(regs, nr); > > > > instrumentation_begin(); > > + kmsan_instrumentation_begin(regs); > > Can we please make this something like: > > instrumentation_begin_at_entry(regs); Fine, will do. Do you think it would make sense to hide it inside instrumentation_begin(), or is it ok to have both macros follow each other? > or some other sensible name which hides that kmsan gunk and avoids to > touch all of this again when KFOOSAN comes around? > > Thanks, > > tglx > > > --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg