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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B1840C00140 for ; Fri, 5 Aug 2022 17:24:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241142AbiHERYG (ORCPT ); Fri, 5 Aug 2022 13:24:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40638 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238133AbiHERYE (ORCPT ); Fri, 5 Aug 2022 13:24:04 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14F99765E; Fri, 5 Aug 2022 10:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1659720244; x=1691256244; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=gA+aK7p4JPfKPh6XWb3jT6QvhY4lfvwF9wFUlII7414=; b=nOcAuOkAYDCvmQnpGI1mxztF3vXmNp0Fbw1Mlg26xkAslMlQpw8EbgER 0A2zRTO3DfFA6ptozJdIVLY1xOe/SFbACxjpT2/DtVObrKLAKZRwSYVVn X58eHO/SGQU2PRcFmu1K41J6eXoyBS+4uJBKbffnRWBsPiEJgxxueK0bM 56sBUsujAQfxqPvjUOvQJQRWRpxWwaP7DJi8G/4LqQSDN8b2/1hAbGSAl 9QIm4SlT6LdK6Q1EEa7FmJ3EBcaW0Ir9adj0ZblE+FpaMOsRZZe0wiM+b cKohLG43uq+LmbYi6REGrb21TaUc6oitPOgPwWYZCU8Blz3lva3BSzsxY w==; X-IronPort-AV: E=McAfee;i="6400,9594,10430"; a="351969430" X-IronPort-AV: E=Sophos;i="5.93,216,1654585200"; d="scan'208";a="351969430" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Aug 2022 10:24:03 -0700 X-IronPort-AV: E=Sophos;i="5.93,216,1654585200"; d="scan'208";a="579571659" Received: from rderber-mobl1.amr.corp.intel.com (HELO [10.212.217.71]) ([10.212.217.71]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Aug 2022 10:24:03 -0700 Message-ID: Date: Fri, 5 Aug 2022 10:24:04 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v2] x86/fpu: Allow PKRU to be (once again) written by ptrace. Content-Language: en-US To: Kyle Huey , Dave Hansen , Thomas Gleixner , Borislav Petkov Cc: Ingo Molnar , x86@kernel.org, "H. Peter Anvin" , Paolo Bonzini , Andy Lutomirski , Peter Zijlstra , linux-kernel@vger.kernel.org, Robert O'Callahan , David Manouchehri , Borislav Petkov , kvm@vger.kernel.org, stable@vger.kernel.org References: <20220804031632.52921-1-khuey@kylehuey.com> From: Dave Hansen In-Reply-To: <20220804031632.52921-1-khuey@kylehuey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/3/22 20:16, Kyle Huey wrote: > When management of the PKRU register was moved away from XSTATE, emulation > of PKRU's existence in XSTATE was added for APIs that read XSTATE, but not > for APIs that write XSTATE. This can be seen by running gdb and executing > `p $pkru`, `set $pkru = 42`, and `p $pkru`. On affected kernels (5.14+) the > write to the PKRU register (which gdb performs through ptrace) is ignored. Do you happen to have a reproducer for this sitting around? I'd love to get an addition to the pkeys selftest/ in place to make sure we don't break this again. PKRU is a very special snowflake.