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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3202AC433EF for ; Mon, 9 May 2022 16:51:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8AFD26B0072; Mon, 9 May 2022 12:51:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 85D6C6B0073; Mon, 9 May 2022 12:51:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D6AB6B0074; Mon, 9 May 2022 12:51:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 5B1CD6B0072 for ; Mon, 9 May 2022 12:51:23 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 28C986132C for ; Mon, 9 May 2022 16:51:23 +0000 (UTC) X-FDA: 79446795246.26.38E37AA Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) by imf16.hostedemail.com (Postfix) with ESMTP id 71E5A1800B1 for ; Mon, 9 May 2022 16:51:14 +0000 (UTC) Received: by mail-yb1-f173.google.com with SMTP id y76so26069081ybe.1 for ; Mon, 09 May 2022 09:51:22 -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:content-transfer-encoding; bh=xv3YNr+ejtNXLt/3K/MJW1lmyFr4+HmU5M46knKl15A=; b=qzQQBeDIXPjgQg9o0N4Qf/md5IkN/vOjVl6fC5GVKpgiXu3VqQ/t2/oS949Ye1D/MP UoEvD6TzcTAbTEOWhMRa72QRymRlxd44YwrhzjfcdgXzCga+Om3dMx9Y+OSJQt5zRCw3 +MuxBTB3B0MvvcOO0cZ1OiXpyzKXU1QlXZmnNuwPOI1GJaPuCVDT73Opv7ihk/0krrY8 BC/rUoXJHVUJJXttPpWAOFWYLUYLpxOIpnTQzxAPE29v1qLwJyg8jx4Uj7aiUyLR7b7x g9MPBOkAhKiTuw3GTexW2rDM44fgqYj3KRXhFl+BHrBm7Llo4mUKfe4O72BYjWNiD5xd TPVQ== 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=xv3YNr+ejtNXLt/3K/MJW1lmyFr4+HmU5M46knKl15A=; b=Ugg2cGxSN7F8DhWgN+pp8KeWWgHLhsDPBU8O6CZ1xGVvEvlD5PK4Hi6cukjuzf+zA2 ysxmX0Oi4mrVA6DTqlxq05KA88EYIdgovT1aj1ToKBWGT25EqIVxeb1VDOdqEVzBNK8x KS4nJw9zPVrmdci0E5I8IaYrwJacvgRIsjqYp7NVP4WzIq7dBE0uCuWE6AqSQ1BBhidD Vnc5cIXOSryCHLlK9e/7yTr8af8UPWY5IkynKWGnRju+MICV5JoPRz9DNlPYB8FWHOwN h4QRyX0XDQJpbhYTNqlEo1ko+S9J04JOYlZr9k5+lgPD4T2yHqlPoh7Iyx6j1vDkLFDg n7Eg== X-Gm-Message-State: AOAM533FJzPtHgI+u4G+gz/xFGm76trbhDM727naWeK+J8ZHwuGYoBuf VPzWdhsOBQMCSnQ5EQrK0cU3SvdnqXHkVUC4Q2pM5g== X-Google-Smtp-Source: ABdhPJxk2axP91QTV5WMMRiQcamRUJ0YhF0xRNVwcidsKN1FnuaSRI3NRg0kFbpLTrCWH32z8BDTWymGCd3ivXwMIZE= X-Received: by 2002:a25:aa62:0:b0:648:590f:5a53 with SMTP id s89-20020a25aa62000000b00648590f5a53mr14674322ybi.5.1652115081586; Mon, 09 May 2022 09:51:21 -0700 (PDT) MIME-Version: 1.0 References: <20220426164315.625149-1-glider@google.com> <20220426164315.625149-29-glider@google.com> <87a6c6y7mg.ffs@tglx> <87y1zjlhmj.ffs@tglx> <878rrfiqyr.ffs@tglx> <87k0ayhc43.ffs@tglx> <87h762h5c2.ffs@tglx> In-Reply-To: <87h762h5c2.ffs@tglx> From: Alexander Potapenko Date: Mon, 9 May 2022 18:50:45 +0200 Message-ID: Subject: Re: [PATCH v3 28/46] kmsan: entry: handle register passing from uninstrumented code To: Thomas Gleixner Cc: Alexander Viro , 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 , Vasily Gorbik , Vegard Nossum , Vlastimil Babka , kasan-dev , Linux Memory Management List , Linux-Arch , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 71E5A1800B1 X-Stat-Signature: y6f98nbdmy89iedb7ms4xqorrzcfebjq Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=qzQQBeDI; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of glider@google.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=glider@google.com X-Rspam-User: X-HE-Tag: 1652115074-592344 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > The callchain is: > > asm_sysvec_apic_timer_interrupt <- ASM entry in gate > sysvec_apic_timer_interrupt(regs) <- noinstr C entry point > irqentry_enter(regs) <- unpoisons @reg > __sysvec_apic_timer_interrupt(regs) <- the actual handler > set_irq_regs(regs) <- stores regs > local_apic_timer_interrupt() > ... > tick_handler() <- One of the 4 variants > regs =3D get_irq_regs(); <- retrieves regs > update_process_times(user_tick =3D user_mode(regs)) > account_process_tick(user_tick) > irqtime_account_process_tick(user_tick) > line 382: } else if { user_tick } <- KMSAN complains > > I'm even more confused now. Ok, I think I know what's going on. Indeed, calling kmsan_unpoison_memory() in irqentry_enter() was supposed to be enough, but we have code in kmsan_unpoison_memory() (as well as other runtime functions) that checks for kmsan_in_runtime() and bails out to prevent potential recursion if KMSAN code starts calling itself. kmsan_in_runtime() is implemented as follows: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D static __always_inline bool kmsan_in_runtime(void) { if ((hardirq_count() >> HARDIRQ_SHIFT) > 1) return true; return kmsan_get_context()->kmsan_in_runtime; } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (see the code here: https://lore.kernel.org/lkml/20220426164315.625149-13-glider@google.com/#Z3= 1mm:kmsan:kmsan.h) If we are running in the task context (in_task()=3D=3Dtrue), kmsan_get_context() returns a per-task `struct *kmsan_ctx`. If `in_task()=3D=3Dfalse` and `hardirq_count()>>HARDIRQ_SHIFT=3D=3D1`, it returns a per-CPU one. Otherwise kmsan_in_runtime() is considered true to avoid dealing with nested interrupts. So in the case when `hardirq_count()>>HARDIRQ_SHIFT` is greater than 1, kmsan_in_runtime() becomes a no-op, which leads to false positives. The solution I currently have in mind is to provide a specialized version of kmsan_unpoison_memory() for entry.c, which will not perform the reentrancy checks. > > I guess handling those will require wrapping every interrupt gate into > > a function that performs register unpoisoning? > > No, guessing does not help here. > > The gates point to the ASM entry point, which then invokes the C entry > point. All C entry points use a DEFINE_IDTENTRY variant. Thanks for the explanation. I previously thought there were two different entry points, one with asm_ and one without, that ended up calling the same code. > Some of the DEFINE_IDTENTRY_* C entry points are not doing anything in > the macro, but the C function either invokes irqentry_enter() or > irqentry_nmi_enter() open coded _before_ invoking any instrumentable > function. So the unpoisoning of @regs in these functions should tell > KMSAN that @regs or something derived from @regs are not some random > uninitialized values. > > There should be no difference between unpoisoning @regs in > irqentry_enter() or in set_irq_regs(), right? > > If so, then the problem is definitely _not_ the idt entry code. > > > By the way, if it helps, I think we don't necessarily have to call > > kmsan_unpoison_memory() from within the > > instrumentation_begin()/instrumentation_end() region? > > We could move the call to the beginning of irqentry_enter(), removing > > unnecessary duplication. > > We could, but then you need to mark unpoison_memory() noinstr too and you > have to add the unpoison into the syscall code. No win and irrelevant to > the problem at hand. Makes sense, thank you! > 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, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Diese E-Mail ist vertraulich. Falls Sie diese f=C3=A4lschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, l=C3=B6schen Sie alle Kopien und Anh=C3=A4nge davon und lassen Sie = mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.