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 X-Spam-Level: X-Spam-Status: No, score=-16.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C317BC04FF3 for ; Mon, 24 May 2021 16:34:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9593D613CC for ; Mon, 24 May 2021 16:34:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233048AbhEXQgF (ORCPT ); Mon, 24 May 2021 12:36:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:38382 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232491AbhEXQgE (ORCPT ); Mon, 24 May 2021 12:36:04 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 33DDD6140C for ; Mon, 24 May 2021 16:34:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621874076; bh=ZLC8qQnMj4ooJVxFsue4U3K8DWfx8sWZhRr0SsKBcjk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=POmSP74CcUe0KM1A6asTBP5N4cIxU9qdYs5z543h7DwZAi5wWbC+pl8QLI6UkE1G6 U2321BNMHejTCio06KhWeZyVujf8vQIy+zgeNhstptLNWb6bS9wo4kjmQHjw8R9RQ7 rDHKy1e6H75XccxTC3E4MurrWi1N7CxvXPUaoIPAE8H1JJPUyPfBJveR7+OMBO7WMb /KTAlJ/Fh8Af5kcO1Yyo8m4CXLiQGwCYoOM+g6bXJ59tCp7VDgQ9uPdE0oprCspy5H lR6K0JCV1oyUIeWhz5lnd4yvQLgA/LvwtZ+H4tx1sa5np3laPH6v18fkAuQHee3yOl JoTZIcQaf1WPA== Received: by mail-ed1-f54.google.com with SMTP id t15so32718141edr.11 for ; Mon, 24 May 2021 09:34:36 -0700 (PDT) X-Gm-Message-State: AOAM530Db5iiKgrNI0OyG4xPIZGjX/2j863/9ZFQXvy43V9RSy7X6QGQ yKnuaCU6Oa/PMS+jUg5Ob7OtAtr11Myg9z8RMfgcxw== X-Google-Smtp-Source: ABdhPJy/LkAdwUDEi2HBwJHj8sOm3jtgls+wbFBUGYPLK3LBnPye3W6g3OUK8gFArWJZcw6647SJKzgVJmX+8UAAWoY= X-Received: by 2002:a05:6402:4251:: with SMTP id g17mr26424758edb.238.1621874074727; Mon, 24 May 2021 09:34:34 -0700 (PDT) MIME-Version: 1.0 References: <20200512145444.15483-6-yu-cheng.yu@intel.com> <158964181793.17951.15480349640697746223.tip-bot2@tip-bot2> In-Reply-To: <158964181793.17951.15480349640697746223.tip-bot2@tip-bot2> From: Andy Lutomirski Date: Mon, 24 May 2021 09:34:23 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [tip: x86/fpu] x86/fpu/xstate: Define new functions for clearing fpregs and xstates To: LKML Cc: linux-tip-commits@vger.kernel.org, Fenghua Yu , Yu-cheng Yu , Borislav Petkov , Dave Hansen , Tony Luck , x86 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 16, 2020 at 8:10 AM tip-bot2 for Fenghua Yu wrote: > > The following commit has been merged into the x86/fpu branch of tip: > > Commit-ID: b860eb8dce5906b14e3a7f3c771e0b3d6ef61b94 > Gitweb: https://git.kernel.org/tip/b860eb8dce5906b14e3a7f3c771e0b3d6ef61b94 > Author: Fenghua Yu > AuthorDate: Tue, 12 May 2020 07:54:39 -07:00 > Committer: Borislav Petkov > CommitterDate: Wed, 13 May 2020 13:41:50 +02:00 > > x86/fpu/xstate: Define new functions for clearing fpregs and xstates syzbot says this is busted. I've made no effort to identify the precise bug that is making syzbot complain, but: > /* > - * Clear FPU registers by setting them up from > - * the init fpstate: > + * Clear FPU registers by setting them up from the init fpstate. > + * Caller must do fpregs_[un]lock() around it. > */ > -static inline void copy_init_fpstate_to_fpregs(void) > +static inline void copy_init_fpstate_to_fpregs(u64 features_mask) > { > - fpregs_lock(); > - > if (use_xsave()) > - copy_kernel_to_xregs(&init_fpstate.xsave, -1); > + copy_kernel_to_xregs(&init_fpstate.xsave, features_mask); > else if (static_cpu_has(X86_FEATURE_FXSR)) > copy_kernel_to_fxregs(&init_fpstate.fxsave); > else > @@ -307,9 +305,6 @@ static inline void copy_init_fpstate_to_fpregs(void) > > if (boot_cpu_has(X86_FEATURE_OSPKE)) > copy_init_pkru_to_fpregs(); if (boot_cpu_has(X86_FEATURE_OSPKE) && (features_mask & PKRU)), perhaps? > - > - fpregs_mark_activate(); > - fpregs_unlock(); > } > > /* > @@ -318,18 +313,40 @@ static inline void copy_init_fpstate_to_fpregs(void) > * Called by sys_execve(), by the signal handler code and by various > * error paths. > */ > -void fpu__clear(struct fpu *fpu) > +static void fpu__clear(struct fpu *fpu, bool user_only) > { > - WARN_ON_FPU(fpu != ¤t->thread.fpu); /* Almost certainly an anomaly */ > + WARN_ON_FPU(fpu != ¤t->thread.fpu); > > - fpu__drop(fpu); > + if (!static_cpu_has(X86_FEATURE_FPU)) { > + fpu__drop(fpu); > + fpu__initialize(fpu); > + return; > + } > > - /* > - * Make sure fpstate is cleared and initialized. > - */ > - fpu__initialize(fpu); > - if (static_cpu_has(X86_FEATURE_FPU)) > - copy_init_fpstate_to_fpregs(); > + fpregs_lock(); > + > + if (user_only) { > + if (!fpregs_state_valid(fpu, smp_processor_id()) && > + xfeatures_mask_supervisor()) > + copy_kernel_to_xregs(&fpu->state.xsave, > + xfeatures_mask_supervisor()); This looks correct to me. So I'm guessing that syzbot may have misattributed the problem. But we definitely need to clean up the XRSTOR #GP handling before CET lands.