Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp376810ybi; Fri, 31 May 2019 03:00:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqxIw1ipXDa05wXBxTCCZue2wg8Y5OIWHpVFPcur/nxTnpkii3AmdFzABI57AI91SkaEAIBA X-Received: by 2002:a65:51cb:: with SMTP id i11mr7783152pgq.390.1559296812392; Fri, 31 May 2019 03:00:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559296812; cv=none; d=google.com; s=arc-20160816; b=Ht/Ac11PR/ou4NIeBiaGJ+BtbW6K52E03laDx+KfyDfOba7+5BAeN56hihloWiKR5a UCq17sCyLVYX3uqZYMWYWOJuRPXSXLTl7A8gOSeH9P1xoHQZ2WKzhXnZ9jyVcrpdKMzH HPry1guAQr4QSXk1QsmfHl/I3SzYVLcKtInBeVyfebDqwxcjom4pYyWpQX4wS+tx2p1f WZMiGXJKwp+v/1PrFLBGuRmRaz8X4WuQDr/gvDkkGnM1bCCcpgRda3D6NUEcGwyMVucd FO9TW8/dpz6jaG4DrXLGf+X2c8Q83UoTw2kPNQKNfEjc4i0x/dT8thE0XcKck9ljye0+ g7iw== 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=t/dabiI1+zXohN0XPJPWZWWtcKfqB2v/nUShweQXWc0=; b=ViOUcMD38YFDDe2cZ0cCdSkPJApiJmStSeUUdYCjimfBeqgkOd+DxiXSLKm57afnhu aDAIjshZf3qESu5XttaF3hJ4OXXQ5vXwXHSHFAWx3vD4KeUr+1ED3ntn8HF5cInNfaLs xfl/uwVzjnQEL8SOwo0xOtDIzngE4T7MuXg5ZifSnvqzIdH8UEUYDpQAavrbOsxHC2ik s+z9uN2j8UOgsA4AjE0XJJzFvBHOAOTcKx5cyIjO8cZ5WV0onVlwXfJXGIJjgdSHqzWx gS/xq9w9jWZ3TGv/I4tefrz992rYLIIlIboGkzNG/wTAI11pwVgjfang1JTJXUkw0+jY FTTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=e32JUU3P; 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 c15si5222548pgl.160.2019.05.31.02.59.55; Fri, 31 May 2019 03:00:12 -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=e32JUU3P; 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 S1727087AbfEaJ5s (ORCPT + 99 others); Fri, 31 May 2019 05:57:48 -0400 Received: from mail-oi1-f194.google.com ([209.85.167.194]:42327 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726307AbfEaJ5s (ORCPT ); Fri, 31 May 2019 05:57:48 -0400 Received: by mail-oi1-f194.google.com with SMTP id v25so6700065oic.9 for ; Fri, 31 May 2019 02:57:48 -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=t/dabiI1+zXohN0XPJPWZWWtcKfqB2v/nUShweQXWc0=; b=e32JUU3PfkhWWkA3PguBCXaJsg7lPEFltaK4JUSnF6IbCO9/3/VgXrN9kHh3T04HLU cc4gQFNRfzpdnn3Zlkl3O/QinrY8vWDnieuJJwrqkt0dvkzgU7PDufYQXYPqEMNesADO JVaQC2W7ZHVecGYxyIF1y9IjnOSSWo9uVr8tnjnGR/TrX7YhkC2+GmF2tE5qi7m3/FYn BfTdJ9JkODL+hIo8f7g/TB0zWHG/iD4uzthFPjhkMd1kviqjgSmtvoJPj1I2+Rb2A3IN KPSBDVByMZKy33HHr8kFjSobFkI5QhXEmahv2OcciHPwIGZXWvZ6+fRFSfkNx/Xuce6j T5LQ== 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=t/dabiI1+zXohN0XPJPWZWWtcKfqB2v/nUShweQXWc0=; b=p9gkkwZrQzrast8aEDSYBwUN5zvmrFG+RGISX0qMQnA6YL2LvgaQZ/A+HM1CQviU4O uzMwyQ5aIPoVR/625z6UcpdVFvKt89OpDMmUa+QkJr+Xhl2iY71jpJoYhqEYnWSHjPdg USX0//NZShPsBssuQHpgDPanscYYTlP66SRVu5oaSY6Rd1ZJ8xNKUsYZY0jISkw73Fwv VCM1ylhPFFC4rgYo5dHEH+UEakAoECWNaxNByV/SCuWueXhtQBegMwaEKicP1J0q0m88 o9N3/1Spk1MpUFoujzXHodK09zdrc+IwztZA8JRjl95OvrgBbaKR2pLqtunFR9A1NY0i c8+w== X-Gm-Message-State: APjAAAWg/9fn3GGeUfBvkvfK/GNdR0Tdr53FFTRKNOarGYnG6A7XlgYQ 14n5D8AQeavvolT1ihgHls3Ysx8fST3sl2KKgttGTw== X-Received: by 2002:aca:bfc6:: with SMTP id p189mr5781082oif.121.1559296667221; Fri, 31 May 2019 02:57:47 -0700 (PDT) MIME-Version: 1.0 References: <20190529141500.193390-1-elver@google.com> <20190529141500.193390-3-elver@google.com> In-Reply-To: From: Marco Elver Date: Fri, 31 May 2019 11:57:36 +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 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