Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp216762iob; Mon, 2 May 2022 17:30:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyDtjTb/yc0mvp8na+PHQLMckWSdzuYwJcUDC4dDwyeNRMRPM/X/MiHX3EHpi0d/kZQv5kP X-Received: by 2002:a17:902:f649:b0:156:1609:79e9 with SMTP id m9-20020a170902f64900b00156160979e9mr14458224plg.69.1651537822060; Mon, 02 May 2022 17:30:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651537822; cv=none; d=google.com; s=arc-20160816; b=uIeDqs7GXx23HCWTcRMwoHy2x+UhUPiXul2ITlJ1k6Y0i5PlVEQ0HSTAikntIXmj5C 9qsif9KclKQco2Z3lpXQJbSbHcDzNW2dHiIu8tPV2Tet9E+ut2R/tPWq6jqa0sYt4Yhq TNAh7dKPj+U3Zn7o7gqZjKSA8CzRXZlKQpmBO19Si2nSsN3ZQM//DOeIEUE87GUbwTQg q/1Wh47F9g+vrNA2Ve8odmJCHVZKr5mcZe7MJDxR5I6wiS/3clE9SB3NBXQRBDcSMPzD RWYn12wLmzrw748UwHrEY8leQblC5XjQ4bwHk5TXW+o8HblcIXslhIl/giRuU9m45TTh uFFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=ZDNXgBhMz20++Q4yigO612T0eYygF7r9J92FIVtim7Y=; b=mE1Q5S6VW0ldNlC2LJjVRevbT7kPLjr+QzqNDXsNS6Zqueobzq8eBfUMbEaqBfhgnN vdqvgWEt0BC/S6GK9gp+JVLLdgPypdciviNrn19vfXLfaSD/cmMjGEqmVNQJbfXsSC2a XM7wHmlHMfTCE2f1uHvBkm1GzH6HCqqtOVKdU6OZ9E2JlSGfMTeo1FuA4vOetBk0Fgpd 6ZIq9CrDRopqiWSDzqywfOvzMhUqwhnQ9Er+ZmJiRsXhoxJ8/AbUp2M5RKL2eJIpq4Uq kASBBGQ4YtB4Z5R6dGsF5gqK93XZBG5FSZAqIHEk2ZE+EGGGOF0c5cLmAhpVnw1xXLA+ duvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=JgdYu4i8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id d76-20020a621d4f000000b00505b033e35fsi14611932pfd.71.2022.05.02.17.30.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 May 2022 17:30:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=JgdYu4i8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 3007D3CFDC; Mon, 2 May 2022 17:24:35 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1386440AbiEBREq (ORCPT + 99 others); Mon, 2 May 2022 13:04:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44902 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1386455AbiEBREe (ORCPT ); Mon, 2 May 2022 13:04:34 -0400 Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40044270D for ; Mon, 2 May 2022 10:01:05 -0700 (PDT) Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-2ebf4b91212so154606977b3.8 for ; Mon, 02 May 2022 10:01:05 -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=ZDNXgBhMz20++Q4yigO612T0eYygF7r9J92FIVtim7Y=; b=JgdYu4i8LXmMnXLXrkcT7kHOAMHmAidhNS6U0ueSLoMV2xM914ojCWAfQT3FwPR+1l PoLOfIxEoZUnpUcLAHkqdzewTFZmlPHzf2P4KtVSykjNiUaSjHEZ4JXGrO87YwYEfY29 Z+QTsgSlKNHz0OH4JLROLS99pvqLcEwt40oWqVFt9/peS0coGpNEREGC2CeybE9udTkZ PBSCKT1mEj4EUvIGaFwp/YC2T3K64TVZ9MIoJHwe/x1WPyoerlcNsHxE9mUxBRzI6/O/ dA+GoQpNe65P4xsbfG25zceIOp2apEavuWjynEw+O1ENeDzWJe9o6sXQ0vlxCo8yyC69 UBEg== 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=ZDNXgBhMz20++Q4yigO612T0eYygF7r9J92FIVtim7Y=; b=U+om279C0KmLyf1GuJ6ccc61ZtLlMjZ8FNlwZhV9LCs0lgG70Yt8lZFatCUmsh9X27 cwWKEDyTTQPnTHQ9m0lqdXFyNs/9CXrX7e0HOZ8SaMqNIdKhOFIq8To7aPndy6DjfwbH BvZK9gKGTlm5Q6JrTwZ1S7OCMdgUNT6KErb/Q9fQa6yVknT4RvRsLieN5YIPeYLxcIvT Ul0bKrr7Zackb27LxPEUyEmzCExYaFRi+wfOoLF/bivvLOekt1uhy/WZv9gBdbjr9+SE ckBtA+UWD7rJysiu6/YC7e0Cf5jAC3gE3A8gcP7+UlSx8vULjxj10WMskGjl7jihsUKj lGIQ== X-Gm-Message-State: AOAM533i2h9i1zN814oVLdNPBqozV+s4R91lPiPha0owSTypWr/cqtj7 enHpJrYUBGQfN5tiuqF3EW2WQUVabMwsWnoTf4eKfg== X-Received: by 2002:a81:1f8b:0:b0:2f8:5846:445e with SMTP id f133-20020a811f8b000000b002f85846445emr11776773ywf.50.1651510864112; Mon, 02 May 2022 10:01:04 -0700 (PDT) MIME-Version: 1.0 References: <20220426164315.625149-1-glider@google.com> <20220426164315.625149-29-glider@google.com> <87a6c6y7mg.ffs@tglx> In-Reply-To: <87a6c6y7mg.ffs@tglx> From: Alexander Potapenko Date: Mon, 2 May 2022 19:00:28 +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-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=no 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 On Wed, Apr 27, 2022 at 3:32 PM Thomas Gleixner wrote: > > On Tue, Apr 26 2022 at 18:42, Alexander Potapenko wrote: > > Can you please use 'entry:' as prefix. Slapping kmsan in front of > everything does not really make sense. Sure, will do. > > Replace instrumentation_begin() with instrumentation_begin_with_r= egs() > > to let KMSAN handle the non-instrumented code and unpoison pt_regs > > passed from the instrumented part. > > That should be: > > from the non-instrumented part > or > passed to the instrumented part > > right? That should be "from the non-instrumented part", you are right. > > --- a/kernel/entry/common.c > > +++ b/kernel/entry/common.c > > @@ -23,7 +23,7 @@ static __always_inline void __enter_from_user_mode(st= ruct pt_regs *regs) > > CT_WARN_ON(ct_state() !=3D CONTEXT_USER); > > user_exit_irqoff(); > > > > - instrumentation_begin(); > > + instrumentation_begin_with_regs(regs); > > I can see what you are trying to do, but this will end up doing the same > thing over and over. Let's just look at a syscall. > > __visible noinstr void do_syscall_64(struct pt_regs *regs, int nr) > { > ... > nr =3D syscall_enter_from_user_mode(regs, nr) > > __enter_from_user_mode(regs) > ..... > instrumentation_begin_with_regs(regs); > .... > > instrumentation_begin_with_regs(regs); > .... > > instrumentation_begin_with_regs(regs); > > if (!do_syscall_x64(regs, nr) && !do_syscall_x32(regs, nr) && nr = !=3D -1) { > /* Invalid system call, but still a system call. */ > regs->ax =3D __x64_sys_ni_syscall(regs); > } > > instrumentation_end(); > > syscall_exit_to_user_mode(regs); > instrumentation_begin_with_regs(regs); > __syscall_exit_to_user_mode_work(regs); > instrumentation_end(); > __exit_to_user_mode(); > > That means you memset state four times and unpoison regs four times. I'm > not sure whether that's desired. Regarding the regs, you are right. It should be enough to unpoison the regs at idtentry prologue instead. I tried that initially, but IIRC it required patching each of the DEFINE_IDTENTRY_XXX macros, which already use instrumentation_begin(). This decision can probably be revisited. As for the state, what we are doing here is still not enough, although it appears to work. Every time an instrumented function calls another function, it sets up the metadata for the function arguments in the per-task struct kmsan_context_state. Similarly, every instrumented function expects its caller to put the metadata into that structure. Now, if a non-instrumented function (e.g. every `noinstr` function) calls an instrumented one (which happens inside the instrumentation_begin()/instrumentation_end() region), nobody sets up the state for that instrumented function, so it may report false positives when accessing its arguments, if there are leftover poisoned values in the state. To overcome this problem, ideally we need to wipe kmsan_context_state every time a call from the non-instrumented function occurs. But this cannot be done automatically exactly because we cannot instrument the named function :) We therefore apply an approximation, wiping the state at the point of the first transition between instrumented and non-instrumented code. Because poison values are generally rare, and instrumented regions tend to be short, it is unlikely that further calls from the same non-instrumented function will result in false positives. Yet it is not completely impossible, so wiping the state for the second/third etc. time won't hurt. > > instrumentation_begin()/end() are not really suitable IMO. They were > added to allow objtool to validate that nothing escapes into > instrumentable code unless annotated accordingly. An alternative to this would be adding some extra code unpoisoning the state to every non-instrumented function that contains an instrumented region. That code would have to precede the first instrumentation_begin() anyway, so I thought it would be reasonable to piggyback on the existing annotation. > > 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.