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 1192AC433EF for ; Wed, 1 Jun 2022 11:28:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8FA3B8D000A; Wed, 1 Jun 2022 07:28:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A5128D0006; Wed, 1 Jun 2022 07:28:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7968A8D000A; Wed, 1 Jun 2022 07:28:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 6B21F8D0006 for ; Wed, 1 Jun 2022 07:28:35 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3A28520A04 for ; Wed, 1 Jun 2022 11:28:35 +0000 (UTC) X-FDA: 79529444190.27.DB0A1AA Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) by imf06.hostedemail.com (Postfix) with ESMTP id F389018004D for ; Wed, 1 Jun 2022 11:28:30 +0000 (UTC) Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-30ce6492a60so14838937b3.8 for ; Wed, 01 Jun 2022 04:28:34 -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=tDA6PuH6NICvxSpkxUN08aIv7E1lLbWtwbYMOmp3DFc=; b=qZ4wk7dYHXk+svmWhmtwD5F01nOrHanF/nZcd2rNt/sATC0umgD7nFxlyirkk7t7yt /5NSe+GKx657K37eu29ixICiLnZ+U5EhmxLGckjho8BnQPOSc1PytOmMl6dueOaOkRfp DK5IdYHqNZRD8IyzEHTH+X04qE9G9cXrdrwM7Gd2ldpCMdWe/bhKK0FJ+oJcIm+1NXnd 1c5MqLPnhnJ3tz9ErQexOBcfjZPLSbQweY61tDKiErca+u+a4dbYtfvmsF3W9dTrjtkf 9GPnypBdkQvxxu/eYpcMAJS42Y+VITDDdkbpWf4+uiNiaR6Na/D7SpKNUJAX1i+IgkSv VNvA== 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=tDA6PuH6NICvxSpkxUN08aIv7E1lLbWtwbYMOmp3DFc=; b=IELydZ7e8Z7WRq+f2qAXn0dnTQKS7MT7jbGLWiiaWikvsayr5/F7rDE2SW6LdH03uj MTS+N0O3twh9KiQKVOJTcRLPFPOkqUfO6GRq+npD/yoNFR+gxBpjdPMlB4z64BLM+6Xi pPYrscdpwYsF4evdy+wPkwJJeLhcgXv3zN0E/UOUCcxW1+EHVYg0u2QXuVT4x3R8KQ0U Wb++0eLmdgIn+gVwFakwUqt2MxBjvRAvyUNWENyqsg9lYQEtXXadEoI+kq7T6bEHcL/J fbm6WJ41mWztK+e2wdGbKFY0ovvg20KPodGJVfpCa/9gAlBed2KlXR+eL1AoTZdWTqyI 5eIw== X-Gm-Message-State: AOAM531Vjy0qwr2eJa930RFRV6+B/+Tot7ELi2yaLnneoLlJG9nbSbpq nq/1bzMnavkjxebIMCDE072bP/L7zPNDzJCUrVXOMg== X-Google-Smtp-Source: ABdhPJyo22i6mb4t9rd8RWOXkFixboX4VLMr4JB+/qGQCmpcDVlUNjyMNUrEjFthhS3/evNm77t2vXH8qRIY3ppOfOY= X-Received: by 2002:a81:1f8b:0:b0:2f8:5846:445e with SMTP id f133-20020a811f8b000000b002f85846445emr69247959ywf.50.1654082912126; Wed, 01 Jun 2022 04:28:32 -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> <871qx2r09k.ffs@tglx> <87h75uvi7s.ffs@tglx> <87ee0yvgrd.ffs@tglx> In-Reply-To: <87ee0yvgrd.ffs@tglx> From: Alexander Potapenko Date: Wed, 1 Jun 2022 13:27:56 +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" X-Stat-Signature: thezbds3b3p5awkko8iqyy5thnkjzkin Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=qZ4wk7dY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of glider@google.com designates 209.85.128.174 as permitted sender) smtp.mailfrom=glider@google.com X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: F389018004D X-HE-Tag: 1654082910-105382 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: On Thu, May 12, 2022 at 6:48 PM Thomas Gleixner wrote: > > On Thu, May 12 2022 at 18:17, Thomas Gleixner wrote: > > On Thu, May 12 2022 at 14:24, Alexander Potapenko wrote: > >> We could try to figure out the places in idtentry code where normal > >> kmsan_unpoison_memory() can be called in IRQ context, but as far as I > >> can see it will depend on the type of the entry point. > > > > NMI is covered as it increments before it invokes the unpoison(). > > > > Let me figure out why we increment the preempt count late for > > interrupts. IIRC it's for symmetry reasons related to softirq processing > > on return, but let me double check. > > It's even documented: > > https://www.kernel.org/doc/html/latest/core-api/entry.html#interrupts-and-regular-exceptions > > But who reads documentation? :) > > So, I think the simplest and least intrusive solution is to have special > purpose unpoison functions. See the patch below for illustration. This patch works well and I am going to adopt it for my series. But the problem with occasional calls of instrumented functions from noinstr still persists: if there is a noinstr function foo() and an instrumented function bar() called from foo() with one or more arguments, bar() must wipe its kmsan_context_state before using the arguments. I have a solution for this problem described in https://reviews.llvm.org/D126385 The plan is to pass __builtin_return_address(0) to __msan_get_context_state_caller() at the beginning of each instrumented function. Then KMSAN runtime can check the passed return address and wipe the context if it belongs to the .noinstr code section. Alternatively, we could employ MSan's -fsanitize-memory-param-retval flag, that will report supplying uninitialized parameters when calling functions. Doing so is currently allowed in the kernel, but Clang aggressively applies the noundef attribute (see https://llvm.org/docs/LangRef.html) to function arguments, which effectively makes passing uninit values as function parameters an UB. So if we make KMSAN detect such cases as well, we can ultimately get rid of all cases when uninits are passed to functions. As a result, kmsan_context_state will become unnecessary, because it will never contain nonzero values. > The reasons why I used specific ones: > > 1) User entry > > Whether that's a syscall or interrupt/exception does not > matter. It's always on the task stack and your machinery cannot be > running at that point because it came from user space. > > 2) Interrupt/exception/NMI entry kernel > > Those can nest into an already active context, so you really want > to unpoison @regs. > > Also while regular interrupts cannot nest because of interrupts > staying disabled, exceptions triggered in the interrupt handler and > NMIs can nest. > > -> device interrupt() > irqentry_enter(regs) > > -> NMI() > irqentry_nmi_enter(regs) > > -> fault() > irqentry_enter(regs) > > --> debug_exception() > irqentry_nmi_enter(regs) > > Soft interrupt processing on return from interrupt makes it more > interesting: > > interrupt() > handler() > do_softirq() > local_irq_enable() > interrupt() > NMI > .... > > And everytime you get a new @regs pointer to deal with. > > Wonderful, isn't it? > > Thanks, > > tglx >