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=-7.9 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 7BB5BC433E9 for ; Thu, 3 Sep 2020 17:59:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 63C1720775 for ; Thu, 3 Sep 2020 17:59:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728677AbgICR7S (ORCPT ); Thu, 3 Sep 2020 13:59:18 -0400 Received: from mga18.intel.com ([134.134.136.126]:1301 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726327AbgICR7R (ORCPT ); Thu, 3 Sep 2020 13:59:17 -0400 IronPort-SDR: Zey8bhnXoWmUpAaat3pVpAK6f3SZOPQBi8xZwhy83WX+eZ99nSpcrQVUuI5IJ8uZmy+pQ3cntM 26sdud4xUmZg== X-IronPort-AV: E=McAfee;i="6000,8403,9733"; a="145329662" X-IronPort-AV: E=Sophos;i="5.76,387,1592895600"; d="scan'208";a="145329662" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Sep 2020 10:59:16 -0700 IronPort-SDR: X6hOgUBXuT53zGBETVRIl8Y3udPYgeOjMvy4EgfTvR+oR8iOyOvL0gprGjnPMNJMYyxw+50upa fFrRD+sU+TdQ== X-IronPort-AV: E=Sophos;i="5.76,387,1592895600"; d="scan'208";a="334548855" Received: from yyu32-mobl1.amr.corp.intel.com (HELO [10.209.173.133]) ([10.209.173.133]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Sep 2020 10:59:15 -0700 Subject: Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET To: Dave Hansen , Andy Lutomirski Cc: Jann Horn , the arch/x86 maintainers , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , kernel list , "open list:DOCUMENTATION" , Linux-MM , linux-arch , Linux API , Arnd Bergmann , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin , Weijiang Yang References: <46e42e5e-0bca-5f3f-efc9-5ab15827cc0b@intel.com> <40BC093A-F430-4DCC-8DC0-2BA90A6FC3FA@amacapital.net> <88261152-2de1-fe8d-7ab0-acb108e97e04@intel.com> <1b51d89c-c7de-2032-df23-e138d1369ffa@intel.com> <21491d05-6306-0a6f-58a7-8bf29feae8c7@intel.com> <8fcde9bb-284f-f089-96d3-702f501a6258@intel.com> From: "Yu, Yu-cheng" Message-ID: <2a58982b-8a69-1280-86ec-d0b70ede4453@intel.com> Date: Thu, 3 Sep 2020 10:59:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <8fcde9bb-284f-f089-96d3-702f501a6258@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On 9/3/2020 9:42 AM, Dave Hansen wrote: > On 9/3/20 9:32 AM, Andy Lutomirski wrote: >>> Taking the config register out of the init state is illogical, as is >>> writing to SSP while the config register is in its init state. >> What's so special about the INIT state? It's optimized by XSAVES, but >> it's just a number, right? So taking the register out of the INIT >> state is kind of like saying "gdb wanted to set xmm0 to (0,0,0,1), but >> it was in the INIT state to begin with", right? > > Yeah, that's a good point. The init state shouldn't be special, as the > hardware is within its right to choose not to use the init optimization > at any time. > Then, I would suggest changing get_xsave_addr() to return non-null for the INIT state case. For the other two cases, it still returns NULL. But this also requires any write to INIT states to set xstate_bv bits properly. This would be a pitfall for any code addition later on. Looking at this another way. Would it be better for the debugger to get an error and then to set the MSR directly first (vs. changing the XSAVES INIT state first)?