From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [RFC PATCH v9 01/27] Documentation/x86: Add CET description Date: Mon, 9 Mar 2020 15:19:13 -0700 Message-ID: <56ab33ac-865b-b37e-75f2-a489424566c3@intel.com> References: <0088001c-0b12-a7dc-ff2a-9d5c282fa36b@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from mga06.intel.com ([134.134.136.31]:5055 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727191AbgCIWTP (ORCPT ); Mon, 9 Mar 2020 18:19:15 -0400 In-Reply-To: Content-Language: en-US Sender: linux-arch-owner@vger.kernel.org List-ID: To: "H.J. Lu" Cc: Andy Lutomirski , Yu-cheng Yu , the arch/x86 maintainers , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , LKML , linux-doc@vger.kernel.org, Linux-MM , linux-arch , Linux API , Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , Jann Horn , Jonathan Corbet On 3/9/20 2:12 PM, H.J. Lu wrote: >> But what are the rules for clone()? Should there be rules for >> mismatches for CET enabling between threads if a process (not child >> processes)? > What did you mean? A threaded application is either CET enabled or not > CET enabled. A new thread from clone makes no difference. Stacks are fundamentally thread-local resources. The registers that point to them and MSRs that manage shadow stacks are all CPU-thread local. Nothing is fundamentally tied to the address space shared across the process. A thread might also share *no* control flow with its child. It might ask the thread to start in code that the parent can never even reach. It sounds like you've picked a Linux implementation that has restrictions on top of the fundamentals. That's not wrong per se, but it does deserve explanation and deliberate, not experimental design. Could you go back to the folks at Intel and try to figure out what this was designed to *do*? Yes, I'm probably one of those folks. You know where to find me. :) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [RFC PATCH v9 01/27] Documentation/x86: Add CET description References: <0088001c-0b12-a7dc-ff2a-9d5c282fa36b@intel.com> From: Dave Hansen Message-ID: <56ab33ac-865b-b37e-75f2-a489424566c3@intel.com> Date: Mon, 9 Mar 2020 15:19:13 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-doc-owner@vger.kernel.org To: "H.J. Lu" Cc: Andy Lutomirski , Yu-cheng Yu , the arch/x86 maintainers , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , LKML , linux-doc@vger.kernel.org, Linux-MM , linux-arch , Linux API , Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin , x86-patch-review@intel.com List-ID: Message-ID: <20200309221913.5lBpbIy1HyDUY3Ub8WqdQlDmb3mRIaQWDZjW2WfLEEo@z> On 3/9/20 2:12 PM, H.J. Lu wrote: >> But what are the rules for clone()? Should there be rules for >> mismatches for CET enabling between threads if a process (not child >> processes)? > What did you mean? A threaded application is either CET enabled or not > CET enabled. A new thread from clone makes no difference. Stacks are fundamentally thread-local resources. The registers that point to them and MSRs that manage shadow stacks are all CPU-thread local. Nothing is fundamentally tied to the address space shared across the process. A thread might also share *no* control flow with its child. It might ask the thread to start in code that the parent can never even reach. It sounds like you've picked a Linux implementation that has restrictions on top of the fundamentals. That's not wrong per se, but it does deserve explanation and deliberate, not experimental design. Could you go back to the folks at Intel and try to figure out what this was designed to *do*? Yes, I'm probably one of those folks. You know where to find me. :)