Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp3959092ybi; Mon, 3 Jun 2019 03:20:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqylZMZt7/nNNg3cw05iCoaddmmLQCl5hvL72UY1g6GXWEvXPGvQPVVAsk61/UrlBPVfO+qu X-Received: by 2002:a62:7d10:: with SMTP id y16mr29453608pfc.116.1559557239033; Mon, 03 Jun 2019 03:20:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559557239; cv=none; d=google.com; s=arc-20160816; b=d8w9zfP4Gnh/4vHcRLoFMmfC2hnFaXs7I6yt+V+hbsbDA+nUTepdwnIWz3kAk1IQSS XTS0q4YGCXdtfHSJ8qixNJKIbQIvElrtVEpprit1fhfocy6/+pC/MZuT6W/ZlBJf8sBk jJqhs1hq+b+WQq1edlPcybm6hxC7s89ruAkbDynIkH+R/m1avasdF6hKjiJPomvWqo3X CZjcoCiUn0hCPch+FyNOx4bO8lLONBNnxMGkX8uJMn+QRnhsSKhl/sLNb3g8ZMXLln5J aX9s9MVdIahpsUWOwj4kMxWK6sXreOxeO3VAwrJmPuJig4BjPmq7WByweRynUohvtm9e xa0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=/VCvRg4+mMJ/yKzCQebn8clHJnLDYyzYIHqLnBJ4zrI=; b=FMvNm/9MYINyUUKDRdyimAlZpuYh8cZcQ0RlcyBf0ExLTI6N/BbHw59WTIvWG5y4MO l4HOr3xLjPz4AjWMvgUJ5BxzefQZ68F01Xm09y6xrkdjO3VOIysWe+YVsFjSdyImvVgb +0pty+CG54eVI1w1T27T5lbUYYnRO1X+t0B/u9RClfrEccvjYzf+I2cD4akhm2S92Tuo s3246YhL5wnM5z13kzx7O4LmEuaDmVsfnqbj28m7jH6Rqsxa0prg3KLSLU+dHPnz/HqP gi78isUQuM0/TUgdieIBFIwPFTscCTM3gxm2vgMq8MyFUbUdD+kCRpfP4Tw8muS/EGbv Qsrg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="H/dToC9r"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f187si1138951pfb.265.2019.06.03.03.20.21; Mon, 03 Jun 2019 03:20:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="H/dToC9r"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1727231AbfFCJDn (ORCPT + 99 others); Mon, 3 Jun 2019 05:03:43 -0400 Received: from mail-ot1-f66.google.com ([209.85.210.66]:44635 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726734AbfFCJDn (ORCPT ); Mon, 3 Jun 2019 05:03:43 -0400 Received: by mail-ot1-f66.google.com with SMTP id b7so1753061otl.11 for ; Mon, 03 Jun 2019 02:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/VCvRg4+mMJ/yKzCQebn8clHJnLDYyzYIHqLnBJ4zrI=; b=H/dToC9rVgyO60IieVWtYVTFQ1+mQqRSqm7v+uDMC1JFRW6hoq3rdcMjJGt9aQAIaH mvwyuRkWbUoNOyCBYn6MwVr6/BdJhcTk06MVITyowa6mOgyUH9nBiAvZtjtGzy2TTkda EAF67zsrU7hR7HeHdu/j+sq2s3b8F9Icz0URNmQ1Rh17LYo05PTttkSfR1u2coSXZRtQ tqZZJCE1G1U4VD7OF+rDL6FcRsoI1FklrQXZiMF2/4vOHdaaiTaGerKo7Cs+Inh712v9 uB61H8IfL5Wmv7x9BdPISh8Mu7FAQiQ8nbHfWItpIqQV08wnaeX6MA4FCit0UuEXiTwb 8j4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/VCvRg4+mMJ/yKzCQebn8clHJnLDYyzYIHqLnBJ4zrI=; b=ZPpCM7dH7ewe0qBBjUyvH2ftYZRf7uVAhWpDUk20joXh0h3cqFaP4T1AqCPcIXi8aK W/gSpiVwnjRlJE+GM4wUjW8I6wlYYi5NS/+10j0sVumMUymGFJPg/Tv+CaFgXUdTaAQO 6CmTXmIs8burb6p4nfm3FL+M2i0sJeVpOEolXWC2HzD1ghP1hpHdUx7LTe30cWZKom+T fVMwtqdhR3/JpS+cY3Ig+PneJG58v9erkGx2dRQ79zB3lSBgaF3M8OLAuoAz4yNZGqb5 F+Q4Lpvy/PyzDcS6TNA0ZKENTQouxi80l24hcgvuIdrJ+LzmOfcpb4NB+IyBgDKU645Y CLJg== X-Gm-Message-State: APjAAAXVGyh9vgeI3sMOkozsYX+Vxl13qIpolXOZIHLF7A9XyYvG+7n/ tglS+C5U/3pXLdG3Mo6mtyszPLENvojvnpXWcPpxXg== X-Received: by 2002:a05:6830:1688:: with SMTP id k8mr378583otr.233.1559552622037; Mon, 03 Jun 2019 02:03:42 -0700 (PDT) MIME-Version: 1.0 References: <20190529141500.193390-1-elver@google.com> <20190529141500.193390-3-elver@google.com> <3B49EF08-147F-451C-AA5B-FC4E1B8568EE@zytor.com> In-Reply-To: <3B49EF08-147F-451C-AA5B-FC4E1B8568EE@zytor.com> From: Marco Elver Date: Mon, 3 Jun 2019 11:03:30 +0200 Message-ID: Subject: Re: [PATCH 2/3] x86: Move CPU feature test out of uaccess region To: "H. Peter Anvin" Cc: Peter Zijlstra , Andrey Ryabinin , Dmitry Vyukov , Alexander Potapenko , Andrey Konovalov , Mark Rutland , Jonathan Corbet , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "the arch/x86 maintainers" , Arnd Bergmann , Josh Poimboeuf , "open list:DOCUMENTATION" , LKML , linux-arch , kasan-dev Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks for the clarification. I found that static_cpu_has was replaced by static_cpu_has_safe: https://lkml.org/lkml/2016/1/24/29 -- so is it fair to assume that both are equally safe at this point? I have sent a follow-up patch which uses static_cpu_has: http://lkml.kernel.org/r/20190531150828.157832-3-elver@google.com Many thanks! -- Marco On Sat, 1 Jun 2019 at 03:13, wrote: > > On May 31, 2019 2:57:36 AM PDT, Marco Elver wrote: > >On Wed, 29 May 2019 at 16:29, wrote: > >> > >> On May 29, 2019 7:15:00 AM PDT, Marco Elver wrote: > >> >This patch is a pre-requisite for enabling KASAN bitops > >> >instrumentation: > >> >moves boot_cpu_has feature test out of the uaccess region, as > >> >boot_cpu_has uses test_bit. With instrumentation, the KASAN check > >would > >> >otherwise be flagged by objtool. > >> > > >> >This approach is preferred over adding the explicit kasan_check_* > >> >functions to the uaccess whitelist of objtool, as the case here > >appears > >> >to be the only one. > >> > > >> >Signed-off-by: Marco Elver > >> >--- > >> >v1: > >> >* This patch replaces patch: 'tools/objtool: add kasan_check_* to > >> > uaccess whitelist' > >> >--- > >> > arch/x86/ia32/ia32_signal.c | 9 ++++++++- > >> > 1 file changed, 8 insertions(+), 1 deletion(-) > >> > > >> >diff --git a/arch/x86/ia32/ia32_signal.c > >b/arch/x86/ia32/ia32_signal.c > >> >index 629d1ee05599..12264e3c9c43 100644 > >> >--- a/arch/x86/ia32/ia32_signal.c > >> >+++ b/arch/x86/ia32/ia32_signal.c > >> >@@ -333,6 +333,7 @@ int ia32_setup_rt_frame(int sig, struct ksignal > >> >*ksig, > >> > void __user *restorer; > >> > int err = 0; > >> > void __user *fpstate = NULL; > >> >+ bool has_xsave; > >> > > >> > /* __copy_to_user optimizes that into a single 8 byte store > >*/ > >> > static const struct { > >> >@@ -352,13 +353,19 @@ int ia32_setup_rt_frame(int sig, struct > >ksignal > >> >*ksig, > >> > if (!access_ok(frame, sizeof(*frame))) > >> > return -EFAULT; > >> > > >> >+ /* > >> >+ * Move non-uaccess accesses out of uaccess region if not > >strictly > >> >+ * required; this also helps avoid objtool flagging these > >accesses > >> >with > >> >+ * instrumentation enabled. > >> >+ */ > >> >+ has_xsave = boot_cpu_has(X86_FEATURE_XSAVE); > >> > put_user_try { > >> > put_user_ex(sig, &frame->sig); > >> > put_user_ex(ptr_to_compat(&frame->info), > >&frame->pinfo); > >> > put_user_ex(ptr_to_compat(&frame->uc), &frame->puc); > >> > > >> > /* Create the ucontext. */ > >> >- if (boot_cpu_has(X86_FEATURE_XSAVE)) > >> >+ if (has_xsave) > >> > put_user_ex(UC_FP_XSTATE, > >&frame->uc.uc_flags); > >> > else > >> > put_user_ex(0, &frame->uc.uc_flags); > >> > >> This was meant to use static_cpu_has(). Why did that get dropped? > > > >I couldn't find any mailing list thread referring to why this doesn't > >use static_cpu_has, do you have any background? > > > >static_cpu_has also solves the UACCESS warning. > > > >If you confirm it is safe to change to static_cpu_has(), I will change > >this patch. Note that I should then also change > >arch/x86/kernel/signal.c to mirror the change for 32bit (although > >KASAN is not supported for 32bit x86). > > > >Thanks, > >-- Marco > > I believe at some point the intent was that boot_cpu_has() was safer and could be used everywhere. > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity.