Received: by 2002:a05:6a10:8395:0:0:0:0 with SMTP id n21csp616521pxh; Tue, 9 Nov 2021 16:14:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJzW8u/+CrKwrBD7DyA8TqoTmvipv8WAHPBt+GY3vGPpVLBttIs1EX2vzmZSg/KtZYmPEi+L X-Received: by 2002:a05:6e02:1749:: with SMTP id y9mr8424798ill.232.1636503282387; Tue, 09 Nov 2021 16:14:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636503282; cv=none; d=google.com; s=arc-20160816; b=v+I13FHj5ux5hwYCA8c/bS6wSWAg0mgcyd6Ts8t16WG09GVsSP+ON/A2cDuh9KXhIW ioBLSnBUhh5Pw4ghCUcXEA2NpUCgu+FNHtEN3ah91du1GZVA/hF0IdOwVoJuaBfQCn+y NzUYSUzMNueO/x6pEDL5yhiQlMupzr77IgyOpDn5oKmFY1aarjaSFvMA2LbsOReakE0B dr05l+T91k4Z0F1J2eGXvQNXP0/FiDuu7NmS9DfDdee/QWrM2gDsFDOsVfEKLDGgUJbX xH48GTaCyrQQpoOha0PFGJyYo+gp+FAEf50vEdyTjS+QaPOasjmhEbKcFpfgY9tO2QJ6 jSPQ== 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=ei0IjmYjF3Cz9j83zRSEUli+MBWkuUhizQs40K0x/A0=; b=n4h8gPmMkbCFdZuiLyMGNOIfCp1f1luSLPCyC2xRhcX+S1h1IU026B6R3puUAPtJzr mI80alD8DHb5TB0YG5Lx5BWZ/rQqMgLBGrwD3biuYjUH6nR7qQYs6WqYIMS3EJgRji4Z DZxLQBcde5RwuXpyi4iAJkbBDF55Yc3AY8J0T5tcMVExxzb6fr0LtwONAHYYYZGqEWye Ow/4dBv9RosJsl5xK18m+6kI9xrHVYx794lZW1CPhMHTvmpK8cya+Ai+6bzGwv2jwXTr jrwottUWCxfrfDAGIRrkVWe5mkX5ALwrhhoMI2nIR88zkFIRAOY8iQFDL3krvCidW9sH VIQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=jGcnUHEB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h22si30208853jal.48.2021.11.09.16.14.17; Tue, 09 Nov 2021 16:14:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=jGcnUHEB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.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: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242627AbhKIT3Y (ORCPT + 97 others); Tue, 9 Nov 2021 14:29:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243202AbhKIT3X (ORCPT ); Tue, 9 Nov 2021 14:29:23 -0500 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 08CB5C061766 for ; Tue, 9 Nov 2021 11:26:37 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id o8so814321edc.3 for ; Tue, 09 Nov 2021 11:26:36 -0800 (PST) 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=ei0IjmYjF3Cz9j83zRSEUli+MBWkuUhizQs40K0x/A0=; b=jGcnUHEBsbodZFjwpoerQJ8EjsqCv3BcE+rQKXLFvhGfEL5lR0Zp2ogTeibupQhGvj CVqSXfL3y1szo+7gDT3kXSHAdIjM1a+zcto4+Rt0wevVKaRgDekNGHyd/D5neWOxrWf4 EcGTlio1t/2hzh0opontENyuvQQDdBEByBCP2P4s0/nyv3Te+Ly/UqHh40z5JnV3Ji6t aQp+JDj0BkAWqHBtx8XjGweXL00rLKzYiDYANdD+RFTmx4DUTCSlpNiIy6Rip1sDo5X6 IiklCrcmB3KDXrDhsIdc6GMHVX8okMG/jKqWo31KaOM2Z/iXCjisWP6Iq01VFbaVQzmU PkXQ== 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=ei0IjmYjF3Cz9j83zRSEUli+MBWkuUhizQs40K0x/A0=; b=p6GVbV/u9F+xxtXUEAY9VRzkx886PL6wxn506E5zXQS3093aUX2NGtQVBO+dwCBXCT rabO0RgLLDqM5UxtcfeLwgNxZFrz76jg0rc7NZB8J0eUH9jqEKEK9b0hbMpdJXZ2+8ml Ct88ym4TXfwCv99SyLT6GYzb1m+fH6mdHQaK7A0PK+h+LtDFFEww5pQXCesqK+ZEp6Cb +jhhX/US43tJRFA0UZAklZPAnWBFQf9/tsEF+x7lh/dmnQNIeMST2QJk2vam+2Rm49zf 5XIz9TCrtLsrR7XYzRxn3UTBH77iZHc/Fpb5pdiqiqAAh8X4Fb+UszEYqC/I/ZbGqJyc X7EA== X-Gm-Message-State: AOAM533F4m1r33KO+IAyQ+YQyowwJJzq9djZbta1qouOjS1a/N2fUCG/ IhTV54uCIt4hyzZOtFxoOhlM3sNWkXydy0egx7FvAg== X-Received: by 2002:a50:e184:: with SMTP id k4mr13491532edl.217.1636485995403; Tue, 09 Nov 2021 11:26:35 -0800 (PST) MIME-Version: 1.0 References: <85925a39-37c3-a79a-a084-51f2f291ca9c@intel.com> <472b8dbf-2c55-98c9-39ad-2db32a649a20@intel.com> <649f4de7-3c91-4974-9af7-d981a2bf6224@www.fastmail.com> In-Reply-To: From: Brian Geffon Date: Tue, 9 Nov 2021 14:25:59 -0500 Message-ID: Subject: Re: XSAVE / RDPKRU on Intel 11th Gen Core CPUs To: Andy Lutomirski Cc: Dave Hansen , Thomas Gleixner , Guenter Roeck , Borislav Petkov , stable@vger.kernel.org, "the arch/x86 maintainers" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 9, 2021 at 1:58 PM Brian Geffon wrote: > > Hi Andy, > > On Tue, Nov 9, 2021 at 9:58 AM Andy Lutomirski wrote: > > Here's an excerpt from an old email that I, perhaps unwisely, sent to D= ave but not to a public list: > > > > static inline void write_pkru(u32 pkru) > > { > > struct pkru_state *pk; > > > > if (!boot_cpu_has(X86_FEATURE_OSPKE)) > > return; > > > > pk =3D get_xsave_addr(¤t->thread.fpu.state.xsave, > > XFEATURE_PKRU); > > > > /* > > * The PKRU value in xstate needs to be in sync with the value > > that is > > * written to the CPU. The FPU restore on return to userland wo= uld > > * otherwise load the previous value again. > > */ > > fpregs_lock(); > > if (pk) > > pk->pkru =3D pkru; > > > > ^^^ > > else we just write to the PKRU register but leave XINUSE[PKRU] clear on > > return to usermode? That seems... unwise. > > > > __write_pkru(pkru); > > fpregs_unlock(); > > } > > > > I bet you're hitting exactly this bug. The fix ended up being a whole = series of patches, but the gist of it is that the write_pkru() slow path ne= eds to set the xfeature bit in the xsave buffer and then do the write. It = should be possible to make a little patch to do just this in a couple lines= of code. > > I think you've got the right idea, the following patch does seem to > fix the problem on this CPU, this is based on 5.13. It seems the > changes to asm/pgtable.h were not enough, I also had to modify > fpu/internal.h to get it working properly. > Actually, it seems that only the changes to fpu/internal.h seem necessary. I guess the switch_fpu_finish explains how it's reverting to the initial value. diff --git a/arch/x86/include/asm/fpu/internal.h b/arch/x86/include/asm/fpu/internal.h index 16bf4d4a8159..ed2ce7d1afeb 100644 --- a/arch/x86/include/asm/fpu/internal.h +++ b/arch/x86/include/asm/fpu/internal.h @@ -564,18 +564,16 @@ static inline void switch_fpu_finish(struct fpu *new_= fpu) * PKRU state is switched eagerly because it needs to be valid befo= re we * return to userland e.g. for a copy_to_user() operation. */ - if (!(current->flags & PF_KTHREAD)) { - /* - * If the PKRU bit in xsave.header.xfeatures is not set, - * then the PKRU component was in init state, which means - * XRSTOR will set PKRU to 0. If the bit is not set then - * get_xsave_addr() will return NULL because the PKRU value - * in memory is not valid. This means pkru_val has to be - * set to 0 and not to init_pkru_value. - */ - pk =3D get_xsave_addr(&new_fpu->state.xsave, XFEATURE_PKRU)= ; - pkru_val =3D pk ? pk->pkru : 0; - } + /* + * If the PKRU bit in xsave.header.xfeatures is not set, + * then the PKRU component was in init state, which means + * XRSTOR will set PKRU to 0. If the bit is not set then + * get_xsave_addr() will return NULL because the PKRU value + * in memory is not valid. This means pkru_val has to be + * set to 0 and not to init_pkru_value. + */ + pk =3D get_xsave_addr(&new_fpu->state.xsave, XFEATURE_PKRU); + pkru_val =3D pk ? pk->pkru : 0; __write_pkru(pkru_val); }