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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 4E339C433E0 for ; Sat, 16 May 2020 14:09:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2EC9C20671 for ; Sat, 16 May 2020 14:09:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726328AbgEPOJg (ORCPT ); Sat, 16 May 2020 10:09:36 -0400 Received: from esa5.hc3370-68.iphmx.com ([216.71.155.168]:51750 "EHLO esa5.hc3370-68.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726266AbgEPOJg (ORCPT ); Sat, 16 May 2020 10:09:36 -0400 Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: hDidN96EUzAnOHMS55xkxs8WWGVq+5pBKthbrckMfVRSrIbE6S6mARR7e6iCmfxtRs+t6dZgOn ky111k+QuspRYuPHlo/+bvt29pmbSElOVJe4am+k+1tbPdGq/i+V24dJ3m99rHE8HATp2ZNRal knsFZmYHRfkpmlZjBldpccNopJkJ6lo0HltBZH+ddN3rfRQYUukAzDVjzrj80JOwNd+xhBnxBN 4I+HAvqcn84qN2FSgGa3aBcSWhG+FVqxNDKAS3eGl286pjYdRCihkiuh2RLGpNdST+isqSx6Wx l98= X-SBRS: None X-MesageID: 17965253 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,398,1583211600"; d="scan'208";a="17965253" Subject: Re: [PATCH v10 01/26] Documentation/x86: Add CET description To: "H.J. Lu" CC: Dave Hansen , Yu-cheng Yu , the arch/x86 maintainers , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , LKML , "open list:DOCUMENTATION" , 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 , Weijiang Yang References: <20200429220732.31602-1-yu-cheng.yu@intel.com> <20200429220732.31602-2-yu-cheng.yu@intel.com> <5cc163ff9058d1b27778e5f0a016c88a3b1a1598.camel@intel.com> <44c055342bda4fb4730703f987ae35195d1d0c38.camel@intel.com> <32235ffc-6e6c-fb3d-80c4-a0478e2d0e0f@intel.com> <6272c481-af90-05c5-7231-3ba44ff9bd02@citrix.com> From: Andrew Cooper Message-ID: Date: Sat, 16 May 2020 15:09:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On 16/05/2020 03:37, H.J. Lu wrote: > On Fri, May 15, 2020 at 5:13 PM Andrew Cooper wrote: >> Finally seeing as the question was asked but not answered, it is >> actually quite easy to figure out whether shadow stacks are enabled in >> the current thread. >> >> mov $1, %eax >> rdsspd %eax > This is for 32-bit mode. It actually works for both, if all you need is a shstk yes/no check. Usually, you also want SSP in the yes case, so substitute rdsspq %rax as appropriate. (On a tangent - binutils mandating the D/Q suffixes is very irritating with mixed 32/64bit code because you have to #ifdef your instructions despite the register operands being totally unambiguous.  Also, D is the wrong suffix for AT&T syntax, and should be L.  Frankly - the Intel manuals are wrong and should not have the operand size suffix included in the opcode name, as they are consistent with all the other instructions in this regard.) > I use > > /* Check if shadow stack is in use. */ > xorl %esi, %esi > rdsspq %rsi > testq %rsi, %rsi > /* Normal return if shadow stack isn't in use. */ > je L(no_shstk) This is probably fine for user code, as I don't think it would be legitimate for shstk to be enabled, with SSP being 0. Sadly, the same is not true for kernel shadow stacks. SSP is 0 after SYSCALL, SYSENTER and CLRSSBSY, and you've got to be careful to re-establish the shadow stack before a CALL, interrupt or exception tries pushing a word onto the shadow stack at 0xfffffffffffffff8. It is a very good (lucky?) thing that frame is unmapped for other reasons, because this corner case does not protect against multiple threads/cores using the same shadow stack concurrently. ~Andrew